From owner-freebsd-current@FreeBSD.ORG Sat Jun 30 23:29:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24D87106564A for ; Sat, 30 Jun 2012 23:29:38 +0000 (UTC) (envelope-from erich@alogreentechnologies.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id CA30F8FC15 for ; Sat, 30 Jun 2012 23:29:37 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.29]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q5UNTUTV019752; Sat, 30 Jun 2012 17:29:31 -0600 From: Erich Dollansky Organization: ALO Green Technologies To: Matthias Apitz Date: Sun, 1 Jul 2012 06:29:28 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) References: <20120629133422.GA2233@tiny.Sisis.de> <201206301349.58930.erich@alogreentechnologies.com> <20120630151130.GA1106@tiny.Sisis.de> In-Reply-To: <20120630151130.GA1106@tiny.Sisis.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201207010629.29148.erich@alogreentechnologies.com> X-Mailman-Approved-At: Sun, 01 Jul 2012 00:41:07 +0000 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jun 2012 23:29:38 -0000 Hi, On Saturday, June 30, 2012 10:11:31 PM Matthias Apitz wrote: > El d=EDa Saturday, June 30, 2012 a las 01:49:58PM +0700, Erich Dollansky = escribi=F3: >=20 > >=20 > > Can you try FreeBSD 7.4 or 8.3? > >=20 > > It is sad to say but some times support for older hardware gets cut out= for whatever reason. >=20 > The IT guy of my company found this laptop in the attic and because > it has no Wifi, nobody is interested in using it anymore. As I said, > I could make use of it as a build machine and for this it must run CURRENT > and no older versions. I will install the USB booted system to harddisk > and hope when booted from disk and not from USB the keyboard is working. >=20 if 7.4 still runs but not anything after 8.0, it is most likely what I have= written. Some USB hardware is not supported anymore in 8 and later. I would install the old one just to see You will also know wat hwardware i= s used there and how it is supported. This might be the faster route before starting debugging something which is= not there. Erich From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 00:53:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADED91065670 for ; Sun, 1 Jul 2012 00:53:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-scalar.mail.uoguelph.ca (esa-scalar.mail.uoguelph.ca [66.199.40.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7CACE8FC14 for ; Sun, 1 Jul 2012 00:53:20 +0000 (UTC) Received: from zcs3.mail.uoguelph.ca (new.mail.uoguelph.ca [131.104.93.37]) by esa-scalar.mail.uoguelph.ca (8.14.1/8.14.1) with ESMTP id q610r9KU009659; Sat, 30 Jun 2012 20:53:09 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7FA8AB4064; Sat, 30 Jun 2012 20:53:09 -0400 (EDT) Date: Sat, 30 Jun 2012 20:53:09 -0400 (EDT) From: Rick Macklem To: Vincent Hoffman Message-ID: <68594395.2439924.1341103989486.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4FECAD2C.8070402@unsane.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 00:53:20 -0000 Vincent Hoffman wrote: > Just a note to say I have tested this on -CURRENT with the new nfs > server and it is still the case. > > On the client (FreeBSD seaurchin 8.3-RELEASE-p3 FreeBSD 8.3-RELEASE-p3 > #0: Tue Jun 12 00:39:29 UTC 2012 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64) > > [root@seaurchin /mnt/nfs/vm]# date ; tar -cf foo.tar > /var/nfsen/profiles-data/ ; date > Thu Jun 28 20:12:36 BST 2012 > tar: Removing leading '/' from member names > tar: Write error > Thu Jun 28 20:12:38 BST 2012 > [root@seaurchin /mnt/nfs/vm]# > > > > on the Server > [root@fbsd /var/tmp]# uname -a ; date ; while true ; do mount /dev/md0 > /mnt/tmp/ ; umount /mnt/tmp ; done > FreeBSD fbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #22 r237646: Wed Jun 27 > 19:13:26 BST 2012 > toor@fbsd.bmk.namesco.net:/usr/obj/usr/src/sys/unsane-vm amd64 > Thu Jun 28 20:12:38 BST 2012 > ^C > [root@fbsd /var/tmp]# > > any suggestions welcome. > > Vince > > > On 27/06/2012 16:27, Vincent Hoffman wrote: > > Hi, > > After only one off-list reply from the author of kern/136865 (see > > below) > > after asking -questions, I thought it worth asking -CURRENT. > > Basically: > > > > I seem to have run into the problems described in this old thread. > > http://lists.freebsd.org/pipermail/freebsd-questions/2004-April/044927.html > > > > tl:dr mountd may give incorrect permission denied errors when it is > > refreshing the exports list due to non-atomic operations, > > /sbin/mount has code that sends SIGHUP to > > mountd on any mount operation, which implies that any manual mount > > request would cause the problem. > > > > Currently I have still only tested on 8.3-RELEASE but the svn log > > doesnt > > seem to mention a fix since then. I'm currently taking a VM up to > > -CURRENT to test. > > > > Looking though old PRs I see the following related. > > kern/131342 > > kern/136865 (with patch for 7.2 and links to > > http://nfse.sourceforge.net/ for -CURRENT ) > > > > Does anyone who is qualified (sadly not me) feel like looking at the > > code to see if its suitable for inclusion in part/whole as not > > having > > NFS transfers interrupted by local mount operations on the nfs > > server > > would be very handy :) > > I haven't looked at Andrey's patch, but conceptually it sounds like the best approach. As I understand it, the problem with replacing mountd with nfse (at least in the FreeBSD source tree) is that nfse is not 100% backwards compatible with /etc/exports and, as such, is a POLA violation. To modify mountd to use the kernel changes is more work than I have time for, in part because mountd.c is a very ugly old piece of C code, imho. I do have a patch that suspends/resumes execution of the nfsd threads (new, experimental for FreeBSD8.n only) when mountd reloads /etc/exports. This approach has certain disadvantages vs Andrey's transactional load/commit model, but it is simple and might be sufficient for your problem. If you want to try this patch, it is at: http://people.freebsd.org/~rmacklem/atomic-export.patch (The patch affects both the kernel and mountd.c.) Also, you could easily hack mount.c so that it doesn't send a SIGHUP to mountd (which causes the exports to be reloaded) every time a local fs is mounted. rick > > > > thanks, Vince > > > > > > _______________________________________________ > > 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" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 02:36:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22346106566C for ; Sun, 1 Jul 2012 02:36:06 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp.insight.synacor.com [208.47.185.22]) by mx1.freebsd.org (Postfix) with ESMTP id D9FB68FC17 for ; Sun, 1 Jul 2012 02:36:05 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=1.1 cv=JliV1TWavljy2htMhoUIMxhlgBLBqsUyu4r3EPHUlag= c=1 sm=0 a=190A9ldbhagA:10 a=jLN7EqiLvroA:10 a=sg0gfQ5U3qcR-Zv8BogA:9 a=Q/oqmR4JO1zR3vNQamCQeQ==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Authentication-Results: smtp01.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Received-SPF: softfail (smtp01.insight.synacor.com: transitional domain insightbb.com does not designate 74.134.26.53 as permitted sender) Received: from [74.134.26.53] ([74.134.26.53:58750] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id 61/60-17943-E87BFEF4; Sat, 30 Jun 2012 22:35:59 -0400 Date: Sat, 30 Jun 2012 22:35:58 -0400 Message-ID: <61.60.17943.E87BFEF4@smtp01.insight.synacor.com> From: "Thomas Mueller" To: freebsd-current@freebsd.org Cc: FreeBSD FS , Attilio Rao , Bob Friesenhahn Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 02:36:06 -0000 > You can not only run Linux on XFS (which I do) but it is still likely > the most reliable and consistently performant of the filesystems > available in Linux because of its origin and its maturity. XFS did > not originate in Linux (it originated in SGI's Irix) so it should not > surprise that Linux core developers are proponents of filesystems > originally developed under Linux. > Regardless, a key value of *BSD supporting non-native filesystems is > in order to be able to access filesystems created on other OSs. > XFS is a major filesystem so hopefully someone will volunteer to > support it. > Bob > -- > Bob Friesenhahn I remember starting threads, many months ago, both on FreeBSD and NetBSD lists about lingua franca file system for sharing data between OSes. I can see why NTFS support is important, due to its prevalence. But I believe very few people would have any use for HPFS access from BSD, and it would be practically impossible to find testers. Tom From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 04:36:13 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C8091065675; Sun, 1 Jul 2012 04:36:13 +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 E44E68FC1A; Sun, 1 Jul 2012 04:36:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q614a6Vv016910; Sun, 1 Jul 2012 00:36:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q614a6tj016909; Sun, 1 Jul 2012 04:36:06 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 1 Jul 2012 04:36:06 GMT Message-Id: <201207010436.q614a6tj016909@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 04:36:13 -0000 TB --- 2012-07-01 03:10:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-01 03:10:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-01 03:10:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-07-01 03:10:01 - cleaning the object tree TB --- 2012-07-01 03:14:01 - cvsupping the source tree TB --- 2012-07-01 03:14:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-07-01 03:14:39 - building world TB --- 2012-07-01 03:14:39 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 03:14:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 03:14:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 03:14:39 - SRCCONF=/dev/null TB --- 2012-07-01 03:14:39 - TARGET=arm TB --- 2012-07-01 03:14:39 - TARGET_ARCH=arm TB --- 2012-07-01 03:14:39 - TZ=UTC TB --- 2012-07-01 03:14:39 - __MAKE_CONF=/dev/null TB --- 2012-07-01 03:14:39 - cd /src TB --- 2012-07-01 03:14:39 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 1 03:14:39 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 1 04:17:57 UTC 2012 TB --- 2012-07-01 04:17:57 - cd /src/sys/arm/conf TB --- 2012-07-01 04:17:57 - /usr/sbin/config -m AVILA TB --- 2012-07-01 04:17:57 - skipping AVILA kernel TB --- 2012-07-01 04:17:57 - cd /src/sys/arm/conf TB --- 2012-07-01 04:17:57 - /usr/sbin/config -m BWCT TB --- 2012-07-01 04:17:57 - building BWCT kernel TB --- 2012-07-01 04:17:57 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 04:17:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 04:17:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 04:17:57 - SRCCONF=/dev/null TB --- 2012-07-01 04:17:57 - TARGET=arm TB --- 2012-07-01 04:17:57 - TARGET_ARCH=arm TB --- 2012-07-01 04:17:57 - TZ=UTC TB --- 2012-07-01 04:17:57 - __MAKE_CONF=/dev/null TB --- 2012-07-01 04:17:57 - cd /src TB --- 2012-07-01 04:17:57 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sun Jul 1 04:17:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Sun Jul 1 04:20:10 UTC 2012 TB --- 2012-07-01 04:20:10 - cd /src/sys/arm/conf TB --- 2012-07-01 04:20:10 - /usr/sbin/config -m CAMBRIA TB --- 2012-07-01 04:20:10 - skipping CAMBRIA kernel TB --- 2012-07-01 04:20:10 - cd /src/sys/arm/conf TB --- 2012-07-01 04:20:10 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-07-01 04:20:10 - building CNS11XXNAS kernel TB --- 2012-07-01 04:20:10 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 04:20:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 04:20:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 04:20:10 - SRCCONF=/dev/null TB --- 2012-07-01 04:20:10 - TARGET=arm TB --- 2012-07-01 04:20:10 - TARGET_ARCH=arm TB --- 2012-07-01 04:20:10 - TZ=UTC TB --- 2012-07-01 04:20:10 - __MAKE_CONF=/dev/null TB --- 2012-07-01 04:20:10 - cd /src TB --- 2012-07-01 04:20:10 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sun Jul 1 04:20:10 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Sun Jul 1 04:22:38 UTC 2012 TB --- 2012-07-01 04:22:38 - cd /src/sys/arm/conf TB --- 2012-07-01 04:22:38 - /usr/sbin/config -m CRB TB --- 2012-07-01 04:22:38 - skipping CRB kernel TB --- 2012-07-01 04:22:38 - cd /src/sys/arm/conf TB --- 2012-07-01 04:22:38 - /usr/sbin/config -m DB-78XXX TB --- 2012-07-01 04:22:38 - building DB-78XXX kernel TB --- 2012-07-01 04:22:38 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 04:22:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 04:22:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 04:22:38 - SRCCONF=/dev/null TB --- 2012-07-01 04:22:38 - TARGET=arm TB --- 2012-07-01 04:22:38 - TARGET_ARCH=arm TB --- 2012-07-01 04:22:38 - TZ=UTC TB --- 2012-07-01 04:22:38 - __MAKE_CONF=/dev/null TB --- 2012-07-01 04:22:38 - cd /src TB --- 2012-07-01 04:22:38 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sun Jul 1 04:22:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Sun Jul 1 04:25:28 UTC 2012 TB --- 2012-07-01 04:25:28 - cd /src/sys/arm/conf TB --- 2012-07-01 04:25:28 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-07-01 04:25:28 - building DB-88F5XXX kernel TB --- 2012-07-01 04:25:28 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 04:25:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 04:25:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 04:25:28 - SRCCONF=/dev/null TB --- 2012-07-01 04:25:28 - TARGET=arm TB --- 2012-07-01 04:25:28 - TARGET_ARCH=arm TB --- 2012-07-01 04:25:28 - TZ=UTC TB --- 2012-07-01 04:25:28 - __MAKE_CONF=/dev/null TB --- 2012-07-01 04:25:28 - cd /src TB --- 2012-07-01 04:25:28 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sun Jul 1 04:25:28 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Sun Jul 1 04:28:10 UTC 2012 TB --- 2012-07-01 04:28:10 - cd /src/sys/arm/conf TB --- 2012-07-01 04:28:10 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-07-01 04:28:10 - building DB-88F6XXX kernel TB --- 2012-07-01 04:28:10 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 04:28:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 04:28:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 04:28:10 - SRCCONF=/dev/null TB --- 2012-07-01 04:28:10 - TARGET=arm TB --- 2012-07-01 04:28:10 - TARGET_ARCH=arm TB --- 2012-07-01 04:28:10 - TZ=UTC TB --- 2012-07-01 04:28:10 - __MAKE_CONF=/dev/null TB --- 2012-07-01 04:28:10 - cd /src TB --- 2012-07-01 04:28:10 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sun Jul 1 04:28:10 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Sun Jul 1 04:31:03 UTC 2012 TB --- 2012-07-01 04:31:03 - cd /src/sys/arm/conf TB --- 2012-07-01 04:31:03 - /usr/sbin/config -m DOCKSTAR TB --- 2012-07-01 04:31:03 - building DOCKSTAR kernel TB --- 2012-07-01 04:31:03 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 04:31:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 04:31:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 04:31:03 - SRCCONF=/dev/null TB --- 2012-07-01 04:31:03 - TARGET=arm TB --- 2012-07-01 04:31:03 - TARGET_ARCH=arm TB --- 2012-07-01 04:31:03 - TZ=UTC TB --- 2012-07-01 04:31:03 - __MAKE_CONF=/dev/null TB --- 2012-07-01 04:31:03 - cd /src TB --- 2012-07-01 04:31:03 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sun Jul 1 04:31:03 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Sun Jul 1 04:33:37 UTC 2012 TB --- 2012-07-01 04:33:37 - cd /src/sys/arm/conf TB --- 2012-07-01 04:33:37 - /usr/sbin/config -m EP80219 TB --- 2012-07-01 04:33:37 - skipping EP80219 kernel TB --- 2012-07-01 04:33:37 - cd /src/sys/arm/conf TB --- 2012-07-01 04:33:37 - /usr/sbin/config -m ETHERNUT5 TB --- 2012-07-01 04:33:38 - building ETHERNUT5 kernel TB --- 2012-07-01 04:33:38 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 04:33:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 04:33:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 04:33:38 - SRCCONF=/dev/null TB --- 2012-07-01 04:33:38 - TARGET=arm TB --- 2012-07-01 04:33:38 - TARGET_ARCH=arm TB --- 2012-07-01 04:33:38 - TZ=UTC TB --- 2012-07-01 04:33:38 - __MAKE_CONF=/dev/null TB --- 2012-07-01 04:33:38 - cd /src TB --- 2012-07-01 04:33:38 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Sun Jul 1 04:33:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -mno-apcs-frame -ffreestanding -Werror /src/sys/geom/geom_kern.c cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -mno-apcs-frame -ffreestanding -Werror /src/sys/geom/geom_map.c cc1: warnings being treated as errors /src/sys/geom/geom_map.c: In function 'g_map_parse_part': /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 5 has type 'off_t' [-Wformat] *** Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-01 04:36:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-01 04:36:06 - ERROR: failed to build ETHERNUT5 kernel TB --- 2012-07-01 04:36:06 - 3286.76 user 706.73 system 5164.99 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 06:59:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41E69106564A for ; Sun, 1 Jul 2012 06:59:02 +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 BB3268FC08 for ; Sun, 1 Jul 2012 06:59:01 +0000 (UTC) Received: from [93.104.14.31] (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 1SlE7R-0005D2-IS; Sun, 01 Jul 2012 08:58:54 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id q616wpV7002714; Sun, 1 Jul 2012 08:58:51 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id q616woHu002713; Sun, 1 Jul 2012 08:58:50 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 1 Jul 2012 08:58:49 +0200 From: Matthias Apitz To: Erich Dollansky Message-ID: <20120701065849.GA2681@tinyCurrent> References: <20120629133422.GA2233@tiny.Sisis.de> <201206301349.58930.erich@alogreentechnologies.com> <20120630151130.GA1106@tiny.Sisis.de> <201207010629.29148.erich@alogreentechnologies.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201207010629.29148.erich@alogreentechnologies.com> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.14.31 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 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: Sun, 01 Jul 2012 06:59:02 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit El día Sunday, July 01, 2012 a las 06:29:28AM +0700, Erich Dollansky escribió: Hi, > > and no older versions. I will install the USB booted system to harddisk > > and hope when booted from disk and not from USB the keyboard is working. > > I installed the system r235646 to disk and it shows the same problem: no keyboard; > if 7.4 still runs but not anything after 8.0, it is most likely what I have written. Some USB hardware is not supported anymore in 8 and later. > > I would install the old one just to see You will also know wat hwardware is used there and how it is supported. > > This might be the faster route before starting debugging something which is not there. I said already that it works with a r214444 version, CURRENT from October 2010; so I booted this again and concerning keyboard, here is the diff: r214444: $ fgrep -i kb /tmp/dmesg-r214444.txt kbd1 at kbdmux0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 $ ls -l /dev/kb* lrwxr-xr-x 1 root wheel 6 Jul 1 08:39 /dev/kbd0 -> atkbd0 lrwxr-xr-x 1 root wheel 7 Jul 1 08:39 /dev/kbd1 -> kbdmux0 crw------- 1 root wheel 0, 17 Jul 1 08:39 /dev/kbdmux0 r235646: $ fgrep -i kb /tmp/dmesg-r235646.txt atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) atkbdc0 failed to probe at port 0x60 on isa0 $ ls -l /dev/kb* lrwxr-xr-x 1 root wheel 7 Jul 1 08:39 /dev/kbd1 -> kbdmux0 crw------- 1 root wheel 0, 17 Jul 1 08:39 /dev/kbdmux0 the complete /tmp/dmesg-r214444.txt is attached, the /tmp/dmesg-r235646.txt was in some message of this thread; So the question is: why the is not detected anymore in r235646, while it is in r214444? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg-r214444.txt" Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #1 r214444: Thu Oct 28 10:56:32 CEST 2010 guru@current.Sisis.de:/usr/home/guru/myThings/FreeBSD/9-CURRENT/obj/usr/home/guru/myThings/FreeBSD/9-CURRENT/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.34-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Family = f Model = 2 Stepping = 7 Features=0xbfebfbff Features2=0x4400 real memory = 1073741824 (1024 MB) avail memory = 1031737344 (983 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xb000-0xb0ff mem 0xd0000000-0xd7ffffff,0xffcf0000-0xffcfffff irq 16 at device 0.0 on pci1 uhci0: port 0xdf20-0xdf3f irq 16 at device 29.0 on pci0 uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xdf40-0xdf5f irq 19 at device 29.1 on pci0 uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xdf80-0xdf9f irq 18 at device 29.2 on pci0 uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xffeffc00-0xffefffff irq 23 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3: on ehci0 pcib2: at device 30.0 on pci0 pci2: on pcib2 cbb0: at device 3.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: port 0xcc00-0xcc7f mem 0xffdff800-0xffdfffff irq 18 at device 10.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:03:0d:49:75:50:7a:e8 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:03:0d:50:7a:e8 fwe0: Ethernet address: 02:03:0d:50:7a:e8 fwip0: on firewire0 fwip0: Firewire address: 00:03:0d:49:75:50:7a:e8 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x14ac000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode sis0: port 0xc800-0xc8ff mem 0xffdfe000-0xffdfefff irq 17 at device 12.0 on pci2 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:a0:cc:df:75:57 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 acpi_lid0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 p4tcc0: on cpu0 Timecounter "TSC" frequency 2398341748 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ad0: 76319MB at ata0-master UDMA100 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 acd0: CDRW at ata1-master UDMA33 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen3.2: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:1:0:-1: Attached to scbus1 da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 7560MB (15482880 512 byte sectors: 255H 63S/T 963C) WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/da0s1a [rw]... --nFreZHaLTZJo0R7j-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 07:52:11 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83DC41065680; Sun, 1 Jul 2012 07:52:11 +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 486E78FC17; Sun, 1 Jul 2012 07:52:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q617qATc027673; Sun, 1 Jul 2012 03:52:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q617qAut027668; Sun, 1 Jul 2012 07:52:10 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 1 Jul 2012 07:52:10 GMT Message-Id: <201207010752.q617qAut027668@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 07:52:11 -0000 TB --- 2012-07-01 06:32:40 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-01 06:32:40 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-01 06:32:40 - starting HEAD tinderbox run for mips/mips TB --- 2012-07-01 06:32:40 - cleaning the object tree TB --- 2012-07-01 06:33:44 - cvsupping the source tree TB --- 2012-07-01 06:33:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-07-01 06:34:27 - building world TB --- 2012-07-01 06:34:27 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 06:34:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 06:34:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 06:34:27 - SRCCONF=/dev/null TB --- 2012-07-01 06:34:27 - TARGET=mips TB --- 2012-07-01 06:34:27 - TARGET_ARCH=mips TB --- 2012-07-01 06:34:27 - TZ=UTC TB --- 2012-07-01 06:34:27 - __MAKE_CONF=/dev/null TB --- 2012-07-01 06:34:27 - cd /src TB --- 2012-07-01 06:34:27 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 1 06:34:28 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 1 07:50:44 UTC 2012 TB --- 2012-07-01 07:50:44 - cd /src/sys/mips/conf TB --- 2012-07-01 07:50:44 - /usr/sbin/config -m ADM5120 TB --- 2012-07-01 07:50:44 - skipping ADM5120 kernel TB --- 2012-07-01 07:50:44 - cd /src/sys/mips/conf TB --- 2012-07-01 07:50:44 - /usr/sbin/config -m ALCHEMY TB --- 2012-07-01 07:50:44 - skipping ALCHEMY kernel TB --- 2012-07-01 07:50:44 - cd /src/sys/mips/conf TB --- 2012-07-01 07:50:44 - /usr/sbin/config -m AP93 TB --- 2012-07-01 07:50:44 - building AP93 kernel TB --- 2012-07-01 07:50:44 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 07:50:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 07:50:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 07:50:44 - SRCCONF=/dev/null TB --- 2012-07-01 07:50:44 - TARGET=mips TB --- 2012-07-01 07:50:44 - TARGET_ARCH=mips TB --- 2012-07-01 07:50:44 - TZ=UTC TB --- 2012-07-01 07:50:44 - __MAKE_CONF=/dev/null TB --- 2012-07-01 07:50:44 - cd /src TB --- 2012-07-01 07:50:44 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Sun Jul 1 07:50:45 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_kern.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_map.c cc1: warnings being treated as errors /src/sys/geom/geom_map.c: In function 'g_map_parse_part': /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat] /src/sys/geom/geom_map.c:327: warning: format '%lx' expects type 'long unsigned int', but argument 5 has type 'off_t' [-Wformat] *** Error code 1 Stop in /obj/mips.mips/src/sys/AP93. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-01 07:52:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-01 07:52:10 - ERROR: failed to build AP93 kernel TB --- 2012-07-01 07:52:10 - 2598.96 user 558.96 system 4770.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 08:37:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99CE0106566B for ; Sun, 1 Jul 2012 08:37:49 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 205C48FC12 for ; Sun, 1 Jul 2012 08:37:48 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 293448777; Sun, 01 Jul 2012 10:37:41 +0200 From: Hans Petter Selasky To: Erich Dollansky Date: Sun, 1 Jul 2012 10:37:33 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20120629133422.GA2233@tiny.Sisis.de> <20120630151130.GA1106@tiny.Sisis.de> <201207010629.29148.erich@alogreentechnologies.com> In-Reply-To: <201207010629.29148.erich@alogreentechnologies.com> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@ =?iso-8859-1?q?d2+AyewRX=7DmAm=3BYp=0A=09=7CU=5B?=@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y> =?iso-8859-1?q?Y=7Dk1C4TfysrsUI=0A=09-=25GU9V5=5DiUZF=26nRn9mJ=27=3F=26?=>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201207011037.33605.hselasky@c2i.net> Cc: Matthias Apitz , freebsd-current@freebsd.org Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 08:37:49 -0000 On Sunday 01 July 2012 01:29:28 Erich Dollansky wrote: > Hi, >=20 > On Saturday, June 30, 2012 10:11:31 PM Matthias Apitz wrote: > > El d=EDa Saturday, June 30, 2012 a las 01:49:58PM +0700, Erich Dollansk= y=20 escribi=F3: > > > Can you try FreeBSD 7.4 or 8.3? > > >=20 > > > It is sad to say but some times support for older hardware gets cut o= ut > > > for whatever reason. > >=20 > > The IT guy of my company found this laptop in the attic and because > > it has no Wifi, nobody is interested in using it anymore. As I said, > > I could make use of it as a build machine and for this it must run > > CURRENT and no older versions. I will install the USB booted system to > > harddisk and hope when booted from disk and not from USB the keyboard is > > working. >=20 > if 7.4 still runs but not anything after 8.0, it is most likely what I ha= ve > written. Some USB hardware is not supported anymore in 8 and later. >=20 > I would install the old one just to see You will also know wat hwardware > is used there and how it is supported. >=20 > This might be the faster route before starting debugging something which = is > not there. >=20 > Erich Try to compare pciconf -lv and dmesg. =2D-HPS From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 09:20:31 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3D1B106564A for ; Sun, 1 Jul 2012 09:20:31 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 882638FC08 for ; Sun, 1 Jul 2012 09:20:31 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 1952125D38A0 for ; Sun, 1 Jul 2012 09:20:24 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 16168BD4001 for ; Sun, 1 Jul 2012 09:20:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id PznZjAPlkQv9 for ; Sun, 1 Jul 2012 09:20:23 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id E8D0BBD3FFE for ; Sun, 1 Jul 2012 09:20:22 +0000 (UTC) From: "Bjoern A. Zeeb" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Jul 2012 09:20:21 +0000 Message-Id: To: current@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Subject: SVN2CVS exporter down X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 09:20:31 -0000 Just FYI, the svn2cvs exporter is currently down due to = http://svn.freebsd.org/changeset/base/237860 . I'll fix it as soon as I get back from lunch, so should be back in a few = hours. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 10:14:50 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 132AA1065674; Sun, 1 Jul 2012 10:14:50 +0000 (UTC) (envelope-from simon@FreeBSD.org) Received: from emx.nitro.dk (emx.nitro.dk [IPv6:2a01:4f8:120:7384::102]) by mx1.freebsd.org (Postfix) with ESMTP id C3B618FC1B; Sun, 1 Jul 2012 10:14:49 +0000 (UTC) Received: from mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) by emx.nitro.dk (Postfix) with ESMTP id 298DE20103A; Sun, 1 Jul 2012 10:14:49 +0000 (UTC) Received: from emx.nitro.dk ([127.0.1.2]) by mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) (amavisd-new, port 10024) with LMTP id SBNezAODyOsz; Sun, 1 Jul 2012 10:14:47 +0000 (UTC) Received: from [192.168.4.32] (unknown [89.100.2.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by emx.nitro.dk (Postfix) with ESMTPSA id B9318201037; Sun, 1 Jul 2012 10:14:46 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Simon L. B. Nielsen" In-Reply-To: Date: Sun, 1 Jul 2012 11:14:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2A1FD996-9AB7-4F8D-B22D-0B3F0437C0F2@FreeBSD.org> References: To: Bjoern A. Zeeb X-Mailer: Apple Mail (2.1278) Cc: current@FreeBSD.org Subject: Re: SVN2CVS exporter down X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 10:14:50 -0000 On 1 Jul 2012, at 10:20, Bjoern A. Zeeb wrote: > Just FYI, >=20 > the svn2cvs exporter is currently down due to = http://svn.freebsd.org/changeset/base/237860 . > I'll fix it as soon as I get back from lunch, so should be back in a = few hours. Fixed. Please try not to replace files or even worse directories. = Thanks. --=20 Simon L. B. Nielsen From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 11:13:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96F6F106566B for ; Sun, 1 Jul 2012 11:13:36 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id B334A8FC14 for ; Sun, 1 Jul 2012 11:13:35 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q61BDW1C075709 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 1 Jul 2012 12:13:33 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FF030DA.8030304@unsane.co.uk> Date: Sun, 01 Jul 2012 12:13:30 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rick Macklem References: <68594395.2439924.1341103989486.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <68594395.2439924.1341103989486.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 11:13:36 -0000 On 01/07/2012 01:53, Rick Macklem wrote: > Vincent Hoffman wrote: >> Just a note to say I have tested this on -CURRENT with the new nfs >> server and it is still the case. >> >> On the client (FreeBSD seaurchin 8.3-RELEASE-p3 FreeBSD 8.3-RELEASE-p3 >> #0: Tue Jun 12 00:39:29 UTC 2012 >> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64) >> >> [root@seaurchin /mnt/nfs/vm]# date ; tar -cf foo.tar >> /var/nfsen/profiles-data/ ; date >> Thu Jun 28 20:12:36 BST 2012 >> tar: Removing leading '/' from member names >> tar: Write error >> Thu Jun 28 20:12:38 BST 2012 >> [root@seaurchin /mnt/nfs/vm]# >> >> >> >> on the Server >> [root@fbsd /var/tmp]# uname -a ; date ; while true ; do mount /dev/md0 >> /mnt/tmp/ ; umount /mnt/tmp ; done >> FreeBSD fbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #22 r237646: Wed Jun 27 >> 19:13:26 BST 2012 >> toor@fbsd.bmk.namesco.net:/usr/obj/usr/src/sys/unsane-vm amd64 >> Thu Jun 28 20:12:38 BST 2012 >> ^C >> [root@fbsd /var/tmp]# >> >> any suggestions welcome. >> >> Vince >> >> >> On 27/06/2012 16:27, Vincent Hoffman wrote: >>> Hi, >>> After only one off-list reply from the author of kern/136865 (see >>> below) >>> after asking -questions, I thought it worth asking -CURRENT. >>> Basically: >>> >>> I seem to have run into the problems described in this old thread. >>> http://lists.freebsd.org/pipermail/freebsd-questions/2004-April/044927.html >>> >>> tl:dr mountd may give incorrect permission denied errors when it is >>> refreshing the exports list due to non-atomic operations, >>> /sbin/mount has code that sends SIGHUP to >>> mountd on any mount operation, which implies that any manual mount >>> request would cause the problem. >>> >>> Currently I have still only tested on 8.3-RELEASE but the svn log >>> doesnt >>> seem to mention a fix since then. I'm currently taking a VM up to >>> -CURRENT to test. >>> >>> Looking though old PRs I see the following related. >>> kern/131342 >>> kern/136865 (with patch for 7.2 and links to >>> http://nfse.sourceforge.net/ for -CURRENT ) >>> >>> Does anyone who is qualified (sadly not me) feel like looking at the >>> code to see if its suitable for inclusion in part/whole as not >>> having >>> NFS transfers interrupted by local mount operations on the nfs >>> server >>> would be very handy :) >>> > I haven't looked at Andrey's patch, but conceptually it sounds like > the best approach. As I understand it, the problem with replacing > mountd with nfse (at least in the FreeBSD source tree) is that nfse > is not 100% backwards compatible with /etc/exports and, as such, is > a POLA violation. Understood. Its far from a simple drop in replacement. > > To modify mountd to use the kernel changes is more work than I have > time for, in part because mountd.c is a very ugly old piece of C code, imho. > > I do have a patch that suspends/resumes execution of the nfsd threads > (new, experimental for FreeBSD8.n only) when mountd reloads /etc/exports. > This approach has certain disadvantages vs Andrey's transactional load/commit > model, but it is simple and might be sufficient for your problem. > If you want to try this patch, it is at: > http://people.freebsd.org/~rmacklem/atomic-export.patch > (The patch affects both the kernel and mountd.c.) Happy to try it, to be certain I have understood, this is for the newnfs server (experimental in 8.x default for 8 9+) I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm when i get a minute. > > Also, you could easily hack mount.c so that it doesn't send a SIGHUP > to mountd (which causes the exports to be reloaded) every time a local > fs is mounted. True and I may have to do that for the production NAS for the time being. Thanks for looking at this. Vince > > rick > >>> thanks, Vince >>> >>> >>> _______________________________________________ >>> 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" >> >> _______________________________________________ >> 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" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 10:18:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FA121065673 for ; Sun, 1 Jul 2012 10:18:05 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm8.bullet.mail.ird.yahoo.com (nm8.bullet.mail.ird.yahoo.com [77.238.189.23]) by mx1.freebsd.org (Postfix) with SMTP id C81F38FC1A for ; Sun, 1 Jul 2012 10:18:04 +0000 (UTC) Received: from [77.238.189.234] by nm8.bullet.mail.ird.yahoo.com with NNFMP; 01 Jul 2012 10:18:03 -0000 Received: from [217.146.189.246] by tm15.bullet.mail.ird.yahoo.com with NNFMP; 01 Jul 2012 10:18:03 -0000 Received: from [127.0.0.1] by smtp111.mail.ird.yahoo.com with NNFMP; 01 Jul 2012 10:18:03 -0000 X-Yahoo-Newman-Id: 600877.35538.bm@smtp111.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cvcCQvwVM1nfdEv6tz51PK1O3y6oBHSe4cOoORYUHZUxs4v s0eaxaABAzpiO593u2LoULxJwOH87OBwW__ZphfCp2k2r95ZrNdPiHjjIP4U a_c9ouGFJo4bKWPQaLM188i7ai0CZIPigSCKM_p47lINsgIBYUdo1GLYAmcn jUhbcKJxuw2.trourhIGup4I2d5rcH3xHk.qms.kBPAEIyR43aB40erxLHAx IpWEylkywqN.te5FO2yW9qY.b5FGlgvmKPeLFsO4sZGaxdG6cNWVh8J0kwu2 9IkPRBKEftVjztOB.Ub0j4JcUWJtEk6Oo2wKmC79WMxEudzCKSy3tLKdU8qh 6CI3gIXmAhfHoeQYRYQ9YRnVgNV6i0M91Z83KLGwhEen_oSnnIg3.ki0vXto CuvPRBVOny9ALcMBc.QM1B0qaoHXKUYFsYYNsAbTOzaD11rL714pw3hp2HlN L8GCQk45Z8Aa6pISRNha_WXRb625vezYVero.EJ8N5odkTWjVWBKgxZjiSl7 4h7TviT9hdWfvIyMjlgzODsd3Ou5wzwO7tvPt1NVUCAF45L8bb15UIPJLmPk alsNUe8pll.Pp2kJRkuYAlGTDJlJ3UPKH8EK8CW3bzXe1HcXhtkDA.hk- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.11] (se@81.173.144.247 with plain) by smtp111.mail.ird.yahoo.com with SMTP; 01 Jul 2012 03:18:03 -0700 PDT Message-ID: <4FF023DF.8000003@freebsd.org> Date: Sun, 01 Jul 2012 12:18:07 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: FreeBSD developers References: <4FEAA3C1.2040807@freebsd.org> <4FECBBC1.3000800@freebsd.org> In-Reply-To: <4FECBBC1.3000800@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 01 Jul 2012 11:17:57 +0000 Cc: Subject: [RFT/RFC]: Please test NSCD patch (was: Re: [PATCH] Fix for negative cacheing problem in NSCD) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 10:18:05 -0000 [Since I did not receive any feedback on my previous message to the -hackers list, I try again and CC: to -current in the hope to attract more interest ...] The NSCD patch attached to the previous mail, which can be found at: http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg164538.html It fixes an often reported problem with negative cacheing in NSCD: E.g. when a new user account is created, there is a query for this username to give a meaningful reply to the user, if that username has been choosen before. The query result is cached, and if the username was not found and a new account is created, NSCD does not notice and returns the "user does not exist" result for the cache's time-to-live duration that is configured for negative queries (default is 60 seconds, could be increased when the patch is applied). The patch fixes the scenario given by marking the first negative reply as preliminary result and requires further queries to the original data source to deliver the same result before the cached value is used and the data source is not queried again. I'd want to commit this patch to -CURRENT within the next week, if there are no objections. The patch does not violate POLA, since it does not change the behavior without an additional configuration line in /etc/nscd.conf. Before I commit the patch I'd appreciate the following feedback: 1) Does it work for you with your data sources (e.g. LDAP) (The patch has worked on my box in the cases I tested.) 2) Should the defaults be changed, e.g. the negative confidence threshold could be set to 3 with a timeout of 10 minutes instead of the current values of 1 and 1 minute. (I plan to commit the change without change to the defaults to prevent a violation of POLA, unless there are strong arguments in favor of changed defaults.) 3) Is there a better name for the new option? I used "negative-confidence-threshold" since I could not think of a simpler/shorter name to express its purpose. 4) Is the patch to the man page comprehensible? Any suggestions to improve the wording? 5) I also added support for retries on positive cache results, which might for example help with DNS based load balancing. For example "positive-confidence-threshold hosts 4" will require 4 identical DNS replies before the cache trusts its contents and stops sending DNS queries. This may or may not be useful; the feature came at negligible cost, and so I kept it in the attached patch, but might as well commit a stripped down version that only supports negative cacheing. The patch was attached to my previous mail and is also available from: http://people.freebsd.org/~se/nscd-Negative-Threshold.patch Regards, STefan From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 11:19:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2319B1065675 for ; Sun, 1 Jul 2012 11:19:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-scalar.mail.uoguelph.ca (esa-scalar.mail.uoguelph.ca [66.199.40.18]) by mx1.freebsd.org (Postfix) with ESMTP id D8DE78FC18 for ; Sun, 1 Jul 2012 11:19:01 +0000 (UTC) Received: from zcs3.mail.uoguelph.ca (new.mail.uoguelph.ca [131.104.93.37]) by esa-scalar.mail.uoguelph.ca (8.14.1/8.14.1) with ESMTP id q61BIx5K004187; Sun, 1 Jul 2012 07:18:59 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 17ECFB4018; Sun, 1 Jul 2012 07:18:59 -0400 (EDT) Date: Sun, 1 Jul 2012 07:18:59 -0400 (EDT) From: Rick Macklem To: Vincent Hoffman Message-ID: <497527423.2441665.1341141539082.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4FF030DA.8030304@unsane.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 11:19:02 -0000 Vincent Hoffman wrote: > On 01/07/2012 01:53, Rick Macklem wrote: > > Vincent Hoffman wrote: > >> Just a note to say I have tested this on -CURRENT with the new nfs > >> server and it is still the case. > >> > >> On the client (FreeBSD seaurchin 8.3-RELEASE-p3 FreeBSD > >> 8.3-RELEASE-p3 > >> #0: Tue Jun 12 00:39:29 UTC 2012 > >> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > >> amd64) > >> > >> [root@seaurchin /mnt/nfs/vm]# date ; tar -cf foo.tar > >> /var/nfsen/profiles-data/ ; date > >> Thu Jun 28 20:12:36 BST 2012 > >> tar: Removing leading '/' from member names > >> tar: Write error > >> Thu Jun 28 20:12:38 BST 2012 > >> [root@seaurchin /mnt/nfs/vm]# > >> > >> > >> > >> on the Server > >> [root@fbsd /var/tmp]# uname -a ; date ; while true ; do mount > >> /dev/md0 > >> /mnt/tmp/ ; umount /mnt/tmp ; done > >> FreeBSD fbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #22 r237646: Wed Jun > >> 27 > >> 19:13:26 BST 2012 > >> toor@fbsd.bmk.namesco.net:/usr/obj/usr/src/sys/unsane-vm amd64 > >> Thu Jun 28 20:12:38 BST 2012 > >> ^C > >> [root@fbsd /var/tmp]# > >> > >> any suggestions welcome. > >> > >> Vince > >> > >> > >> On 27/06/2012 16:27, Vincent Hoffman wrote: > >>> Hi, > >>> After only one off-list reply from the author of kern/136865 (see > >>> below) > >>> after asking -questions, I thought it worth asking -CURRENT. > >>> Basically: > >>> > >>> I seem to have run into the problems described in this old thread. > >>> http://lists.freebsd.org/pipermail/freebsd-questions/2004-April/044927.html > >>> > >>> tl:dr mountd may give incorrect permission denied errors when it > >>> is > >>> refreshing the exports list due to non-atomic operations, > >>> /sbin/mount has code that sends SIGHUP to > >>> mountd on any mount operation, which implies that any manual mount > >>> request would cause the problem. > >>> > >>> Currently I have still only tested on 8.3-RELEASE but the svn log > >>> doesnt > >>> seem to mention a fix since then. I'm currently taking a VM up to > >>> -CURRENT to test. > >>> > >>> Looking though old PRs I see the following related. > >>> kern/131342 > >>> kern/136865 (with patch for 7.2 and links to > >>> http://nfse.sourceforge.net/ for -CURRENT ) > >>> > >>> Does anyone who is qualified (sadly not me) feel like looking at > >>> the > >>> code to see if its suitable for inclusion in part/whole as not > >>> having > >>> NFS transfers interrupted by local mount operations on the nfs > >>> server > >>> would be very handy :) > >>> > > I haven't looked at Andrey's patch, but conceptually it sounds like > > the best approach. As I understand it, the problem with replacing > > mountd with nfse (at least in the FreeBSD source tree) is that nfse > > is not 100% backwards compatible with /etc/exports and, as such, is > > a POLA violation. > Understood. Its far from a simple drop in replacement. > > > > To modify mountd to use the kernel changes is more work than I have > > time for, in part because mountd.c is a very ugly old piece of C > > code, imho. > > > > I do have a patch that suspends/resumes execution of the nfsd > > threads > > (new, experimental for FreeBSD8.n only) when mountd reloads > > /etc/exports. > > This approach has certain disadvantages vs Andrey's transactional > > load/commit > > model, but it is simple and might be sufficient for your problem. > > If you want to try this patch, it is at: > > http://people.freebsd.org/~rmacklem/atomic-export.patch > > (The patch affects both the kernel and mountd.c.) > Happy to try it, to be certain I have understood, this is for the > newnfs > server (experimental in 8.x default for 8 > 9+) Yes, that is correct. For the old (default on 8.x) it will have no effect. > I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm when > i > get a minute. Also, to enable it, you must add a "-S" flag to mountd_flags, after you've replaced the mountd executable. The patch is pretty straightforward, but has not seen much testing. Hopefully, it might be useful for you, rick > > > > Also, you could easily hack mount.c so that it doesn't send a SIGHUP > > to mountd (which causes the exports to be reloaded) every time a > > local > > fs is mounted. > True and I may have to do that for the production NAS for the time > being. > Thanks for looking at this. > > Vince > > > > rick > > > >>> thanks, Vince > >>> > >>> > >>> _______________________________________________ > >>> 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" > >> > >> _______________________________________________ > >> 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" > > _______________________________________________ > > 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" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 12:23:37 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5D6C106566B for ; Sun, 1 Jul 2012 12:23:37 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 898FA8FC08 for ; Sun, 1 Jul 2012 12:23:37 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A5AA225D3872 for ; Sun, 1 Jul 2012 12:23:36 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 94FBCBD4001 for ; Sun, 1 Jul 2012 12:23:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id FobdBrGlzDsK for ; Sun, 1 Jul 2012 12:23:34 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 10E42BD3FFE for ; Sun, 1 Jul 2012 12:23:33 +0000 (UTC) From: "Bjoern A. Zeeb" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Jul 2012 12:23:31 +0000 Message-Id: <7BEE3948-EE35-48C2-B4B1-25E34087A4C4@lists.zabbadoz.net> To: current@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Subject: swp_pager_meta_build DoS printf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 12:23:37 -0000 Hey, hitting this printf in swp_pager_meta_build() if (uma_zone_exhausted(swap_zone)) { printf("swap zone exhausted, increase = kern.maxswzone\n"); vm_pageout_oom(VM_OOM_SWAPZ); pause("swzonex", 10); } else seems to be an effective way to put the machine into a state of no = recovery unless the memory situation would be able to clear itself. Not that it = wouldn't otherwise be any better but in addition having a couple of tenthousands = of these going to console as well is really not helpful to try to do anything = either. Can we make it a log() call or something? /bz PS: I am not sure as I have seen it on someone else's machines and it's probably been ZFS that caused it. I unfortunately neither had a way to get back in or break to a kernel debugger, so information is sparse. --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 12:52:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2B64106564A for ; Sun, 1 Jul 2012 12:52:21 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 656BC8FC14 for ; Sun, 1 Jul 2012 12:52:21 +0000 (UTC) Received: by vbmv11 with SMTP id v11so3768286vbm.13 for ; Sun, 01 Jul 2012 05:52:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=R7dmhUfaFLwDzEU+V8I12kPkQK7K5hoab9yFaA5/P/s=; b=kMIstFjXURX9PriMr9eXOOkatfcZ1MiiDBO72dZ/tCjRex0Y56vr+AgQZS8Z6yUMXd y5gT+FUHjeU2wmUDHn/J0FZmMgscfXQbUzxaGtb6/EmLCyIcOrTA6WdbYII2R8rkgN56 vxzjHhXNddmkCzh/e/akh3crGhyBNb04ZE0OUaat30NE8sKk61BUU5/98CXLfPFry23n L9ik6yZiQrCA/IfbLOFDTbUUZtvDRagECs45zHc6cdtUXhYrK0D6bnujLxSwFHwApnqb fzjuiIIQSNCt6wfqaUexQ9BVhIg/y1WOuq3sdOyM2LdotssWsEMCri0jRa3Pt/PO71hB BvsA== MIME-Version: 1.0 Received: by 10.220.218.141 with SMTP id hq13mr4487656vcb.8.1341147134790; Sun, 01 Jul 2012 05:52:14 -0700 (PDT) Received: by 10.220.240.197 with HTTP; Sun, 1 Jul 2012 05:52:14 -0700 (PDT) X-Originating-IP: [93.221.178.61] In-Reply-To: References: Date: Sun, 1 Jul 2012 14:52:14 +0200 Message-ID: From: "C. P. Ghost" To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlBsprDT0lDDEfpX/CUZq64NG+vlFEIZm7Q/8J7fDX03zpxOZwxmFoIrdXMB3w3THPsn+bd Cc: FreeBSD FS , freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 12:52:21 -0000 On Fri, Jun 29, 2012 at 10:32 PM, Attilio Rao wrote: > As already published several times, according to the following plan: > http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS > > in 2 months the code dealing with non-MPSAFE filesystem will be > removed and filesystems not yet MPSAFE will be disconnected from the > tree. Their code will be however available in our official repository > yet for 6 months. This leaves a total time of 8 months to do actions. > > Current list of unmantained filesystems is: HPFS, NWFS, PortalFS and > XFS. Coda and SMBFS have current mantainership but the status of the > work has still to be determined. NTFS, is being worked for the Summer > of Code program. Finally, ReiserFS was successfully locked during this > campaign. Sorry if this has been discussed already, but... it's one thing to obsolete some code, it's a different thing to remove it entirely where there's no user-level replacement, especially since it would also remove the ability to access ancient media that some people may still have access to. Couldn't filesystems that are still not MP SAFE be kept in the tree in such a way that they at least provide read-only access in case of emergencies? > It is time for community members to step up and offer time and skills > to lock a filesystem or test the effort of other developers willing to > do so. I don't have the skills for that, but I'd love to see some brave soul step up to rescue PortalFS. ;-) > Thanks, > Attilio Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 13:52:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A964106566B; Sun, 1 Jul 2012 13:52:07 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8FD368FC0A; Sun, 1 Jul 2012 13:52:06 +0000 (UTC) Received: by lbon10 with SMTP id n10so8085018lbo.13 for ; Sun, 01 Jul 2012 06:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZyqLcgTbvH8XtoJ1UYt4UB/CiaZeZ8hzjvy8/45mjnw=; b=cP+ZUWiiGL/SmuejbdFmuuJZvkJQBXwEfuoySqsOuVBsBpgirTNv+/MR8kJBuj3vTD e/9Gi4Ds2Dtve9/Ot6E5ZrLFLUcPJStaYDqjL5Bcu1L62JhRrF2bbqzj24+xNhztzUHO UuJJfB69OPUVN1cFjF/JUR+qlQhctKOG9A+j+aIbQgbOT6S7Blwnu1vv3qs8GRV4buoF RO2sogEDVvpomv/cPAfJquskyp4qi3N0QHRKPBC2DXj01BmRgNaa3pKOhAX54fuEtCeD F4AhJCBtS0fxnNzI2jqlN+QxOkMxPEH8us6GjfTia3zaFrJl+UUcR0oxhD2PM2+KhJIf rKHA== MIME-Version: 1.0 Received: by 10.152.46.6 with SMTP id r6mr9347323lam.7.1341150725329; Sun, 01 Jul 2012 06:52:05 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Sun, 1 Jul 2012 06:52:05 -0700 (PDT) In-Reply-To: References: Date: Sun, 1 Jul 2012 15:52:05 +0200 X-Google-Sender-Auth: 3KKjJXsWWzgtQuJq8SQUHw9VyQw Message-ID: From: Attilio Rao To: "C. P. Ghost" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD FS , freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 13:52:07 -0000 2012/7/1 C. P. Ghost : > On Fri, Jun 29, 2012 at 10:32 PM, Attilio Rao wrote: >> As already published several times, according to the following plan: >> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS >> >> in 2 months the code dealing with non-MPSAFE filesystem will be >> removed and filesystems not yet MPSAFE will be disconnected from the >> tree. Their code will be however available in our official repository >> yet for 6 months. This leaves a total time of 8 months to do actions. >> >> Current list of unmantained filesystems is: HPFS, NWFS, PortalFS and >> XFS. Coda and SMBFS have current mantainership but the status of the >> work has still to be determined. NTFS, is being worked for the Summer >> of Code program. Finally, ReiserFS was successfully locked during this >> campaign. > > Sorry if this has been discussed already, but... > > it's one thing to obsolete some code, it's a different thing to > remove it entirely where there's no user-level replacement, > especially since it would also remove the ability to access > ancient media that some people may still have access to. > > Couldn't filesystems that are still not MP SAFE be kept in the > tree in such a way that they at least provide read-only access > in case of emergencies? Unfortunately not. First of all, they are mostly already READ-ONLY, in particular XFS and NTFS. Second, it would be meaning leave in place the Giant-VFS bloat that we necessarilly must get rid of. The most interesting ones in the list, IMHO, are still SMBFS and NTFS and possibly XFS (but this is really a personal preference). I've received an e-mail explaining that there are arrangements by a company to put their developers on work after 1st september on SMBFS locking which is certainly a good new, but I still haven't heard anything by SoC involved people about NTFS and certainly I don't see a plan to get XFS locked. However remind that at the worst (for filesystems like PortalFS, for example) the code will remain in Attic even after it gets depurated and then it can be revitalized and locked in whatever point in the future. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 15:07:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C6AF1065691 for ; Sun, 1 Jul 2012 15:07:41 +0000 (UTC) (envelope-from erich@alogreentechnologies.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id BD1BF8FC1A for ; Sun, 1 Jul 2012 15:07:40 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.29]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q617HLZD005387; Sun, 1 Jul 2012 01:17:23 -0600 From: Erich Dollansky Organization: ALO Green Technologies To: Matthias Apitz Date: Sun, 1 Jul 2012 14:17:20 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) References: <20120629133422.GA2233@tiny.Sisis.de> <201207010629.29148.erich@alogreentechnologies.com> <20120701065849.GA2681@tinyCurrent> In-Reply-To: <20120701065849.GA2681@tinyCurrent> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201207011417.20527.erich@alogreentechnologies.com> X-Mailman-Approved-At: Sun, 01 Jul 2012 15:26:04 +0000 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 15:07:41 -0000 Hi, On Sunday, July 01, 2012 01:58:49 PM Matthias Apitz wrote: > El d=EDa Sunday, July 01, 2012 a las 06:29:28AM +0700, Erich Dollansky es= cribi=F3: >=20 > > > and no older versions. I will install the USB booted system to harddi= sk > > > and hope when booted from disk and not from USB the keyboard is worki= ng. > > >=20 >=20 > I installed the system r235646 to disk and it shows the same problem: no > keyboard; >=20 ok. > > if 7.4 still runs but not anything after 8.0, it is most likely what I = have written. Some USB hardware is not supported anymore in 8 and later. > >=20 > > I would install the old one just to see You will also know wat hwardwa= re is used there and how it is supported. > >=20 > > This might be the faster route before starting debugging something whic= h is not there. >=20 > I said already that it works with a r214444 version, CURRENT from > October 2010; so I booted this again and concerning keyboard, here is > the diff: Of course, I have read it but forgot about it then. >=20 > r214444: >=20 > atkbdc0: at port 0x60,0x64 on isa0 >=20 > r235646: >=20 > $ fgrep -i kb /tmp/dmesg-r235646.txt=20 > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > atkbdc0 failed to probe at port 0x60 on isa0 It must be the probing routine then. My keyboard here is at acpi but not on= isa0. Is all in the kernel which is needed for isa? It should be, but a check cou= ld help. > So the question is: why the is not > detected anymore in r235646, while it is in r214444? >=20 Maybe the hints from man will help you: Kernel configuration: options KBD_RESETDELAY=3DN options KBD_MAXWAIT=3DN options KBDIO_DEBUG=3DN device atkbdc Are they still there? /boot/device.hints: hint.atkbdc.0.at=3D"isa" hint.atkbdc.0.port=3D"0x060" I do not know if some defaults have changed. Erich From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 18:04:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C48D6106564A; Sun, 1 Jul 2012 18:04:15 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id A14088FC0A; Sun, 1 Jul 2012 18:04:15 +0000 (UTC) Received: from [192.168.2.58] (wifi.xcllnt.net [70.36.220.6] (may be forged)) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q61I3n4h015219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Jul 2012 11:03:56 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120621154010.GA95280@mech-cluster241.men.bris.ac.uk> Date: Sun, 1 Jul 2012 11:03:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <56020E80-DBA0-4D54-BF0C-A5716B657839@xcllnt.net> References: <20120621154010.GA95280@mech-cluster241.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1278) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: init: fatal signal: Segmentation fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 18:04:15 -0000 On Jun 21, 2012, at 8:40 AM, Anton Shterenlikht wrote: *snip* > Trying to mount root from ufs:/dev/da2p2 [rw]... > WARNING: / was not properly dismounted > Jun 21 17:35:34 init: fatal signal: Segmentation fault > Setting hostuuid: 0aa09909-35f1-11df-b7f8-00110a31e60a. > Setting hostid: 0xc70eae4e. > Entropy harvesting: interrupts ethernet point_to_point kickstart. > Fast boot: skipping disk checks. Why are you forcing a fast boot? Subsequent problems are the result of not making your file system clean. > mount: /dev/da2p2: R/W mount of / denied. Filesystem is not clean - = run fsck.: Operation not permitted > Mounting root filesystem rw failed, startup aborted > ERROR: ABORTING BOOT (sending SIGTERM to parent)! > Jun 21 17:36:06 init: /bin/sh on /etc/rc terminated abnormally, going = to single user mode > Jun 21 17:36:06 init: fatal signal: Segmentation fault I don't know if there's a separate problem with init(8) dumping core or the immediate consequence of the above. > How can I recover from this? boot -s and see what happens. If init(8) dies again, use a different init(8) by setting init_path at the loader prompt. SOmething like the following could do the trick: set init_path=3D"/sbin/init.bak" FYI, --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 18:05:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5214C106564A for ; Sun, 1 Jul 2012 18:05:32 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 057E98FC21 for ; Sun, 1 Jul 2012 18:05:31 +0000 (UTC) Received: by obbun3 with SMTP id un3so9000756obb.13 for ; Sun, 01 Jul 2012 11:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; bh=gL3lJAmo5m0tzPntotNbPf4NGS7oKVan3eLZZzcxqTE=; b=XbL8+66TpeXPdHR5i5ylbVLdBvENPaiGkvHNx8b+tu1mzdKFUMvFH/V7DrPSepBHjB 5tNkk7Myuyu6Vu8cJoaMZIMK+8wV4/51VY3opM6Pb1i49/Yk2ui1C9yDKI86OT36smvE zOAltaO5RMhDQEq+SPxFv0QIQ83gyrHnpdnz0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:x-gm-message-state; bh=gL3lJAmo5m0tzPntotNbPf4NGS7oKVan3eLZZzcxqTE=; b=CqHBjD+7TsveTwSDR9+2neJ7DzyQOs0VurQu3WVUifzNE4QSut7R7Hh8L+4dx8bZU1 tIMJoO7nYCdnLAJmEnUkRNKOhZp1KN5tB9OiiDgJ0YQ59DsSTk4g5SQLhUFOw/HxU9an 2tHAdwVJ68V7w7Np4KUzCeu6hk6I3KSpXN3FH5jPk94GOpHdmJUrAQrFtQJT8zK1MRJp WZFcUKkx8QuS4Ud5tvDkNoJgFR38saIQw0VSA2Ju1Iwa4yv3APeR9AhopO5tPvZSqUGi wJrcZVMv2KxgHdYx61J7brZquIhPpXY/SWKA4jMVfKgawLYh75sKsWq2U7MO0MjVJlEx 09JA== Received: by 10.50.140.4 with SMTP id rc4mr3633951igb.68.1341165931518; Sun, 01 Jul 2012 11:05:31 -0700 (PDT) Received: from DataIX.net (75-128-120-86.dhcp.aldl.mi.charter.com. [75.128.120.86]) by mx.google.com with ESMTPS id if4sm6802840igc.10.2012.07.01.11.05.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Jul 2012 11:05:30 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q61I5SWa063242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jul 2012 14:05:28 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q61I5SO3063241; Sun, 1 Jul 2012 14:05:28 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sun, 1 Jul 2012 14:05:28 -0400 From: Jason Hellenthal To: stable@freebsd.org, current@freebsd.org Message-ID: <20120701180528.GA61454@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline X-Gm-Message-State: ALoCoQkdYBES53YikCtDzm67Na/bmyq7LbXx8lYbkdf8JykVRTRoKQGdfwitcetSL3/3raOCjBIk Cc: Subject: [RFC] Flags to dmesg(1) to toggle kern.msgbuf_clear ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 18:05:32 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Would anyone be interested in adding a flag argument to dmesg to toggle kern.msgbuf_clear ? or systematicly to do the same thing ? I often find myself wanting to clear the msgbuf but have to remember what the sysctl MIB is for doing so and thought it would be a value add situation to just add '-c' or '-C' to dmesg(1) to accomplish the same thing. This would be along the same lines that Linux has done for quite a while. --=20 - (2^(N-1)) --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJP8JFnAAoJEBSh2Dr1DU7W7JkH/0vuua+84C8D30cp+Gy5ycVV /hazuDVvgGPkNnsHaIzHImXNngTddkrEjdikrE//yXCBeUBT284FduV6tomh42l8 FyoZOc6d7ImMw7z7UQakiJOSMdZL2AX+gUYHHlQeIAHLt7gviUXulPZmMRB9irws HJ+pC8FXD5DCpyNwN/WEHjUkciVNqH5d4cApsTSlzh+rAoHfjc2nStmi03XjbJkE A9P3rpHaGnY1HISKq1dsoTzYP7aOMsmdY+S0rMboTTJlkGpH8bpFWezwHGjxR20g FKhdKa2h89vPUG2P7N/gIZ89qkTq6rRzO6NyOJee984Mb64qRCYVXsKd5CqF50g= =skkb -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 18:28:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEB12106566B; Sun, 1 Jul 2012 18:28:47 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 980188FC21; Sun, 1 Jul 2012 18:28:47 +0000 (UTC) Received: from [192.168.2.58] (wifi.xcllnt.net [70.36.220.6] (may be forged)) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q61IS4PU057150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Jul 2012 11:28:10 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120629104013.GA18398@mech-cluster241.men.bris.ac.uk> Date: Sun, 1 Jul 2012 11:28:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <46A64BD5-0B45-4039-9189-CAB0701B0AA6@xcllnt.net> References: <20120629104013.GA18398@mech-cluster241.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1278) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: ia64 r235474 panic on dump 0aLuf - / | restore -rf - : exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 18:28:47 -0000 On Jun 29, 2012, at 3:40 AM, Anton Shterenlikht wrote: > # newfs /dev/da2p2 > /dev/da2p2: 16384.0MB (33554432 sectors) block size 32768, fragment = size 4096 > using 27 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. > super-block backups (for fsck -b #) at: > 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, = 10258112, 11540352, 12822592, > 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, = 23080512, 24362752, > 25644992, 26927232, 28209472, 29491712, 30773952, 32056192, 33338432 > # mount /dev/da2p2 /mnt > # cd /mnt > # dump 0aLuf - / | restore -rf - >=20 > results in this panic: >=20 > KDB: stack backtrace: > getenv with the following non-sleepable locks held: > exclusive sleep mutex vnode interlock (vnode interlock) r =3D 0 = (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 > KDB: stack backtrace: > getenv with the following non-sleepable locks held: > exclusive sleep mutex vnode interlock (vnode interlock) r =3D 0 = (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 > KDB: stack backtrace: > getenv with the following > non-sleepablefatal kernel trap (cpu 0): > locks held: I think you're kernel is seriously screwed-up. Do you have any non-standard (for ia64) kernel configuration options? --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 19:59:42 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67805106566B; Sun, 1 Jul 2012 19:59:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 360B68FC08; Sun, 1 Jul 2012 19:59:42 +0000 (UTC) Received: by dadv36 with SMTP id v36so7092922dad.13 for ; Sun, 01 Jul 2012 12:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=C7eGBOrZCMippEXh+3YANSBYxD+z+DrmyHsSeduNdNQ=; b=mwtjwfMsRvtpazNemvPb3cU70owUVI0txZMV9IDk1jEKtQr+BxXWJh4PHLfpI/JbEL hu8CGY0ZfjfxlDp0WKPpYMQq0OiUUdwmTA8t2oFNXJtWHgOYqQqeFMka5aSKmdEFoA3E uzCZLKDy6POzxHhIpwynfU27N9NhWGJ+F1uUkzWSJaFOKOGzZ56O+YIOfu9pKc0BxUp6 +peaFLWGFPXygNwV4wEKR6ILHoByl2i9hpQc2GiaekF/bXSmQQz0ucapUtL9v0H51adf 5BUwBdgBah38jJbCsw/jQYwhg22ZWD8pJ/PaHo8bcpxxWrm1XqwMfTQQY5gsUvK/WS2R Azcw== MIME-Version: 1.0 Received: by 10.68.222.103 with SMTP id ql7mr8844331pbc.68.1341172776771; Sun, 01 Jul 2012 12:59:36 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.195.102 with HTTP; Sun, 1 Jul 2012 12:59:36 -0700 (PDT) In-Reply-To: <20120701180528.GA61454@DataIX.net> References: <20120701180528.GA61454@DataIX.net> Date: Sun, 1 Jul 2012 12:59:36 -0700 X-Google-Sender-Auth: vO4BlIcRKqindhXdtYO28rdGES4 Message-ID: From: Adrian Chadd To: Jason Hellenthal Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, current@freebsd.org Subject: Re: [RFC] Flags to dmesg(1) to toggle kern.msgbuf_clear ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jul 2012 19:59:42 -0000 On 1 July 2012 11:05, Jason Hellenthal wrote: > > Would anyone be interested in adding a flag argument to dmesg to toggle > kern.msgbuf_clear ? or systematicly to do the same thing ? > Sure, adding -c to dmesg would be nice. Any objections? Adrian From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 02:21:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 967331065675; Mon, 2 Jul 2012 02:21:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 45D9B8FC0C; Mon, 2 Jul 2012 02:21:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q622LTmb016505; Sun, 1 Jul 2012 22:21:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q622LTGi016463; Mon, 2 Jul 2012 02:21:29 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Jul 2012 02:21:29 GMT Message-Id: <201207020221.q622LTGi016463@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 02:21:30 -0000 TB --- 2012-07-01 20:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-01 20:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-01 20:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-07-01 20:30:00 - cleaning the object tree TB --- 2012-07-01 20:30:00 - cvsupping the source tree TB --- 2012-07-01 20:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-07-01 20:32:27 - building world TB --- 2012-07-01 20:32:27 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 20:32:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 20:32:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 20:32:27 - SRCCONF=/dev/null TB --- 2012-07-01 20:32:27 - TARGET=amd64 TB --- 2012-07-01 20:32:27 - TARGET_ARCH=amd64 TB --- 2012-07-01 20:32:27 - TZ=UTC TB --- 2012-07-01 20:32:27 - __MAKE_CONF=/dev/null TB --- 2012-07-01 20:32:27 - cd /src TB --- 2012-07-01 20:32:27 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 1 20:32:28 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Jul 1 23:35:57 UTC 2012 TB --- 2012-07-01 23:35:57 - generating LINT kernel config TB --- 2012-07-01 23:35:57 - cd /src/sys/amd64/conf TB --- 2012-07-01 23:35:57 - /usr/bin/make -B LINT TB --- 2012-07-01 23:35:57 - cd /src/sys/amd64/conf TB --- 2012-07-01 23:35:57 - /usr/sbin/config -m LINT TB --- 2012-07-01 23:35:57 - building LINT kernel TB --- 2012-07-01 23:35:57 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 23:35:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 23:35:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 23:35:57 - SRCCONF=/dev/null TB --- 2012-07-01 23:35:57 - TARGET=amd64 TB --- 2012-07-01 23:35:57 - TARGET_ARCH=amd64 TB --- 2012-07-01 23:35:57 - TZ=UTC TB --- 2012-07-01 23:35:57 - __MAKE_CONF=/dev/null TB --- 2012-07-01 23:35:57 - cd /src TB --- 2012-07-01 23:35:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 1 23:35:58 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Jul 2 00:07:44 UTC 2012 TB --- 2012-07-02 00:07:44 - cd /src/sys/amd64/conf TB --- 2012-07-02 00:07:44 - /usr/sbin/config -m LINT-NOINET TB --- 2012-07-02 00:07:44 - building LINT-NOINET kernel TB --- 2012-07-02 00:07:44 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 00:07:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 00:07:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 00:07:44 - SRCCONF=/dev/null TB --- 2012-07-02 00:07:44 - TARGET=amd64 TB --- 2012-07-02 00:07:44 - TARGET_ARCH=amd64 TB --- 2012-07-02 00:07:44 - TZ=UTC TB --- 2012-07-02 00:07:44 - __MAKE_CONF=/dev/null TB --- 2012-07-02 00:07:44 - cd /src TB --- 2012-07-02 00:07:44 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Mon Jul 2 00:07:44 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Mon Jul 2 00:37:40 UTC 2012 TB --- 2012-07-02 00:37:40 - cd /src/sys/amd64/conf TB --- 2012-07-02 00:37:40 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-07-02 00:37:40 - building LINT-NOINET6 kernel TB --- 2012-07-02 00:37:40 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 00:37:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 00:37:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 00:37:40 - SRCCONF=/dev/null TB --- 2012-07-02 00:37:40 - TARGET=amd64 TB --- 2012-07-02 00:37:40 - TARGET_ARCH=amd64 TB --- 2012-07-02 00:37:40 - TZ=UTC TB --- 2012-07-02 00:37:40 - __MAKE_CONF=/dev/null TB --- 2012-07-02 00:37:40 - cd /src TB --- 2012-07-02 00:37:40 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Jul 2 00:37:41 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Mon Jul 2 01:07:54 UTC 2012 TB --- 2012-07-02 01:07:54 - cd /src/sys/amd64/conf TB --- 2012-07-02 01:07:54 - /usr/sbin/config -m LINT-NOIP TB --- 2012-07-02 01:07:54 - building LINT-NOIP kernel TB --- 2012-07-02 01:07:54 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 01:07:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 01:07:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 01:07:54 - SRCCONF=/dev/null TB --- 2012-07-02 01:07:54 - TARGET=amd64 TB --- 2012-07-02 01:07:54 - TARGET_ARCH=amd64 TB --- 2012-07-02 01:07:54 - TZ=UTC TB --- 2012-07-02 01:07:54 - __MAKE_CONF=/dev/null TB --- 2012-07-02 01:07:54 - cd /src TB --- 2012-07-02 01:07:54 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Mon Jul 2 01:07:54 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Mon Jul 2 01:35:09 UTC 2012 TB --- 2012-07-02 01:35:09 - cd /src/sys/amd64/conf TB --- 2012-07-02 01:35:09 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-07-02 01:35:09 - building LINT-VIMAGE kernel TB --- 2012-07-02 01:35:09 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 01:35:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 01:35:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 01:35:09 - SRCCONF=/dev/null TB --- 2012-07-02 01:35:09 - TARGET=amd64 TB --- 2012-07-02 01:35:09 - TARGET_ARCH=amd64 TB --- 2012-07-02 01:35:09 - TZ=UTC TB --- 2012-07-02 01:35:09 - __MAKE_CONF=/dev/null TB --- 2012-07-02 01:35:09 - cd /src TB --- 2012-07-02 01:35:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Mon Jul 2 01:35:09 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Mon Jul 2 02:07:44 UTC 2012 TB --- 2012-07-02 02:07:44 - cd /src/sys/amd64/conf TB --- 2012-07-02 02:07:44 - /usr/sbin/config -m GENERIC TB --- 2012-07-02 02:07:44 - building GENERIC kernel TB --- 2012-07-02 02:07:44 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 02:07:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 02:07:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 02:07:44 - SRCCONF=/dev/null TB --- 2012-07-02 02:07:44 - TARGET=amd64 TB --- 2012-07-02 02:07:44 - TARGET_ARCH=amd64 TB --- 2012-07-02 02:07:44 - TZ=UTC TB --- 2012-07-02 02:07:44 - __MAKE_CONF=/dev/null TB --- 2012-07-02 02:07:44 - cd /src TB --- 2012-07-02 02:07:44 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jul 2 02:07:44 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DAHC_REG_PRETTY_PRINT=1 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64.amd64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/obj/amd64.amd64/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c aic7xxx_reg_print.c ctfconvert -L VERSION -g aic7xxx_reg_print.o cc -O2 -pipe -DAHC_REG_PRETTY_PRINT=1 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64.amd64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/obj/amd64.amd64/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/aic7xxx/ahc/../../../dev/aic7xxx/aic7xxx.c /src/sys/modules/aic7xxx/ahc/../../../dev/aic7xxx/aic7xxx.c: In function 'ahc_dump_card_state': /src/sys/modules/aic7xxx/ahc/../../../dev/aic7xxx/aic7xxx.c:6749: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/sys/modules/aic7xxx/ahc. *** Error code 1 Stop in /src/sys/modules/aic7xxx. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64.amd64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-02 02:21:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-02 02:21:29 - ERROR: failed to build GENERIC kernel TB --- 2012-07-02 02:21:29 - 15799.09 user 2289.80 system 21088.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 02:27:33 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F137B1065680; Mon, 2 Jul 2012 02:27:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AA8F48FC19; Mon, 2 Jul 2012 02:27:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q622RWq7066147; Sun, 1 Jul 2012 22:27:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q622RWb4066132; Mon, 2 Jul 2012 02:27:32 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Jul 2012 02:27:32 GMT Message-Id: <201207020227.q622RWb4066132@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 02:27:33 -0000 TB --- 2012-07-01 20:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-01 20:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-01 20:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-01 20:30:00 - cleaning the object tree TB --- 2012-07-01 20:30:00 - cvsupping the source tree TB --- 2012-07-01 20:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-01 20:32:18 - building world TB --- 2012-07-01 20:32:18 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 20:32:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 20:32:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 20:32:18 - SRCCONF=/dev/null TB --- 2012-07-01 20:32:18 - TARGET=i386 TB --- 2012-07-01 20:32:18 - TARGET_ARCH=i386 TB --- 2012-07-01 20:32:18 - TZ=UTC TB --- 2012-07-01 20:32:18 - __MAKE_CONF=/dev/null TB --- 2012-07-01 20:32:18 - cd /src TB --- 2012-07-01 20:32:18 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 1 20:32:20 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 1 23:01:11 UTC 2012 TB --- 2012-07-01 23:01:11 - generating LINT kernel config TB --- 2012-07-01 23:01:11 - cd /src/sys/i386/conf TB --- 2012-07-01 23:01:11 - /usr/bin/make -B LINT TB --- 2012-07-01 23:01:12 - cd /src/sys/i386/conf TB --- 2012-07-01 23:01:12 - /usr/sbin/config -m LINT TB --- 2012-07-01 23:01:12 - building LINT kernel TB --- 2012-07-01 23:01:12 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 23:01:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 23:01:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 23:01:12 - SRCCONF=/dev/null TB --- 2012-07-01 23:01:12 - TARGET=i386 TB --- 2012-07-01 23:01:12 - TARGET_ARCH=i386 TB --- 2012-07-01 23:01:12 - TZ=UTC TB --- 2012-07-01 23:01:12 - __MAKE_CONF=/dev/null TB --- 2012-07-01 23:01:12 - cd /src TB --- 2012-07-01 23:01:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 1 23:01:12 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Jul 1 23:36:23 UTC 2012 TB --- 2012-07-01 23:36:23 - cd /src/sys/i386/conf TB --- 2012-07-01 23:36:23 - /usr/sbin/config -m LINT-NOINET TB --- 2012-07-01 23:36:23 - building LINT-NOINET kernel TB --- 2012-07-01 23:36:23 - CROSS_BUILD_TESTING=YES TB --- 2012-07-01 23:36:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-01 23:36:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-01 23:36:23 - SRCCONF=/dev/null TB --- 2012-07-01 23:36:23 - TARGET=i386 TB --- 2012-07-01 23:36:23 - TARGET_ARCH=i386 TB --- 2012-07-01 23:36:23 - TZ=UTC TB --- 2012-07-01 23:36:23 - __MAKE_CONF=/dev/null TB --- 2012-07-01 23:36:23 - cd /src TB --- 2012-07-01 23:36:23 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sun Jul 1 23:36:23 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Mon Jul 2 00:08:08 UTC 2012 TB --- 2012-07-02 00:08:08 - cd /src/sys/i386/conf TB --- 2012-07-02 00:08:08 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-07-02 00:08:08 - building LINT-NOINET6 kernel TB --- 2012-07-02 00:08:08 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 00:08:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 00:08:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 00:08:08 - SRCCONF=/dev/null TB --- 2012-07-02 00:08:08 - TARGET=i386 TB --- 2012-07-02 00:08:08 - TARGET_ARCH=i386 TB --- 2012-07-02 00:08:08 - TZ=UTC TB --- 2012-07-02 00:08:08 - __MAKE_CONF=/dev/null TB --- 2012-07-02 00:08:08 - cd /src TB --- 2012-07-02 00:08:08 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Jul 2 00:08:08 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Mon Jul 2 00:39:53 UTC 2012 TB --- 2012-07-02 00:39:53 - cd /src/sys/i386/conf TB --- 2012-07-02 00:39:53 - /usr/sbin/config -m LINT-NOIP TB --- 2012-07-02 00:39:53 - building LINT-NOIP kernel TB --- 2012-07-02 00:39:53 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 00:39:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 00:39:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 00:39:53 - SRCCONF=/dev/null TB --- 2012-07-02 00:39:53 - TARGET=i386 TB --- 2012-07-02 00:39:53 - TARGET_ARCH=i386 TB --- 2012-07-02 00:39:53 - TZ=UTC TB --- 2012-07-02 00:39:53 - __MAKE_CONF=/dev/null TB --- 2012-07-02 00:39:53 - cd /src TB --- 2012-07-02 00:39:53 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Mon Jul 2 00:39:53 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Mon Jul 2 01:09:14 UTC 2012 TB --- 2012-07-02 01:09:14 - cd /src/sys/i386/conf TB --- 2012-07-02 01:09:14 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-07-02 01:09:14 - building LINT-VIMAGE kernel TB --- 2012-07-02 01:09:14 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 01:09:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 01:09:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 01:09:14 - SRCCONF=/dev/null TB --- 2012-07-02 01:09:14 - TARGET=i386 TB --- 2012-07-02 01:09:14 - TARGET_ARCH=i386 TB --- 2012-07-02 01:09:14 - TZ=UTC TB --- 2012-07-02 01:09:14 - __MAKE_CONF=/dev/null TB --- 2012-07-02 01:09:14 - cd /src TB --- 2012-07-02 01:09:14 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Mon Jul 2 01:09:15 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Mon Jul 2 01:41:57 UTC 2012 TB --- 2012-07-02 01:41:57 - cd /src/sys/i386/conf TB --- 2012-07-02 01:41:57 - /usr/sbin/config -m GENERIC TB --- 2012-07-02 01:41:57 - building GENERIC kernel TB --- 2012-07-02 01:41:57 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 01:41:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 01:41:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 01:41:57 - SRCCONF=/dev/null TB --- 2012-07-02 01:41:57 - TARGET=i386 TB --- 2012-07-02 01:41:57 - TARGET_ARCH=i386 TB --- 2012-07-02 01:41:57 - TZ=UTC TB --- 2012-07-02 01:41:57 - __MAKE_CONF=/dev/null TB --- 2012-07-02 01:41:57 - cd /src TB --- 2012-07-02 01:41:57 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jul 2 01:41:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Jul 2 02:10:33 UTC 2012 TB --- 2012-07-02 02:10:33 - cd /src/sys/i386/conf TB --- 2012-07-02 02:10:33 - /usr/sbin/config -m PAE TB --- 2012-07-02 02:10:33 - building PAE kernel TB --- 2012-07-02 02:10:33 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 02:10:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 02:10:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 02:10:33 - SRCCONF=/dev/null TB --- 2012-07-02 02:10:33 - TARGET=i386 TB --- 2012-07-02 02:10:33 - TARGET_ARCH=i386 TB --- 2012-07-02 02:10:33 - TZ=UTC TB --- 2012-07-02 02:10:33 - __MAKE_CONF=/dev/null TB --- 2012-07-02 02:10:33 - cd /src TB --- 2012-07-02 02:10:33 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Mon Jul 2 02:10:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Mon Jul 2 02:18:05 UTC 2012 TB --- 2012-07-02 02:18:05 - cd /src/sys/i386/conf TB --- 2012-07-02 02:18:05 - /usr/sbin/config -m XBOX TB --- 2012-07-02 02:18:05 - building XBOX kernel TB --- 2012-07-02 02:18:05 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 02:18:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 02:18:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 02:18:05 - SRCCONF=/dev/null TB --- 2012-07-02 02:18:05 - TARGET=i386 TB --- 2012-07-02 02:18:05 - TARGET_ARCH=i386 TB --- 2012-07-02 02:18:05 - TZ=UTC TB --- 2012-07-02 02:18:05 - __MAKE_CONF=/dev/null TB --- 2012-07-02 02:18:05 - cd /src TB --- 2012-07-02 02:18:05 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Mon Jul 2 02:18:05 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Mon Jul 2 02:21:28 UTC 2012 TB --- 2012-07-02 02:21:28 - cd /src/sys/i386/conf TB --- 2012-07-02 02:21:28 - /usr/sbin/config -m XEN TB --- 2012-07-02 02:21:28 - building XEN kernel TB --- 2012-07-02 02:21:28 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 02:21:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 02:21:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 02:21:28 - SRCCONF=/dev/null TB --- 2012-07-02 02:21:28 - TARGET=i386 TB --- 2012-07-02 02:21:28 - TARGET_ARCH=i386 TB --- 2012-07-02 02:21:28 - TZ=UTC TB --- 2012-07-02 02:21:28 - __MAKE_CONF=/dev/null TB --- 2012-07-02 02:21:28 - cd /src TB --- 2012-07-02 02:21:28 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Mon Jul 2 02:21:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/in_cksum.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/initcpu.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/io.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/k6_mem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/machdep.c cc1: warnings being treated as errors /src/sys/i386/i386/machdep.c: In function 'getmemsize': /src/sys/i386/i386/machdep.c:2179: warning: unused variable 'res' [-Wunused-variable] *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-02 02:27:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-02 02:27:32 - ERROR: failed to build XEN kernel TB --- 2012-07-02 02:27:32 - 16219.54 user 2243.23 system 21451.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 04:10:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F143106566B; Mon, 2 Jul 2012 04:10:26 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [IPv6:2a02:6b8:0:602::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0F88FC08; Mon, 2 Jul 2012 04:10:25 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward2.mail.yandex.net (Yandex) with ESMTP id 9F41612A00D9; Mon, 2 Jul 2012 08:10:19 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341202219; bh=OSaFTs47gBh43YXdsk/WF/kg6+G0IS0CyL903pH0R9w=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=o7NcHH0VrHUGT6WhyqbdYMuDUCYPiBD8YOGuom9JLYUIjrj3vrAchKyU0ugCMsKXW TbV8BMGw29b+wg4qnCJPj39QuYLGWOW2nqkH050nuzhVN6B5ULOoQ0PM//2aR2DVCI sdIBOspYfcYNzuXOb2KCBBKf6R5EYL6GR45srTWA= Received: from smtp3.mail.yandex.net (localhost [127.0.0.1]) by smtp3.mail.yandex.net (Yandex) with ESMTP id 6ED6E1BA0345; Mon, 2 Jul 2012 08:10:19 +0400 (MSK) Received: from antispam.kirov.so-ups.ru (antispam.kirov.so-ups.ru [178.74.170.9]) by smtp3.mail.yandex.net (nwsmtp/Yandex) with ESMTP id AIbqp4Gm-AJbeG4d7; Mon, 2 Jul 2012 08:10:19 +0400 X-Yandex-Rcpt-Suid: jbeich@tormail.org X-Yandex-Rcpt-Suid: dim@FreeBSD.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341202219; bh=OSaFTs47gBh43YXdsk/WF/kg6+G0IS0CyL903pH0R9w=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=lznsigvrLTrTaaubp1Bi5S0Jvo64WXVfoLdSFcvuy0J+XDehkU1axJYSz8KX0BeHn 5mnnQ/aieH5fy2vYMrnSBEXYK+Gk9u6JTn1E9WgEuCWiR1Z3i3eOTDTYFh5pObvZ21 j4OM82FBch7jEZUFcGzWItOLAZdOFwA/vPwBbOsc= Message-ID: <4FF11F26.4040403@yandex.ru> Date: Mon, 02 Jul 2012 08:10:14 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Jan Beich References: <4FE9B01C.30306@yandex.ru> <4FEB5B0E.8020009@FreeBSD.org> <1SkYxx-0007Fr-SA@internal.tormail.org> In-Reply-To: <1SkYxx-0007Fr-SA@internal.tormail.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA188AFD6F784014F8149C8F7" Cc: freebsd-current , Dimitry Andric Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 04:10:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA188AFD6F784014F8149C8F7 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 29.06.2012 15:01, Jan Beich wrote: >>> So, i have created the branch and committed the changes: >>> http://svnweb.freebsd.org/base/user/ae/bootcode/ >>> The patch is here: >>> http://people.freebsd.org/~ae/boot.diff >> >> FWIW, I verified it compiles OK with clang, and especially boot2's siz= e >> isn't increased at all. > Does it boot for you? Same if I build zfs.c with gcc -O0: >=20 > FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1 > (foo@bar, Tue Jun 26 18:52:52 UTC 2012) > ZFS: can't find pool by guid > ZFS: can't find pool by guid >=20 > can't load 'kernel' >=20 Does zfsloader without patches compiled with CLANG work for you? --=20 WBR, Andrey V. Elsukov --------------enigA188AFD6F784014F8149C8F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJP8R8qAAoJEAHF6gQQyKF6xkYH/jbKVCV1SYhjB+6aiXHcfmhf 6jxsHDWf4TgXeXIyWcyvvSPjzcS8uqnfarcR8Ly1Z+5timbH8hsiIasb3D7MLpj6 nJfuppcSKetUNsDSNhtrXobA8dQJky3wPK6RBBtdwM6Wuc2HtD2apcZYXirZQgT/ iy7TUBl6WRgEyIxNFoQ2bWFx6BUxOKpk1MS6pbLN18rSsFEvjT6IdXae72SX8Lnw 0A0zo8N0O5rpkwApDFN1F2zA4l6EIAHjGnqamL2F3byOKSV0Gq0U2YFARK6Bq8gK xz52xAErApnL8etclaUv7fxJDt1rAau+0Ul63UHy0oFaUWDrH8pFoHGwfXAogYE= =O3ko -----END PGP SIGNATURE----- --------------enigA188AFD6F784014F8149C8F7-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 08:28:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CE881065715; Mon, 2 Jul 2012 08:28:42 +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 342678FC08; Mon, 2 Jul 2012 08:28:39 +0000 (UTC) Received: from [192.168.2.111] (host86-149-82-83.range86-149.btcentralplus.com [86.149.82.83]) by cyrus.watson.org (Postfix) with ESMTPSA id 6D4C946B1A; Mon, 2 Jul 2012 04:28:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Robert N. M. Watson" In-Reply-To: Date: Mon, 2 Jul 2012 09:28:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: mdf@FreeBSD.org X-Mailer: Apple Mail (2.1278) Cc: bp@freebsd.org, Arnaud Lacombe , freebsd-hackers@freebsd.org, FreeBSD Current , kby@freebsd.org, Wojciech Puchar , Chris Rees Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 08:28:42 -0000 On 26 Jun 2012, at 15:42, mdf@FreeBSD.org wrote: > While I understand the problems you allude to, the sysctl(8) binary > can protect itself from them. IMO the biggest problem with sysctls > not being files is that it makes no sense from the core UNIX > philosophy that everything is a file. Sockets and pipes and character > devices and even unseekable things like stdout are files; why aren't > these other objects that allow read, write, and have their own > namespace? I think I agree with what you're saying, subject to one modification: = rather than saying "files", say "file descriptors", which are not quite = the same but are, I think, what you mean. This doesn't mean you end up = with a special file system mounted on /foo -- we don't do that for = sockets or pipes --- but rather, we end up with using a similar = object-oriented interface. And hence, BTW, our recent experimental = addition of process descriptors to the API in support of Capsicum. = However, I wonder how well that applies to sysctls, which unlike = pipes/sockets, don't have an event model, etc... Robert= From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 10:55:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AAB71065670; Mon, 2 Jul 2012 10:55:49 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from server2.allsitecontrol.com (server2.allsitecontrol.com [63.143.36.210]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6018FC12; Mon, 2 Jul 2012 10:55:49 +0000 (UTC) Received: from [199.48.147.45] (port=48874 helo=internal.tormail.org) by server2.allsitecontrol.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.77) (envelope-from ) id 1SleIC-003iLa-UA; Mon, 02 Jul 2012 06:55:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:In-Reply-To:Subject:Cc:To:From; bh=NVW93FutpTUl3OOmnvfcIxwzLRvBvjZNc2+f6eog4/g=; b=NAQNl4tSbFLquW5ccZybf4do7CS0Ahv7x+zImU4QB28sTB46uafShrpTwCUubctRHS8cnWpZfKwGU+EaGHLi1gtwsV0Dycbo4uNIFN4cmou8+qBI5n9fOeHfZ4H1/4OZ+uW1KhzGha6BPjZXdmhMcb5ofCiR6Qx1j8Z1/9/exf8=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1SleGk-00080Z-9J; Mon, 02 Jul 2012 10:54:15 +0000 From: Jan Beich To: "Andrey V. Elsukov" In-Reply-To: <1SlXxa-0007aK-Lz@internal.tormail.org> (Andrey V. Elsukov's message of "Mon, 02 Jul 2012 08:10:14 +0400") Date: Mon, 02 Jul 2012 15:33:01 +0500 References: <4FE9B01C.30306@yandex.ru> <4FEB5B0E.8020009@FreeBSD.org> <1SkYxx-0007Fr-SA@internal.tormail.org> <1SlXxa-0007aK-Lz@internal.tormail.org> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1SleGk-00080Z-9J@internal.tormail.org> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.allsitecontrol.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.org X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current , Dimitry Andric Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 10:55:49 -0000 "Andrey V. Elsukov" writes: > On 29.06.2012 15:01, Jan Beich wrote: > >>>> So, i have created the branch and committed the changes: >>>> http://svnweb.freebsd.org/base/user/ae/bootcode/ >>>> The patch is here: >>>> http://people.freebsd.org/~ae/boot.diff >>> >>> FWIW, I verified it compiles OK with clang, and especially boot2's size >>> isn't increased at all. >> Does it boot for you? Same if I build zfs.c with gcc -O0: >> >> FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1 >> (foo@bar, Tue Jun 26 18:52:52 UTC 2012) >> ZFS: can't find pool by guid >> ZFS: can't find pool by guid >> >> can't load 'kernel' >> > > Does zfsloader without patches compiled with CLANG work for you? It does. I did test before using $ cd /usr/src/sys/boot $ env -i __MAKE_CONF= PATH=/bin:/sbin:/usr/bin:/usr/sbin make CC=clang $ make install $ sudo qemu-system-x86_64 -curses -drive file=/dev/ada0 -drive file=/dev/ada1 In gcc -O0 case $ touch zfs/zfs.c $ rm i386/zfsloader/zfsloader* $ echo CFLAGS+=-O0 >>zfs/Makefile $ env -i ... make CC=gcc And for gcc47 $ touch zfs/zfs.c $ rm i386/zfsloader/zfsloader* $ env -i ... make CC=/usr/local/bin/gcc47 -C zfs I haven't tried to further track down which flag(s) within -O1 make zfsloader from your branch work when compiled with base gcc. From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 06:12:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACC721065673; Mon, 2 Jul 2012 06:12:23 +0000 (UTC) (envelope-from BATV+46b70ed064d2f657f9da+3235+infradead.org+hch@bombadil.srs.infradead.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:4830:2446:ff00:4687:fcff:fea6:5117]) by mx1.freebsd.org (Postfix) with ESMTP id 54E3E8FC12; Mon, 2 Jul 2012 06:12:23 +0000 (UTC) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1SlZrw-0004LL-19; Mon, 02 Jul 2012 06:12:20 +0000 Date: Mon, 2 Jul 2012 02:12:20 -0400 From: Christoph Hellwig To: Attilio Rao Message-ID: <20120702061219.GA16671@infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Mailman-Approved-At: Mon, 02 Jul 2012 11:27:22 +0000 Cc: FreeBSD FS , Russell Cattelan , freebsd-current@freebsd.org, "C. P. Ghost" Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 06:12:23 -0000 On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: > anything by SoC involved people about NTFS and certainly I don't see a > plan to get XFS locked. Stupid question, but what amount of locking does XFS in FreeBSD still need? I'm one of the maintainer of XFS on Linux, and while I know FreeBSD imported a really old version compared to the current one the codebases on IRIX and later Linux never relied on any global Giant-style locking. So if there is anything to fix it would be the in the small bits of FreeBSD-specific code. From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 11:34:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 151471065673; Mon, 2 Jul 2012 11:34:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7E5888FC08; Mon, 2 Jul 2012 11:34:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q62BYNeD006179; Mon, 2 Jul 2012 07:34:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q62BYNWY006168; Mon, 2 Jul 2012 11:34:23 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Jul 2012 11:34:23 GMT Message-Id: <201207021134.q62BYNWY006168@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 11:34:30 -0000 TB --- 2012-07-02 05:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-02 05:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-02 05:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-02 05:20:00 - cleaning the object tree TB --- 2012-07-02 05:32:25 - cvsupping the source tree TB --- 2012-07-02 05:32:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-02 05:34:16 - building world TB --- 2012-07-02 05:34:16 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 05:34:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 05:34:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 05:34:16 - SRCCONF=/dev/null TB --- 2012-07-02 05:34:16 - TARGET=i386 TB --- 2012-07-02 05:34:16 - TARGET_ARCH=i386 TB --- 2012-07-02 05:34:16 - TZ=UTC TB --- 2012-07-02 05:34:16 - __MAKE_CONF=/dev/null TB --- 2012-07-02 05:34:16 - cd /src TB --- 2012-07-02 05:34:16 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 2 05:34:17 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 2 08:08:07 UTC 2012 TB --- 2012-07-02 08:08:07 - generating LINT kernel config TB --- 2012-07-02 08:08:07 - cd /src/sys/i386/conf TB --- 2012-07-02 08:08:07 - /usr/bin/make -B LINT TB --- 2012-07-02 08:08:07 - cd /src/sys/i386/conf TB --- 2012-07-02 08:08:07 - /usr/sbin/config -m LINT TB --- 2012-07-02 08:08:07 - building LINT kernel TB --- 2012-07-02 08:08:07 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 08:08:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 08:08:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 08:08:07 - SRCCONF=/dev/null TB --- 2012-07-02 08:08:07 - TARGET=i386 TB --- 2012-07-02 08:08:07 - TARGET_ARCH=i386 TB --- 2012-07-02 08:08:07 - TZ=UTC TB --- 2012-07-02 08:08:07 - __MAKE_CONF=/dev/null TB --- 2012-07-02 08:08:07 - cd /src TB --- 2012-07-02 08:08:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 2 08:08:07 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Jul 2 08:42:00 UTC 2012 TB --- 2012-07-02 08:42:00 - cd /src/sys/i386/conf TB --- 2012-07-02 08:42:00 - /usr/sbin/config -m LINT-NOINET TB --- 2012-07-02 08:42:00 - building LINT-NOINET kernel TB --- 2012-07-02 08:42:00 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 08:42:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 08:42:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 08:42:00 - SRCCONF=/dev/null TB --- 2012-07-02 08:42:00 - TARGET=i386 TB --- 2012-07-02 08:42:00 - TARGET_ARCH=i386 TB --- 2012-07-02 08:42:00 - TZ=UTC TB --- 2012-07-02 08:42:00 - __MAKE_CONF=/dev/null TB --- 2012-07-02 08:42:00 - cd /src TB --- 2012-07-02 08:42:00 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Mon Jul 2 08:42:00 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Mon Jul 2 09:14:58 UTC 2012 TB --- 2012-07-02 09:14:58 - cd /src/sys/i386/conf TB --- 2012-07-02 09:14:58 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-07-02 09:14:58 - building LINT-NOINET6 kernel TB --- 2012-07-02 09:14:58 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 09:14:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 09:14:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 09:14:58 - SRCCONF=/dev/null TB --- 2012-07-02 09:14:58 - TARGET=i386 TB --- 2012-07-02 09:14:58 - TARGET_ARCH=i386 TB --- 2012-07-02 09:14:58 - TZ=UTC TB --- 2012-07-02 09:14:58 - __MAKE_CONF=/dev/null TB --- 2012-07-02 09:14:58 - cd /src TB --- 2012-07-02 09:14:58 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Jul 2 09:14:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Mon Jul 2 09:46:27 UTC 2012 TB --- 2012-07-02 09:46:27 - cd /src/sys/i386/conf TB --- 2012-07-02 09:46:27 - /usr/sbin/config -m LINT-NOIP TB --- 2012-07-02 09:46:27 - building LINT-NOIP kernel TB --- 2012-07-02 09:46:27 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 09:46:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 09:46:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 09:46:27 - SRCCONF=/dev/null TB --- 2012-07-02 09:46:27 - TARGET=i386 TB --- 2012-07-02 09:46:27 - TARGET_ARCH=i386 TB --- 2012-07-02 09:46:27 - TZ=UTC TB --- 2012-07-02 09:46:27 - __MAKE_CONF=/dev/null TB --- 2012-07-02 09:46:27 - cd /src TB --- 2012-07-02 09:46:27 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Mon Jul 2 09:46:27 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Mon Jul 2 10:16:48 UTC 2012 TB --- 2012-07-02 10:16:48 - cd /src/sys/i386/conf TB --- 2012-07-02 10:16:48 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-07-02 10:16:48 - building LINT-VIMAGE kernel TB --- 2012-07-02 10:16:48 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 10:16:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 10:16:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 10:16:48 - SRCCONF=/dev/null TB --- 2012-07-02 10:16:48 - TARGET=i386 TB --- 2012-07-02 10:16:48 - TARGET_ARCH=i386 TB --- 2012-07-02 10:16:48 - TZ=UTC TB --- 2012-07-02 10:16:48 - __MAKE_CONF=/dev/null TB --- 2012-07-02 10:16:48 - cd /src TB --- 2012-07-02 10:16:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Mon Jul 2 10:16:48 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Mon Jul 2 10:50:08 UTC 2012 TB --- 2012-07-02 10:50:08 - cd /src/sys/i386/conf TB --- 2012-07-02 10:50:08 - /usr/sbin/config -m GENERIC TB --- 2012-07-02 10:50:08 - building GENERIC kernel TB --- 2012-07-02 10:50:08 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 10:50:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 10:50:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 10:50:08 - SRCCONF=/dev/null TB --- 2012-07-02 10:50:08 - TARGET=i386 TB --- 2012-07-02 10:50:08 - TARGET_ARCH=i386 TB --- 2012-07-02 10:50:08 - TZ=UTC TB --- 2012-07-02 10:50:08 - __MAKE_CONF=/dev/null TB --- 2012-07-02 10:50:08 - cd /src TB --- 2012-07-02 10:50:08 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jul 2 10:50:08 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Jul 2 11:17:57 UTC 2012 TB --- 2012-07-02 11:17:57 - cd /src/sys/i386/conf TB --- 2012-07-02 11:17:57 - /usr/sbin/config -m PAE TB --- 2012-07-02 11:17:57 - building PAE kernel TB --- 2012-07-02 11:17:57 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 11:17:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 11:17:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 11:17:57 - SRCCONF=/dev/null TB --- 2012-07-02 11:17:57 - TARGET=i386 TB --- 2012-07-02 11:17:57 - TARGET_ARCH=i386 TB --- 2012-07-02 11:17:57 - TZ=UTC TB --- 2012-07-02 11:17:57 - __MAKE_CONF=/dev/null TB --- 2012-07-02 11:17:57 - cd /src TB --- 2012-07-02 11:17:57 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Mon Jul 2 11:17:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Mon Jul 2 11:25:32 UTC 2012 TB --- 2012-07-02 11:25:32 - cd /src/sys/i386/conf TB --- 2012-07-02 11:25:32 - /usr/sbin/config -m XBOX TB --- 2012-07-02 11:25:32 - building XBOX kernel TB --- 2012-07-02 11:25:32 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 11:25:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 11:25:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 11:25:32 - SRCCONF=/dev/null TB --- 2012-07-02 11:25:32 - TARGET=i386 TB --- 2012-07-02 11:25:32 - TARGET_ARCH=i386 TB --- 2012-07-02 11:25:32 - TZ=UTC TB --- 2012-07-02 11:25:32 - __MAKE_CONF=/dev/null TB --- 2012-07-02 11:25:32 - cd /src TB --- 2012-07-02 11:25:32 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Mon Jul 2 11:25:32 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Mon Jul 2 11:28:49 UTC 2012 TB --- 2012-07-02 11:28:49 - cd /src/sys/i386/conf TB --- 2012-07-02 11:28:49 - /usr/sbin/config -m XEN TB --- 2012-07-02 11:28:49 - building XEN kernel TB --- 2012-07-02 11:28:49 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 11:28:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 11:28:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 11:28:49 - SRCCONF=/dev/null TB --- 2012-07-02 11:28:49 - TARGET=i386 TB --- 2012-07-02 11:28:49 - TARGET_ARCH=i386 TB --- 2012-07-02 11:28:49 - TZ=UTC TB --- 2012-07-02 11:28:49 - __MAKE_CONF=/dev/null TB --- 2012-07-02 11:28:49 - cd /src TB --- 2012-07-02 11:28:49 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Mon Jul 2 11:28:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/in_cksum.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/initcpu.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/io.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/k6_mem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/machdep.c cc1: warnings being treated as errors /src/sys/i386/i386/machdep.c: In function 'getmemsize': /src/sys/i386/i386/machdep.c:2179: warning: unused variable 'res' [-Wunused-variable] *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-02 11:34:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-02 11:34:23 - ERROR: failed to build XEN kernel TB --- 2012-07-02 11:34:23 - 16216.84 user 2245.25 system 22462.29 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 12:05:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 002D0106567E for ; Mon, 2 Jul 2012 12:05:13 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id A074E8FC0C for ; Mon, 2 Jul 2012 12:05:13 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SlfNN-0002Xa-6y; Mon, 02 Jul 2012 15:05:09 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 42E751CC2D; Mon, 2 Jul 2012 15:05:09 +0300 (EEST) Date: Mon, 2 Jul 2012 15:05:09 +0300 From: Andrey Simonenko To: Vincent Hoffman Message-ID: <20120702120509.GA24501@pm513-1.comsys.ntu-kpi.kiev.ua> References: <68594395.2439924.1341103989486.JavaMail.root@erie.cs.uoguelph.ca> <4FF030DA.8030304@unsane.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF030DA.8030304@unsane.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-07-02 15:05:09 X-Connected-IP: 10.18.52.101:14672 X-Message-Linecount: 47 X-Body-Linecount: 30 X-Message-Size: 2172 X-Body-Size: 1403 Cc: Rick Macklem , freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 12:05:14 -0000 On Sun, Jul 01, 2012 at 12:13:30PM +0100, Vincent Hoffman wrote: > On 01/07/2012 01:53, Rick Macklem wrote: > >>> > > I haven't looked at Andrey's patch, but conceptually it sounds like > > the best approach. As I understand it, the problem with replacing > > mountd with nfse (at least in the FreeBSD source tree) is that nfse > > is not 100% backwards compatible with /etc/exports and, as such, is > > a POLA violation. > Understood. Its far from a simple drop in replacement. List of difference between "nfse -C ..." (compatible mode with mountd) and mountd is given here: http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014554.html If we ignore absence of some obsolete options support and some command line options, the rest of differences visible to a user will occur only if one does not follow rules of exports(5) file format. The native mode of nfse (nfs.exports(5) file format) is different than the logic of mountd, just because using existent exports(5) file format it is impossible to specify export of not mounted file system, it is impossible to specify all export settings for one file system in one line, etc. Can you verify whether nfse compatible mode with mountd is really compatible with exports(5) files on your systems using instructions from this message (no installation or patching is required): http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008421.html From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 12:36:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50C86106564A; Mon, 2 Jul 2012 12:36:03 +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 B7BDF8FC0A; Mon, 2 Jul 2012 12:36:02 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SlfrA-0006PJ-Cj; Mon, 02 Jul 2012 13:35:56 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Slfr9-0007bb-Hy; Mon, 02 Jul 2012 13:35:55 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q62CZtSG036405; Mon, 2 Jul 2012 13:35:55 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q62CZsxF036404; Mon, 2 Jul 2012 13:35:54 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Mon, 2 Jul 2012 13:35:54 +0100 From: Anton Shterenlikht To: Marcel Moolenaar Message-ID: <20120702123554.GA36368@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: Marcel Moolenaar , Anton Shterenlikht , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org References: <20120621154010.GA95280@mech-cluster241.men.bris.ac.uk> <56020E80-DBA0-4D54-BF0C-A5716B657839@xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56020E80-DBA0-4D54-BF0C-A5716B657839@xcllnt.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-ia64@freebsd.org Subject: Re: init: fatal signal: Segmentation fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 12:36:03 -0000 On Sun, Jul 01, 2012 at 11:03:49AM -0700, Marcel Moolenaar wrote: > > On Jun 21, 2012, at 8:40 AM, Anton Shterenlikht wrote: > > *snip* > > Trying to mount root from ufs:/dev/da2p2 [rw]... > > WARNING: / was not properly dismounted > > Jun 21 17:35:34 init: fatal signal: Segmentation fault > > Setting hostuuid: 0aa09909-35f1-11df-b7f8-00110a31e60a. > > Setting hostid: 0xc70eae4e. > > Entropy harvesting: interrupts ethernet point_to_point kickstart. > > Fast boot: skipping disk checks. > > Why are you forcing a fast boot? Subsequent problems are the result > of not making your file system clean. Well.. I had a complete freeze. The only way to recove was a cold reset, hence the "not properly dismounted" warning. I've no idea why the disk checks were skipped. As far as I remember, I just did a reboot, no extra or special options. > > > mount: /dev/da2p2: R/W mount of / denied. Filesystem is not clean - run fsck.: Operation not permitted > > Mounting root filesystem rw failed, startup aborted > > ERROR: ABORTING BOOT (sending SIGTERM to parent)! > > Jun 21 17:36:06 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode > > Jun 21 17:36:06 init: fatal signal: Segmentation fault > > I don't know if there's a separate problem with init(8) dumping > core or the immediate consequence of the above. > > > How can I recover from this? > > boot -s and see what happens. If init(8) dies again, use a > different init(8) by setting init_path at the loader prompt. > SOmething like the following could do the trick: > > set init_path="/sbin/init.bak" boot -s led to the same error "aborting boot". I didn't know about init.bak, will try next time. Anyway, I couldn't figure out how to recover, and decided to re-install. Thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 12:43:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C81121065672; Mon, 2 Jul 2012 12:43:51 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7A24D8FC1B; Mon, 2 Jul 2012 12:43:51 +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 1Slfyo-0006zm-K2; Mon, 02 Jul 2012 13:43:50 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Slfyo-00022j-Cd; Mon, 02 Jul 2012 13:43:50 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q62Chodj036427; Mon, 2 Jul 2012 13:43:50 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q62ChogQ036426; Mon, 2 Jul 2012 13:43:50 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Mon, 2 Jul 2012 13:43:49 +0100 From: Anton Shterenlikht To: Marcel Moolenaar Message-ID: <20120702124349.GC36368@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: Marcel Moolenaar , Anton Shterenlikht , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org References: <20120629104013.GA18398@mech-cluster241.men.bris.ac.uk> <46A64BD5-0B45-4039-9189-CAB0701B0AA6@xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A64BD5-0B45-4039-9189-CAB0701B0AA6@xcllnt.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-ia64@freebsd.org Subject: Re: ia64 r235474 panic on dump 0aLuf - / | restore -rf - : exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 12:43:51 -0000 On Sun, Jul 01, 2012 at 11:28:04AM -0700, Marcel Moolenaar wrote: > > On Jun 29, 2012, at 3:40 AM, Anton Shterenlikht wrote: > > > # newfs /dev/da2p2 > > /dev/da2p2: 16384.0MB (33554432 sectors) block size 32768, fragment size 4096 > > using 27 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. > > super-block backups (for fsck -b #) at: > > 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, > > 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752, > > 25644992, 26927232, 28209472, 29491712, 30773952, 32056192, 33338432 > > # mount /dev/da2p2 /mnt > > # cd /mnt > > # dump 0aLuf - / | restore -rf - > > > > results in this panic: > > > > KDB: stack backtrace: > > getenv with the following non-sleepable locks held: > > exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 > > KDB: stack backtrace: > > getenv with the following non-sleepable locks held: > > exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 > > KDB: stack backtrace: > > getenv with the following > > non-sleepablefatal kernel trap (cpu 0): > > locks held: > > I think you're kernel is seriously screwed-up. Do you have any > non-standard (for ia64) kernel configuration options? I didn't think so. The latest was this: (From http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/uzi/UZI): cpu ITANIUM2 # UZI - rx2600 portscluster node ident UZI makeoptions DEBUG=-g makeoptions MODULES_OVERRIDE="geom/geom_part geom/geom_label opensolaris zfs" #makeoptions MODULES_OVERRIDE="geom/geom_part geom/geom_label opensolaris zfs acl_nfs4 acl_posix1e" options ALT_BREAK_TO_DEBUGGER options BREAK_TO_DEBUGGER options CD9660 options DDB options DEADLKRES #options EXCEPTION_TRACING options FFS options GDB options INET options INET6 options INVARIANTS options INVARIANT_SUPPORT #options IPI_PREEMPTION options IPFILTER options IPFILTER_DEFAULT_BLOCK options IPFILTER_LOG options KDB options KTRACE options MD_ROOT options MSDOSFS options NFSCL options NFSD options P1003_1B_SEMAPHORES #options PREEMPTION options PRINTF_BUFR_SIZE=128 options PROCFS options PSEUDOFS #options SCHED_4BSD options SCHED_ULE options SCSI_DELAY=3000 options SCTP # Stream Control Transmission Protocol options SMP options SOFTUPDATES options STACK options SYSVMSG options SYSVSEM options SYSVSHM options UFS_DIRHASH options UWX_TRACE_ENABLE options WITNESS #options WITNESS_KDB options WITNESS_SKIPSPIN options _KPOSIX_PRIORITY_SCHEDULING device bge device bpf device cd device da device ehci device ether device firmware device fxp device loop device md device miibus device mpt device ohci device pass device pci device pty device puc device random device sa device scbus device scc device smbus device tun device uart device umass device usb ################################################################## # portbuilding options, from # http://www.freebsd.org/doc/en_US.ISO8859-1/articles/portbuild/article.html#NEW-NODE options NULLFS options TMPFS options GEOM_CONCAT options GEOM_STRIPE options SHMMAXPGS=65536 options SEMMNI=40 options SEMMNS=240 options SEMUME=40 options SEMMNU=120 ################################################################## Many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 14:15:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 436BB106564A for ; Mon, 2 Jul 2012 14:15:35 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id AB1B48FC12 for ; Mon, 2 Jul 2012 14:15:34 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q62EF6iY056865 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 2 Jul 2012 15:15:07 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FF1ACEA.3080009@unsane.co.uk> Date: Mon, 02 Jul 2012 15:15:06 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andrey Simonenko References: <68594395.2439924.1341103989486.JavaMail.root@erie.cs.uoguelph.ca> <4FF030DA.8030304@unsane.co.uk> <20120702120509.GA24501@pm513-1.comsys.ntu-kpi.kiev.ua> In-Reply-To: <20120702120509.GA24501@pm513-1.comsys.ntu-kpi.kiev.ua> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rick Macklem , freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 14:15:35 -0000 On 02/07/2012 13:05, Andrey Simonenko wrote: > On Sun, Jul 01, 2012 at 12:13:30PM +0100, Vincent Hoffman wrote: >> On 01/07/2012 01:53, Rick Macklem wrote: >>> I haven't looked at Andrey's patch, but conceptually it sounds like >>> the best approach. As I understand it, the problem with replacing >>> mountd with nfse (at least in the FreeBSD source tree) is that nfse >>> is not 100% backwards compatible with /etc/exports and, as such, is >>> a POLA violation. >> Understood. Its far from a simple drop in replacement. > List of difference between "nfse -C ..." (compatible mode with mountd) > and mountd is given here: > > http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014554.html > > If we ignore absence of some obsolete options support and some command > line options, the rest of differences visible to a user will occur only > if one does not follow rules of exports(5) file format. > > The native mode of nfse (nfs.exports(5) file format) is different > than the logic of mountd, just because using existent exports(5) file > format it is impossible to specify export of not mounted file system, > it is impossible to specify all export settings for one file system in > one line, etc. > > Can you verify whether nfse compatible mode with mountd is really > compatible with exports(5) files on your systems using instructions > from this message (no installation or patching is required): > > http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008421.html Its certainly compatible for me. I only have simple requirements though. (Basic NFS exports for servers to dump their backups onto.) nfse does look very good to me and I'll certainly be trying it in a VM. Any Ideas as to what would be needed to get this imported? Vince From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 14:22:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEFE4106566B; Mon, 2 Jul 2012 14:22:25 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE64B8FC18; Mon, 2 Jul 2012 14:22:24 +0000 (UTC) Received: by lbon10 with SMTP id n10so9508513lbo.13 for ; Mon, 02 Jul 2012 07:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tAHkgVw5kJ3r56w+xZocmo5AiUeVl2u9KFOnFTLLl6A=; b=YLVQMbSm5FwuQ6KR7SzFqQmZaUNt9U2GWxb4BT5Jv9Df6QwpSc9ZdnCClfKx/wtScA gjJ7MOio1XF3Yg/HDioHX9Od8qp6VPL7fGPlzViBCMufE0db5HCP3qzzS1YqbO5gYhLU dg4Jb5IHBII1jyJBRSw2bSTbgOmdM4N4r66Ec3D7rh+83gNK7n5fxjGnA7rN5tYQnUtY iFo5ReKEy8z2GYLxWyL6Ebr/oG4tKaRLmPkbUPMuV5gQkSILDoP2Srkz1nCVmALDWt1A e2IFxgIENOqopreMI83eXDWPtWH3/WqvmUSR/pG0vmxIruf11kcpCapojB+wdupgLNkw Jiiw== MIME-Version: 1.0 Received: by 10.152.131.9 with SMTP id oi9mr13062883lab.39.1341238943768; Mon, 02 Jul 2012 07:22:23 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Mon, 2 Jul 2012 07:22:23 -0700 (PDT) In-Reply-To: <20120702061219.GA16671@infradead.org> References: <20120702061219.GA16671@infradead.org> Date: Mon, 2 Jul 2012 15:22:23 +0100 X-Google-Sender-Auth: LXn3NQyyCUDaSY6EFW8aBfNtzPI Message-ID: From: Attilio Rao To: Christoph Hellwig Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD FS , Russell Cattelan , freebsd-current@freebsd.org, "C. P. Ghost" Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 14:22:25 -0000 2012/7/2, Christoph Hellwig : > On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: >> anything by SoC involved people about NTFS and certainly I don't see a >> plan to get XFS locked. > > Stupid question, but what amount of locking does XFS in FreeBSD still > need? I'm one of the maintainer of XFS on Linux, and while I know > FreeBSD imported a really old version compared to the current one the > codebases on IRIX and later Linux never relied on any global Giant-style > locking. So if there is anything to fix it would be the in the small > bits of FreeBSD-specific code. Basically when it cames to make a MPSAFE filesystem under FreeBSD there are 2 things to pay attention at: filesystem specific locking and dealing with FreeBSD's VFS locking. The former is usually the tricky part because it varies among the filesystems and it is where the developers might have more knowledge. The latter can be helped by testing with a debugging kernel for low hanging fruits, but special attention must be put in things like avoid to put half-constructed vnodes in the mount lists, lookup races (in particular with DOTDOT case) and others. For a reference, one can always look to simple filesystems that are already made MPSAFE (like MSDOS-FS likely). In the XFS case, I think it would be desirable to have a real maintainership. This means, basically, not only work on the locking but really be keen to have a working XFS. At the moment, we might still have write support as well, but it is badly broken. What I suggest for XFS is: - Remove the current write support entirely - Try to bring the sole read support to new(ish) XFS version (at least to a version that is known to not be totally broken) - Fix up the support to work with FreeBSD VFS Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 14:33:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11D37106566B; Mon, 2 Jul 2012 14:33:51 +0000 (UTC) (envelope-from cattelan@thebarn.com) Received: from x.digitalelves.com (x.digitalelves.com [209.98.77.55]) by mx1.freebsd.org (Postfix) with ESMTP id AA8608FC14; Mon, 2 Jul 2012 14:33:50 +0000 (UTC) Received: from Russells-Lion-Hackintosh.local (c-66-41-26-220.hsd1.mn.comcast.net [66.41.26.220]) (authenticated bits=0) by x.digitalelves.com (8.14.5/8.14.5) with ESMTP id q62EDGqZ071770 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 2 Jul 2012 09:13:19 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <4FF1AC74.7020205@thebarn.com> Date: Mon, 02 Jul 2012 09:13:08 -0500 From: Russell Cattelan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Attilio Rao , "C. P. Ghost" , FreeBSD FS References: <20120702061219.GA16671@infradead.org> In-Reply-To: <20120702061219.GA16671@infradead.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8E2EBB2A9B6D2F149D45CFED" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Christoph Hellwig , freebsd-current@freebsd.org Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 14:33:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8E2EBB2A9B6D2F149D45CFED Content-Type: multipart/mixed; boundary="------------090609090007020402060209" This is a multi-part message in MIME format. --------------090609090007020402060209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/2/12 1:12 AM, Christoph Hellwig wrote: > On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: >> anything by SoC involved people about NTFS and certainly I don't see a= >> plan to get XFS locked. >=20 > Stupid question, but what amount of locking does XFS in FreeBSD still > need? I'm one of the maintainer of XFS on Linux, and while I know > FreeBSD imported a really old version compared to the current one the > codebases on IRIX and later Linux never relied on any global Giant-styl= e > locking. So if there is anything to fix it would be the in the small > bits of FreeBSD-specific code. >=20 I would be curious as well. Since I'm one of the people that has done the port of XFS to FreeBSD I'm wondering what this whole MP initiative with regards to filesystems is about. XFS certainly maintained any fine grain locking inherent to XFS it self. The XFS locks were mapped to FreeBSD sx locks in the code that is in the tree currently. The last time I made a pass at updating XFS some of locks were remapped to mtx locks. Is there somethings in the vfs layer in terms of locking that needs to be pushed down to the fs? -Russell --------------090609090007020402060209-- --------------enig8E2EBB2A9B6D2F149D45CFED Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/xrHwACgkQNRmM+OaGhBidhwCfdDBRjUokO9eYrvB2goE3G7TS e1sAnjxqc7Co5rK2AbxD5r/R4L3GVM5E =hb9/ -----END PGP SIGNATURE----- --------------enig8E2EBB2A9B6D2F149D45CFED-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 14:35:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D919106564A; Mon, 2 Jul 2012 14:35:59 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F0DE48FC0C; Mon, 2 Jul 2012 14:35:58 +0000 (UTC) Received: by bkcje9 with SMTP id je9so214027bkc.13 for ; Mon, 02 Jul 2012 07:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EUgf1rOpNUuBy/2Mhn/BawTLANAf2bZT7bMS47BEVyw=; b=IsTZei13hEcHhBIBwRhwOL7ugfwihn5dilBQglpyX5CDGoqdY/GQgOQhNgE07rA9cP ZY1rMHGkCPdbHbk7B3Q4/LUWlFJ59p6rwfSBAgZqmNRXQzAnc18K1/YzU6+eFq49Uk8n +p9bQqfljasEWCn1aV9+cJrFiTGR9f9WJdYhq1cVOUS+HVLraUDEDfmb1sWxccAhuACF PhlhyiI/UuK8kgH5H2eYCWV7GfZGuZUUXTt1o+2t4qERPmcJxbCTNiIk/beOxeaXPUaG rCxIUhbTJE2ftLQztITI9M+oTS68CYtnTdKpw+1+cr1CpVhJt630f9bPnyD5B3eF5Pp4 if2w== MIME-Version: 1.0 Received: by 10.152.136.18 with SMTP id pw18mr13232556lab.17.1341239757762; Mon, 02 Jul 2012 07:35:57 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Mon, 2 Jul 2012 07:35:57 -0700 (PDT) In-Reply-To: <4FF1AC74.7020205@thebarn.com> References: <20120702061219.GA16671@infradead.org> <4FF1AC74.7020205@thebarn.com> Date: Mon, 2 Jul 2012 15:35:57 +0100 X-Google-Sender-Auth: nTOnsVR6fsqbde3UcZHs-9PSWwU Message-ID: From: Attilio Rao To: Russell Cattelan Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD FS , Christoph Hellwig , freebsd-current@freebsd.org, "C. P. Ghost" Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 14:35:59 -0000 2012/7/2, Russell Cattelan : > On 7/2/12 1:12 AM, Christoph Hellwig wrote: >> On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: >>> anything by SoC involved people about NTFS and certainly I don't see a >>> plan to get XFS locked. >> >> Stupid question, but what amount of locking does XFS in FreeBSD still >> need? I'm one of the maintainer of XFS on Linux, and while I know >> FreeBSD imported a really old version compared to the current one the >> codebases on IRIX and later Linux never relied on any global Giant-style >> locking. So if there is anything to fix it would be the in the small >> bits of FreeBSD-specific code. >> > I would be curious as well. Since I'm one of the people that has done > the port of XFS to FreeBSD I'm wondering what this whole MP initiative > with regards to filesystems is about. So if you think that XFS doesn't need to acquire Giant why it is not yet marked MPSAFE? Also, did you really ever actually tested write support? (Not sure if it was added to you). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 15:03:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5FFF106566B; Mon, 2 Jul 2012 15:03:45 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 560408FC14; Mon, 2 Jul 2012 15:03:45 +0000 (UTC) Received: by qcsg15 with SMTP id g15so3402741qcs.13 for ; Mon, 02 Jul 2012 08:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=kDkWVGa3N+2gt5YKidDiC1CmwxYnsun92iAZTZJbBh4=; b=rhdJoMce//KjShpj72Cee4o2cJh7xTMaXZt+Y1IIcSSYdNDf4bvmzlGRViFLZ/CVbh i5S1GNiPXZWanJZbHOnvA/5gvPZBBwe7VhM2ZTHJ1ssi/6NDc/iD/g9c5txr4pkTkVdv OtoEhWr8DuLNxK8Pe7YpUnX6iTBtIr7tcQL2n0zgJrcb5m/S4+bjLVzDEWdvslcvZTkC miQ5M1eeGBq/MbRpitIHjVB3c7of6kFP68LCcOpaNI1TiH6A/hEDmA9ZLCsqLTdltNDR Mh7IKLRjwLDKcUYcre/AMbLGNp1MVcdWgs3sGgNf42VyLy4tAU7I8e3hHODA920EvQLU k6tA== Received: by 10.229.135.18 with SMTP id l18mr6862575qct.156.1341241424614; Mon, 02 Jul 2012 08:03:44 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id dz4sm31724960qab.4.2012.07.02.08.03.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 08:03:43 -0700 (PDT) Date: Mon, 2 Jul 2012 11:03:40 -0400 From: Alexander Kabaev To: Christoph Hellwig Message-ID: <20120702150339.GA7226@kan.dyndns.org> References: <20120702061219.GA16671@infradead.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <20120702061219.GA16671@infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Attilio Rao , FreeBSD FS , freebsd-current@freebsd.org, "C. P. Ghost" , Russell Cattelan Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 15:03:46 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote: > On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: > > anything by SoC involved people about NTFS and certainly I don't see a > > plan to get XFS locked. >=20 > Stupid question, but what amount of locking does XFS in FreeBSD still > need? I'm one of the maintainer of XFS on Linux, and while I know > FreeBSD imported a really old version compared to the current one the > codebases on IRIX and later Linux never relied on any global Giant-style > locking. So if there is anything to fix it would be the in the small > bits of FreeBSD-specific code. >=20 When I stopped being interested in XFS, I left is marked as non-MPSAFE entirely because of the lack of proper testing and because VFS locking was still evolving, there was no officially proper way of locking the FS and no other FS in the tree was MPSAFE. At that time the only problematic area was around inode instantiation, but sereval other lockingi changes have made it into the tree since then, namely ones that deal with insmntque and also VOP_LOOKUP changes. To mark XFS MPSAFE, one needs to simply audit the code and make sure it still makse sense for today= 's VFS, which is not a huge amount of work. One step further woule be to take most of the XFS from under the exclusive vnode locking to improve the performance. And there is a third option - just let current XFS port die and start with newer version. --=20 Alexander Kabaev --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFP8bhLQ6z1jMm+XZYRAhpNAJ9/wX+/YBqya26vJdUdSl+NrlyOjwCg3K2J ursmLw9qFXWb8eIvglCWxJI= =q7N/ -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 15:04:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0562106564A; Mon, 2 Jul 2012 15:04:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8871E8FC14; Mon, 2 Jul 2012 15:04:34 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F2EC3B960; Mon, 2 Jul 2012 11:04:33 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 2 Jul 2012 10:36:45 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <7BEE3948-EE35-48C2-B4B1-25E34087A4C4@lists.zabbadoz.net> In-Reply-To: <7BEE3948-EE35-48C2-B4B1-25E34087A4C4@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207021036.45567.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 02 Jul 2012 11:04:34 -0400 (EDT) Cc: "Bjoern A. Zeeb" , current@freebsd.org Subject: Re: swp_pager_meta_build DoS printf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 15:04:34 -0000 On Sunday, July 01, 2012 8:23:31 am Bjoern A. Zeeb wrote: > Hey, > > hitting this printf in swp_pager_meta_build() > > if (uma_zone_exhausted(swap_zone)) { > printf("swap zone exhausted, increase kern.maxswzone\n"); > vm_pageout_oom(VM_OOM_SWAPZ); > pause("swzonex", 10); > } else > > seems to be an effective way to put the machine into a state of no recovery > unless the memory situation would be able to clear itself. Not that it wouldn't > otherwise be any better but in addition having a couple of tenthousands of these > going to console as well is really not helpful to try to do anything either. Can > we make it a log() call or something? > > /bz > > PS: I am not sure as I have seen it on someone else's machines and it's > probably been ZFS that caused it. I unfortunately neither had a way to > get back in or break to a kernel debugger, so information is sparse. This used to be a silent deadlock before I added the printf() and the call to OOM. :-P Do you just want to ratelimit the printf? We have an API to ratelimit printf's already. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 15:04:34 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0562106564A; Mon, 2 Jul 2012 15:04:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8871E8FC14; Mon, 2 Jul 2012 15:04:34 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F2EC3B960; Mon, 2 Jul 2012 11:04:33 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 2 Jul 2012 10:36:45 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <7BEE3948-EE35-48C2-B4B1-25E34087A4C4@lists.zabbadoz.net> In-Reply-To: <7BEE3948-EE35-48C2-B4B1-25E34087A4C4@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207021036.45567.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 02 Jul 2012 11:04:34 -0400 (EDT) Cc: "Bjoern A. Zeeb" , current@freebsd.org Subject: Re: swp_pager_meta_build DoS printf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 15:04:34 -0000 On Sunday, July 01, 2012 8:23:31 am Bjoern A. Zeeb wrote: > Hey, > > hitting this printf in swp_pager_meta_build() > > if (uma_zone_exhausted(swap_zone)) { > printf("swap zone exhausted, increase kern.maxswzone\n"); > vm_pageout_oom(VM_OOM_SWAPZ); > pause("swzonex", 10); > } else > > seems to be an effective way to put the machine into a state of no recovery > unless the memory situation would be able to clear itself. Not that it wouldn't > otherwise be any better but in addition having a couple of tenthousands of these > going to console as well is really not helpful to try to do anything either. Can > we make it a log() call or something? > > /bz > > PS: I am not sure as I have seen it on someone else's machines and it's > probably been ZFS that caused it. I unfortunately neither had a way to > get back in or break to a kernel debugger, so information is sparse. This used to be a silent deadlock before I added the printf() and the call to OOM. :-P Do you just want to ratelimit the printf? We have an API to ratelimit printf's already. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 15:04:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C331106564A for ; Mon, 2 Jul 2012 15:04:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 522418FC1B for ; Mon, 2 Jul 2012 15:04:37 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 205F3B99A; Mon, 2 Jul 2012 11:04:37 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 2 Jul 2012 10:50:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201207010654.58777.erichfreebsdlist@ovitrap.com> In-Reply-To: <201207010654.58777.erichfreebsdlist@ovitrap.com> MIME-Version: 1.0 Message-Id: <201207021050.59694.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.7 (bigwig.baldwin.cx); Mon, 02 Jul 2012 11:04:37 -0400 (EDT) Cc: Erich Dollansky , AN Subject: Re: problem with top X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 15:04:38 -0000 On Saturday, June 30, 2012 7:54:58 pm Erich Dollansky wrote: > Hi, > > On Sunday, July 01, 2012 06:51:41 AM AN wrote: > > FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #23 r237852: Sat Jun 30 > > 18:45:27 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 > > > > After a recent upgrade, I am seeing a formatting issue with top. > > > > top -SPH -s 1: > > > > last pid: 26011; load averages: 3.61, 2.80, 1.56 up > > 0+00:23:30 19:48:46 > > 268 processes: 6 running, 245 sleeping, 17 waiting > > CPU 0: 22.0% user, 0.0% nice, 0.8% system, 0.8% interrupt, 76.4% idle > > CPU 16877.6ctive, 2313M Inact, 6.3M Wired, 3 0.8 Cache, 1440M65.4, 7674M > > Free > > CPU 2: 28.3% user, 0.0% nice, 2.4% system, 0.0% interrupt, 69.3% idle > > CPU 3: 36.2% user, 0.0% nice, 1.6% system, 0.0% interrupt, 62.2% idle > > Mem: 455M Active, 2302M Inact, 3151M Wired, 3900K Cache, 1440M Buf, 7943M > > Free > > Swap: 20G Total, 20G Free > > > > > > Seems like the entry for CPU 1 is wrong. > > I also noticed this but thought it is of temporary nature. The data of CPU 1 is getting overwritten by the data of the memory usage. Ah, I think I have found the bug for this, can you try this change: Index: usr.bin/top/machine.c =================================================================== --- machine.c (revision 225593) +++ machine.c (working copy) @@ -263,6 +263,7 @@ update_layout(void) { y_mem = 3; + y_arc = 4; y_swap = 4 + arc_enabled; y_idlecursor = 5 + arc_enabled; y_message = 5 + arc_enabled; @@ -271,7 +272,8 @@ update_layout(void) Header_lines = 7 + arc_enabled; if (pcpu_stats) { - y_mem = ncpus - 1; + y_mem += ncpus - 1; + y_arc += ncpus - 1; y_swap += ncpus - 1; y_idlecursor += ncpus - 1; y_message += ncpus - 1; -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 15:40:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43F68106566C; Mon, 2 Jul 2012 15:40:21 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1EEF78FC16; Mon, 2 Jul 2012 15:40:20 +0000 (UTC) Received: from sa-nc-common-101.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q62Fdvph004834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Jul 2012 08:40:01 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120702124349.GC36368@mech-cluster241.men.bris.ac.uk> Date: Mon, 2 Jul 2012 08:40:02 -0700 Content-Transfer-Encoding: 7bit Message-Id: <3AE1BC28-ACFC-4714-9819-8E4B47739A83@xcllnt.net> References: <20120629104013.GA18398@mech-cluster241.men.bris.ac.uk> <46A64BD5-0B45-4039-9189-CAB0701B0AA6@xcllnt.net> <20120702124349.GC36368@mech-cluster241.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1278) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: ia64 r235474 panic on dump 0aLuf - / | restore -rf - : exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0xe00000001238f6e8) locked @ /usr/src/sys/kern/vfs_hash.c:79 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 15:40:21 -0000 On Jul 2, 2012, at 5:43 AM, Anton Shterenlikht wrote: >> >> I think you're kernel is seriously screwed-up. Do you have any >> non-standard (for ia64) kernel configuration options? > > I didn't think so. > The latest was this: *snip* Looks fine indeed. I have pretty much the same, except for the IPFILTER options. I'm not concerned about. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 16:31:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B88F8106566B; Mon, 2 Jul 2012 16:31:50 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 51DD18FC16; Mon, 2 Jul 2012 16:31:50 +0000 (UTC) Received: from [192.168.14.142] (unknown [62.49.66.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPSA id 3D62B25D3A02; Mon, 2 Jul 2012 16:31:49 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <201207021036.45567.jhb@freebsd.org> Date: Mon, 2 Jul 2012 16:31:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7BEE3948-EE35-48C2-B4B1-25E34087A4C4@lists.zabbadoz.net> <201207021036.45567.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: freebsd-current FreeBSD Subject: Re: swp_pager_meta_build DoS printf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 16:31:50 -0000 On 2. Jul 2012, at 14:36 , John Baldwin wrote: > On Sunday, July 01, 2012 8:23:31 am Bjoern A. Zeeb wrote: >> Hey, >>=20 >> hitting this printf in swp_pager_meta_build() >>=20 >> if (uma_zone_exhausted(swap_zone)) { >> printf("swap zone exhausted, increase = kern.maxswzone\n"); >> vm_pageout_oom(VM_OOM_SWAPZ); >> pause("swzonex", 10); >> } else >>=20 >> seems to be an effective way to put the machine into a state of no = recovery >> unless the memory situation would be able to clear itself. Not that = it wouldn't >> otherwise be any better but in addition having a couple of = tenthousands of these >> going to console as well is really not helpful to try to do anything = either. Can >> we make it a log() call or something? >>=20 >> /bz >>=20 >> PS: I am not sure as I have seen it on someone else's machines and = it's >> probably been ZFS that caused it. I unfortunately neither had a way = to >> get back in or break to a kernel debugger, so information is sparse. >=20 > This used to be a silent deadlock before I added the printf() and the = call to > OOM. :-P Do you just want to ratelimit the printf? We have an API to = ratelimit > printf's already. Ratelimit would be fine; I was writing that on the wrong time of the = wrong day to just get it out; could you do that? /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 16:42:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1BEA10657D2; Mon, 2 Jul 2012 16:42:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7ACE88FC0A; Mon, 2 Jul 2012 16:42:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q62Ggwse029614; Mon, 2 Jul 2012 12:42:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q62Ggw1E029586; Mon, 2 Jul 2012 16:42:58 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Jul 2012 16:42:58 GMT Message-Id: <201207021642.q62Ggw1E029586@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 16:42:59 -0000 TB --- 2012-07-02 16:39:32 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-02 16:39:32 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-02 16:39:32 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-02 16:39:32 - cleaning the object tree TB --- 2012-07-02 16:39:32 - cvsupping the source tree TB --- 2012-07-02 16:39:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-02 16:40:32 - building world TB --- 2012-07-02 16:40:32 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 16:40:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 16:40:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 16:40:32 - SRCCONF=/dev/null TB --- 2012-07-02 16:40:32 - TARGET=ia64 TB --- 2012-07-02 16:40:32 - TARGET_ARCH=ia64 TB --- 2012-07-02 16:40:32 - TZ=UTC TB --- 2012-07-02 16:40:32 - __MAKE_CONF=/dev/null TB --- 2012-07-02 16:40:32 - cd /src TB --- 2012-07-02 16:40:32 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 2 16:40:33 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.bin/ypwhich (cleandir) rm -f ypwhich ypwhich.o ypwhich.1.gz ypwhich.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.sbin (cleandir) "Makefile", line 262: Malformed conditional (${PK_PKGBOOTSTRAP} != "no") "Makefile", line 264: if-less endif make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-02 16:42:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-02 16:42:58 - ERROR: failed to build world TB --- 2012-07-02 16:42:58 - 85.10 user 18.66 system 205.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 16:46:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4F4C106567B; Mon, 2 Jul 2012 16:46:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9278FC14; Mon, 2 Jul 2012 16:46:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q62GkUYR057615; Mon, 2 Jul 2012 12:46:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q62GkTF5057610; Mon, 2 Jul 2012 16:46:29 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Jul 2012 16:46:29 GMT Message-Id: <201207021646.q62GkTF5057610@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 16:46:30 -0000 TB --- 2012-07-02 16:42:58 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-02 16:42:58 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-02 16:42:58 - starting HEAD tinderbox run for mips/mips TB --- 2012-07-02 16:42:58 - cleaning the object tree TB --- 2012-07-02 16:42:58 - cvsupping the source tree TB --- 2012-07-02 16:42:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-07-02 16:44:04 - building world TB --- 2012-07-02 16:44:04 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 16:44:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 16:44:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 16:44:04 - SRCCONF=/dev/null TB --- 2012-07-02 16:44:04 - TARGET=mips TB --- 2012-07-02 16:44:04 - TARGET_ARCH=mips TB --- 2012-07-02 16:44:04 - TZ=UTC TB --- 2012-07-02 16:44:04 - __MAKE_CONF=/dev/null TB --- 2012-07-02 16:44:04 - cd /src TB --- 2012-07-02 16:44:04 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 2 16:44:05 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.bin/ypwhich (cleandir) rm -f ypwhich ypwhich.o ypwhich.1.gz ypwhich.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.sbin (cleandir) "Makefile", line 262: Malformed conditional (${PK_PKGBOOTSTRAP} != "no") "Makefile", line 264: if-less endif make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-02 16:46:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-02 16:46:29 - ERROR: failed to build world TB --- 2012-07-02 16:46:29 - 88.08 user 18.24 system 211.06 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 16:52:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E81AC106566B; Mon, 2 Jul 2012 16:52:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB848FC16; Mon, 2 Jul 2012 16:52:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q62GqsLV090815; Mon, 2 Jul 2012 12:52:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q62GqrHl090814; Mon, 2 Jul 2012 16:52:53 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Jul 2012 16:52:53 GMT Message-Id: <201207021652.q62GqrHl090814@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 16:52:55 -0000 TB --- 2012-07-02 16:46:30 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-02 16:46:30 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-02 16:46:30 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-02 16:46:30 - cleaning the object tree TB --- 2012-07-02 16:46:30 - cvsupping the source tree TB --- 2012-07-02 16:46:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-02 16:47:24 - building world TB --- 2012-07-02 16:47:24 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 16:47:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 16:47:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 16:47:24 - SRCCONF=/dev/null TB --- 2012-07-02 16:47:24 - TARGET=powerpc TB --- 2012-07-02 16:47:24 - TARGET_ARCH=powerpc TB --- 2012-07-02 16:47:24 - TZ=UTC TB --- 2012-07-02 16:47:24 - __MAKE_CONF=/dev/null TB --- 2012-07-02 16:47:24 - cd /src TB --- 2012-07-02 16:47:24 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 2 16:47:25 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.bin/ypwhich (cleandir) rm -f ypwhich ypwhich.o ypwhich.1.gz ypwhich.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.sbin (cleandir) "Makefile", line 262: Malformed conditional (${PK_PKGBOOTSTRAP} != "no") "Makefile", line 264: if-less endif make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-02 16:52:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-02 16:52:53 - ERROR: failed to build world TB --- 2012-07-02 16:52:53 - 238.14 user 32.23 system 383.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 16:59:41 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85464106566B; Mon, 2 Jul 2012 16:59:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 268978FC18; Mon, 2 Jul 2012 16:59:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q62GxeKn026795; Mon, 2 Jul 2012 12:59:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q62GxeGK026787; Mon, 2 Jul 2012 16:59:40 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Jul 2012 16:59:40 GMT Message-Id: <201207021659.q62GxeGK026787@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 16:59:41 -0000 TB --- 2012-07-02 16:52:54 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-02 16:52:54 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-02 16:52:54 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-02 16:52:54 - cleaning the object tree TB --- 2012-07-02 16:52:54 - cvsupping the source tree TB --- 2012-07-02 16:52:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-02 16:53:51 - building world TB --- 2012-07-02 16:53:51 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 16:53:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 16:53:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 16:53:51 - SRCCONF=/dev/null TB --- 2012-07-02 16:53:51 - TARGET=powerpc TB --- 2012-07-02 16:53:51 - TARGET_ARCH=powerpc64 TB --- 2012-07-02 16:53:51 - TZ=UTC TB --- 2012-07-02 16:53:51 - __MAKE_CONF=/dev/null TB --- 2012-07-02 16:53:51 - cd /src TB --- 2012-07-02 16:53:51 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 2 16:53:52 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.bin/ypwhich (cleandir) rm -f ypwhich ypwhich.o ypwhich.1.gz ypwhich.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.sbin (cleandir) "Makefile", line 262: Malformed conditional (${PK_PKGBOOTSTRAP} != "no") "Makefile", line 264: if-less endif make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-02 16:59:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-02 16:59:40 - ERROR: failed to build world TB --- 2012-07-02 16:59:40 - 238.30 user 33.30 system 406.26 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 17:04:13 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B14F106564A; Mon, 2 Jul 2012 17:04:13 +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 20F2A8FC12; Mon, 2 Jul 2012 17:04:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q62H4Ctt052278; Mon, 2 Jul 2012 13:04:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q62H4CkD052269; Mon, 2 Jul 2012 17:04:12 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Jul 2012 17:04:12 GMT Message-Id: <201207021704.q62H4CkD052269@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 17:04:13 -0000 TB --- 2012-07-02 16:59:40 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-02 16:59:40 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-02 16:59:40 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-02 16:59:40 - cleaning the object tree TB --- 2012-07-02 16:59:40 - cvsupping the source tree TB --- 2012-07-02 16:59:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-02 17:00:51 - building world TB --- 2012-07-02 17:00:51 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 17:00:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 17:00:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 17:00:51 - SRCCONF=/dev/null TB --- 2012-07-02 17:00:51 - TARGET=sparc64 TB --- 2012-07-02 17:00:51 - TARGET_ARCH=sparc64 TB --- 2012-07-02 17:00:51 - TZ=UTC TB --- 2012-07-02 17:00:51 - __MAKE_CONF=/dev/null TB --- 2012-07-02 17:00:51 - cd /src TB --- 2012-07-02 17:00:51 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 2 17:00:51 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.bin/ypwhich (cleandir) rm -f ypwhich ypwhich.o ypwhich.1.gz ypwhich.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.sbin (cleandir) "Makefile", line 262: Malformed conditional (${PK_PKGBOOTSTRAP} != "no") "Makefile", line 264: if-less endif make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-02 17:04:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-02 17:04:12 - ERROR: failed to build world TB --- 2012-07-02 17:04:12 - 85.69 user 17.27 system 271.68 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 20:01:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72FE7106566B; Mon, 2 Jul 2012 20:01:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD4D8FC1F; Mon, 2 Jul 2012 20:01:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q62K1cIZ000698; Mon, 2 Jul 2012 16:01:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q62K1ceD000693; Mon, 2 Jul 2012 20:01:38 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Jul 2012 20:01:38 GMT Message-Id: <201207022001.q62K1ceD000693@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 20:01:39 -0000 TB --- 2012-07-02 14:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-02 14:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-02 14:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-02 14:30:00 - cleaning the object tree TB --- 2012-07-02 14:35:26 - cvsupping the source tree TB --- 2012-07-02 14:35:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-02 14:36:39 - building world TB --- 2012-07-02 14:36:39 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 14:36:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 14:36:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 14:36:39 - SRCCONF=/dev/null TB --- 2012-07-02 14:36:39 - TARGET=i386 TB --- 2012-07-02 14:36:39 - TARGET_ARCH=i386 TB --- 2012-07-02 14:36:39 - TZ=UTC TB --- 2012-07-02 14:36:39 - __MAKE_CONF=/dev/null TB --- 2012-07-02 14:36:39 - cd /src TB --- 2012-07-02 14:36:39 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 2 14:36:40 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 2 17:04:18 UTC 2012 TB --- 2012-07-02 17:04:18 - generating LINT kernel config TB --- 2012-07-02 17:04:18 - cd /src/sys/i386/conf TB --- 2012-07-02 17:04:18 - /usr/bin/make -B LINT TB --- 2012-07-02 17:04:18 - cd /src/sys/i386/conf TB --- 2012-07-02 17:04:18 - /usr/sbin/config -m LINT TB --- 2012-07-02 17:04:18 - building LINT kernel TB --- 2012-07-02 17:04:18 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 17:04:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 17:04:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 17:04:18 - SRCCONF=/dev/null TB --- 2012-07-02 17:04:18 - TARGET=i386 TB --- 2012-07-02 17:04:18 - TARGET_ARCH=i386 TB --- 2012-07-02 17:04:18 - TZ=UTC TB --- 2012-07-02 17:04:18 - __MAKE_CONF=/dev/null TB --- 2012-07-02 17:04:18 - cd /src TB --- 2012-07-02 17:04:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 2 17:04:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Jul 2 17:35:42 UTC 2012 TB --- 2012-07-02 17:35:42 - cd /src/sys/i386/conf TB --- 2012-07-02 17:35:42 - /usr/sbin/config -m LINT-NOINET TB --- 2012-07-02 17:35:42 - building LINT-NOINET kernel TB --- 2012-07-02 17:35:42 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 17:35:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 17:35:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 17:35:42 - SRCCONF=/dev/null TB --- 2012-07-02 17:35:42 - TARGET=i386 TB --- 2012-07-02 17:35:42 - TARGET_ARCH=i386 TB --- 2012-07-02 17:35:42 - TZ=UTC TB --- 2012-07-02 17:35:42 - __MAKE_CONF=/dev/null TB --- 2012-07-02 17:35:42 - cd /src TB --- 2012-07-02 17:35:42 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Mon Jul 2 17:35:42 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Mon Jul 2 18:03:15 UTC 2012 TB --- 2012-07-02 18:03:15 - cd /src/sys/i386/conf TB --- 2012-07-02 18:03:15 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-07-02 18:03:15 - building LINT-NOINET6 kernel TB --- 2012-07-02 18:03:15 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 18:03:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 18:03:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 18:03:15 - SRCCONF=/dev/null TB --- 2012-07-02 18:03:15 - TARGET=i386 TB --- 2012-07-02 18:03:15 - TARGET_ARCH=i386 TB --- 2012-07-02 18:03:15 - TZ=UTC TB --- 2012-07-02 18:03:15 - __MAKE_CONF=/dev/null TB --- 2012-07-02 18:03:15 - cd /src TB --- 2012-07-02 18:03:15 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Jul 2 18:03:15 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Mon Jul 2 18:30:48 UTC 2012 TB --- 2012-07-02 18:30:48 - cd /src/sys/i386/conf TB --- 2012-07-02 18:30:48 - /usr/sbin/config -m LINT-NOIP TB --- 2012-07-02 18:30:48 - building LINT-NOIP kernel TB --- 2012-07-02 18:30:48 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 18:30:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 18:30:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 18:30:48 - SRCCONF=/dev/null TB --- 2012-07-02 18:30:48 - TARGET=i386 TB --- 2012-07-02 18:30:48 - TARGET_ARCH=i386 TB --- 2012-07-02 18:30:48 - TZ=UTC TB --- 2012-07-02 18:30:48 - __MAKE_CONF=/dev/null TB --- 2012-07-02 18:30:48 - cd /src TB --- 2012-07-02 18:30:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Mon Jul 2 18:30:48 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Mon Jul 2 18:55:57 UTC 2012 TB --- 2012-07-02 18:55:57 - cd /src/sys/i386/conf TB --- 2012-07-02 18:55:57 - /usr/sbin/config -m LINT-VIMAGE TB --- 2012-07-02 18:55:57 - building LINT-VIMAGE kernel TB --- 2012-07-02 18:55:57 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 18:55:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 18:55:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 18:55:57 - SRCCONF=/dev/null TB --- 2012-07-02 18:55:57 - TARGET=i386 TB --- 2012-07-02 18:55:57 - TARGET_ARCH=i386 TB --- 2012-07-02 18:55:57 - TZ=UTC TB --- 2012-07-02 18:55:57 - __MAKE_CONF=/dev/null TB --- 2012-07-02 18:55:57 - cd /src TB --- 2012-07-02 18:55:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Mon Jul 2 18:55:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Mon Jul 2 19:24:08 UTC 2012 TB --- 2012-07-02 19:24:08 - cd /src/sys/i386/conf TB --- 2012-07-02 19:24:08 - /usr/sbin/config -m GENERIC TB --- 2012-07-02 19:24:08 - building GENERIC kernel TB --- 2012-07-02 19:24:08 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 19:24:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 19:24:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 19:24:08 - SRCCONF=/dev/null TB --- 2012-07-02 19:24:08 - TARGET=i386 TB --- 2012-07-02 19:24:08 - TARGET_ARCH=i386 TB --- 2012-07-02 19:24:08 - TZ=UTC TB --- 2012-07-02 19:24:08 - __MAKE_CONF=/dev/null TB --- 2012-07-02 19:24:08 - cd /src TB --- 2012-07-02 19:24:08 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jul 2 19:24:08 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Jul 2 19:47:46 UTC 2012 TB --- 2012-07-02 19:47:46 - cd /src/sys/i386/conf TB --- 2012-07-02 19:47:46 - /usr/sbin/config -m PAE TB --- 2012-07-02 19:47:46 - building PAE kernel TB --- 2012-07-02 19:47:46 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 19:47:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 19:47:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 19:47:46 - SRCCONF=/dev/null TB --- 2012-07-02 19:47:46 - TARGET=i386 TB --- 2012-07-02 19:47:46 - TARGET_ARCH=i386 TB --- 2012-07-02 19:47:46 - TZ=UTC TB --- 2012-07-02 19:47:46 - __MAKE_CONF=/dev/null TB --- 2012-07-02 19:47:46 - cd /src TB --- 2012-07-02 19:47:46 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Mon Jul 2 19:47:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Mon Jul 2 19:54:13 UTC 2012 TB --- 2012-07-02 19:54:13 - cd /src/sys/i386/conf TB --- 2012-07-02 19:54:13 - /usr/sbin/config -m XBOX TB --- 2012-07-02 19:54:13 - building XBOX kernel TB --- 2012-07-02 19:54:13 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 19:54:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 19:54:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 19:54:13 - SRCCONF=/dev/null TB --- 2012-07-02 19:54:13 - TARGET=i386 TB --- 2012-07-02 19:54:13 - TARGET_ARCH=i386 TB --- 2012-07-02 19:54:13 - TZ=UTC TB --- 2012-07-02 19:54:13 - __MAKE_CONF=/dev/null TB --- 2012-07-02 19:54:13 - cd /src TB --- 2012-07-02 19:54:13 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Mon Jul 2 19:54:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Mon Jul 2 19:57:12 UTC 2012 TB --- 2012-07-02 19:57:12 - cd /src/sys/i386/conf TB --- 2012-07-02 19:57:12 - /usr/sbin/config -m XEN TB --- 2012-07-02 19:57:13 - building XEN kernel TB --- 2012-07-02 19:57:13 - CROSS_BUILD_TESTING=YES TB --- 2012-07-02 19:57:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-02 19:57:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-02 19:57:13 - SRCCONF=/dev/null TB --- 2012-07-02 19:57:13 - TARGET=i386 TB --- 2012-07-02 19:57:13 - TARGET_ARCH=i386 TB --- 2012-07-02 19:57:13 - TZ=UTC TB --- 2012-07-02 19:57:13 - __MAKE_CONF=/dev/null TB --- 2012-07-02 19:57:13 - cd /src TB --- 2012-07-02 19:57:13 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Mon Jul 2 19:57:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/in_cksum.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/initcpu.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/io.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/k6_mem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/machdep.c cc1: warnings being treated as errors /src/sys/i386/i386/machdep.c: In function 'getmemsize': /src/sys/i386/i386/machdep.c:2179: warning: unused variable 'res' [-Wunused-variable] *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-02 20:01:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-02 20:01:38 - ERROR: failed to build XEN kernel TB --- 2012-07-02 20:01:38 - 15989.87 user 2085.95 system 19898.19 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 20:12:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A1341065673; Mon, 2 Jul 2012 20:12:12 +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 2E39C8FC1A; Mon, 2 Jul 2012 20:12:10 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q62KCJ8A033019; Mon, 2 Jul 2012 23:12:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q62KC77s099146; Mon, 2 Jul 2012 23:12:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q62KC6PH099145; Mon, 2 Jul 2012 23:12:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Jul 2012 23:12:06 +0300 From: Konstantin Belousov To: Alexander Kabaev Message-ID: <20120702201206.GV2337@deviant.kiev.zoral.com.ua> References: <20120702061219.GA16671@infradead.org> <20120702150339.GA7226@kan.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0l0ctNieuEHM0Mkh" Content-Disposition: inline In-Reply-To: <20120702150339.GA7226@kan.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Attilio Rao , "C. P. Ghost" , Christoph Hellwig , Russell Cattelan , freebsd-current@freebsd.org, FreeBSD FS Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 20:12:12 -0000 --0l0ctNieuEHM0Mkh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 02, 2012 at 11:03:40AM -0400, Alexander Kabaev wrote: > On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote: > > On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: > > > anything by SoC involved people about NTFS and certainly I don't see a > > > plan to get XFS locked. > >=20 > > Stupid question, but what amount of locking does XFS in FreeBSD still > > need? I'm one of the maintainer of XFS on Linux, and while I know > > FreeBSD imported a really old version compared to the current one the > > codebases on IRIX and later Linux never relied on any global Giant-style > > locking. So if there is anything to fix it would be the in the small > > bits of FreeBSD-specific code. > >=20 >=20 > When I stopped being interested in XFS, I left is marked as non-MPSAFE > entirely because of the lack of proper testing and because VFS locking > was still evolving, there was no officially proper way of locking the > FS and no other FS in the tree was MPSAFE. At that time the only > problematic area was around inode instantiation, but sereval other > lockingi changes have made it into the tree since then, namely ones that > deal with insmntque and also VOP_LOOKUP changes. To mark XFS MPSAFE, one > needs to simply audit the code and make sure it still makse sense for tod= ay's > VFS, which is not a huge amount of work. One step further woule be to take > most of the XFS from under the exclusive vnode locking to improve the > performance. If filesystem uses some global internal locks, that locks usually are placed after the vnode locks in global lock order, because VOP methods call into fs with vnode locked. Then, VOP_LOOKUP() usual sequence of events, when method is called with lookup directory locked, causes LOR. It appears because you lock global lock upon entry into VOP_LOOKUP(), and then need to lock the returned vnode. Dropping global lock inside VOP_LOOKUP() usually exposes races which were the reason to introduce the global lock. Having filesystem non-MPSAFE makes the LOR go away without the need to drop global lock. Example of FreeBSD native filesystem which suffered from this issue and required quite non-trivial handling is devfs. Devfs uses per-mount global lock. See devfs_allocv() and devfs_allocv_drop_refs() for the gory details. --0l0ctNieuEHM0Mkh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/yAJYACgkQC3+MBN1Mb4jGHQCfbUFjkOyR04wK/OubK1LWcRW/ hZsAoIk6tJQ2niBpuL3/3OmDFvfLL9hq =lP1N -----END PGP SIGNATURE----- --0l0ctNieuEHM0Mkh-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 21:39:56 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F154106564A; Mon, 2 Jul 2012 21:39:56 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id F0AA48FC0C; Mon, 2 Jul 2012 21:39:55 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id q62Ldt9m097390; Mon, 2 Jul 2012 14:39:55 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.5/Submit) id q62Ldtow097388; Mon, 2 Jul 2012 14:39:55 -0700 (PDT) (envelope-from obrien) Date: Mon, 2 Jul 2012 14:39:55 -0700 From: "David O'Brien" To: "Simon L. B. Nielsen" Message-ID: <20120702213955.GA96547@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "Simon L. B. Nielsen" , current@FreeBSD.org References: <2A1FD996-9AB7-4F8D-B22D-0B3F0437C0F2@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A1FD996-9AB7-4F8D-B22D-0B3F0437C0F2@FreeBSD.org> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@FreeBSD.org Subject: Re: SVN2CVS exporter down X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 21:39:56 -0000 On Sun, Jul 01, 2012 at 11:14:45AM +0100, Simon L. B. Nielsen wrote: > On 1 Jul 2012, at 10:20, Bjoern A. Zeeb wrote: > > Just FYI, > > > > the svn2cvs exporter is currently down due to > > http://svn.freebsd.org/changeset/base/237860 . > > I'll fix it as soon as I get back from lunch, so should be back in a > > few hours. > > Fixed. Please try not to replace files or even worse directories. Thanks. Simon, Are you saying we are now restricted in the svn operations we can perform due to the lack of the svn2cvs exporter to consume them? If so, this doesn't seem desirable... we moved to Subversion to obtain such operations as file and directory moves. I suspect such operations will only happen with increased frequency after the Ports Collection moves to Subversion. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 21:56:02 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 984711065675; Mon, 2 Jul 2012 21:56:02 +0000 (UTC) (envelope-from simon@FreeBSD.org) Received: from emx.nitro.dk (emx.nitro.dk [IPv6:2a01:4f8:120:7384::102]) by mx1.freebsd.org (Postfix) with ESMTP id 2DBC48FC19; Mon, 2 Jul 2012 21:56:02 +0000 (UTC) Received: from mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) by emx.nitro.dk (Postfix) with ESMTP id 5804A20E18E; Mon, 2 Jul 2012 21:56:01 +0000 (UTC) Received: from emx.nitro.dk ([127.0.1.2]) by mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) (amavisd-new, port 10024) with LMTP id SUaVsTtvEHZu; Mon, 2 Jul 2012 21:55:59 +0000 (UTC) Received: from [192.168.4.24] (unknown [89.100.2.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by emx.nitro.dk (Postfix) with ESMTPSA id 0364A20E18B; Mon, 2 Jul 2012 21:55:58 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Simon L. B. Nielsen" In-Reply-To: <20120702213955.GA96547@dragon.NUXI.org> Date: Mon, 2 Jul 2012 22:55:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <25EA13B6-10A2-404C-8DDA-8C1DD39B13DB@FreeBSD.org> References: <2A1FD996-9AB7-4F8D-B22D-0B3F0437C0F2@FreeBSD.org> <20120702213955.GA96547@dragon.NUXI.org> To: obrien@FreeBSD.org X-Mailer: Apple Mail (2.1278) Cc: current@FreeBSD.org Subject: Re: SVN2CVS exporter down X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 21:56:02 -0000 On 2 Jul 2012, at 22:39, David O'Brien wrote: > On Sun, Jul 01, 2012 at 11:14:45AM +0100, Simon L. B. Nielsen wrote: >> On 1 Jul 2012, at 10:20, Bjoern A. Zeeb wrote: >>> Just FYI, >>>=20 >>> the svn2cvs exporter is currently down due to >>> http://svn.freebsd.org/changeset/base/237860 . >>> I'll fix it as soon as I get back from lunch, so should be back in a >>> few hours. >>=20 >> Fixed. Please try not to replace files or even worse directories. = Thanks. >=20 > Simon, > Are you saying we are now restricted in the svn operations we can = perform > due to the lack of the svn2cvs exporter to consume them? Basically yes, though it's not a new thing - we have been from day 1 of = using svn. Or rather, each time somebody "replaces" a file we (peter, = bz, or me) have to manually hack svn2cvs to handle the case with the = increasing risk that we will do it wrong and svn/cvs will be out of = sync. > If so, this doesn't seem desirable... we moved to Subversion to obtain > such operations as file and directory moves. You can move files and dirs, just as long as you don't move them on top = of existing files. The problem is that that creates an 'remove' and = 'add' operation in the same changeset which CVS cannot handle. Tested patches are accepted = (http://svnweb.freebsd.org/base/svnadmin/tools/export.py), or even = better - work on killing off CVS sooner rather than later. > I suspect such operations will only happen with increased frequency = after > the Ports Collection moves to Subversion. Ports will explicitly deny "Replaced" files in a presubmit check. I will = look at adding the same for src once I get a chance. --=20 Simon L. B. Nielsen From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 21:58:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B29451065670; Mon, 2 Jul 2012 21:58:29 +0000 (UTC) (envelope-from cattelan@thebarn.com) Received: from x.digitalelves.com (x.digitalelves.com [209.98.77.55]) by mx1.freebsd.org (Postfix) with ESMTP id 79AED8FC17; Mon, 2 Jul 2012 21:58:29 +0000 (UTC) Received: from Russells-Lion-Hackintosh.local (c-66-41-26-220.hsd1.mn.comcast.net [66.41.26.220]) (authenticated bits=0) by x.digitalelves.com (8.14.5/8.14.5) with ESMTP id q62LwOof083241 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 2 Jul 2012 16:58:26 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <4FF21980.2090607@thebarn.com> Date: Mon, 02 Jul 2012 16:58:24 -0500 From: Russell Cattelan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexander Kabaev References: <20120702061219.GA16671@infradead.org> <20120702150339.GA7226@kan.dyndns.org> In-Reply-To: <20120702150339.GA7226@kan.dyndns.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig63054884B80B5C3C56A7DE05" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Christoph Hellwig , Attilio Rao , freebsd-current@freebsd.org, "C. P. Ghost" , FreeBSD FS Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 21:58:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig63054884B80B5C3C56A7DE05 Content-Type: multipart/mixed; boundary="------------030107020906030202000708" This is a multi-part message in MIME format. --------------030107020906030202000708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/2/12 10:03 AM, Alexander Kabaev wrote: > On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote: >> On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: >>> anything by SoC involved people about NTFS and certainly I don't see = a >>> plan to get XFS locked. >> >> Stupid question, but what amount of locking does XFS in FreeBSD still >> need? I'm one of the maintainer of XFS on Linux, and while I know >> FreeBSD imported a really old version compared to the current one the >> codebases on IRIX and later Linux never relied on any global Giant-sty= le >> locking. So if there is anything to fix it would be the in the small >> bits of FreeBSD-specific code. >> >=20 > When I stopped being interested in XFS, I left is marked as non-MPSAFE > entirely because of the lack of proper testing and because VFS locking > was still evolving, there was no officially proper way of locking the > FS and no other FS in the tree was MPSAFE. At that time the only > problematic area was around inode instantiation, but sereval other > lockingi changes have made it into the tree since then, namely ones tha= t > deal with insmntque and also VOP_LOOKUP changes. To mark XFS MPSAFE, on= e > needs to simply audit the code and make sure it still makse sense for t= oday's > VFS, which is not a huge amount of work. One step further woule be to t= ake > most of the XFS from under the exclusive vnode locking to improve the > performance. >=20 > And there is a third option - just let current XFS port die and start w= ith > newer version. >=20 I like option 3. The current code is way way out of date and doesn't even reflect the last round of sync up I did. Unless somebody says "hey I'm using XFS" we could just let the current code go and reintroduce a current port if it ever receives the needed attention. Unfortunately I think there were would have be be some sponsorship of the effort since getting xfs fully supported would require some significant developer hours. If anybody is interesting in the current state of things here is my git tree that I cleaned up and put online during BSDCan. http://git.digitalelves.com/?p=3DFreeBSD_xfs.git;a=3Dsummary xfs-FreeBSD_7 has the last somewhat functional code. This was based on a code drop from linux XFS at the time. Log recovery was just starting to come to life (very simple recovery would work) Write was working to the point there you could do a single thread to the fs and have the data cmp back with the original file. Read also still works but is unstable. xfs-FreeBSD_9 is quick code drop I did a month or so ago. I does not compile as many of the linux files moved around so not all the compat stuff lines up and some new compat code needs to written. -Russell --------------030107020906030202000708-- --------------enig63054884B80B5C3C56A7DE05 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/yGYAACgkQNRmM+OaGhBhcYQCfYSzCjbJVmv+IMrdwoxARmHbs aVkAnRbx2YzxZrT6AY76vuB53sCTUZp9 =Ajfl -----END PGP SIGNATURE----- --------------enig63054884B80B5C3C56A7DE05-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 2 22:18:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26449106564A; Mon, 2 Jul 2012 22:18:02 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 961348FC12; Mon, 2 Jul 2012 22:18:01 +0000 (UTC) Received: by qcsg15 with SMTP id g15so3709155qcs.13 for ; Mon, 02 Jul 2012 15:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=YA229ZxuTLp7wYV3QgrlsfH1OApy1puoZbXNkWpw698=; b=AwjMYg/h0PYOhGM2qZGbOfy2ODnu/4UQt4uD8YWgcpy2mh78yQ4Gl+z174ZHZeajUM dkWx1y/YVyd+qtn5/aOhcgDohf+AXpGaTRK0x12dDNU9boqKmrxqRBJpyuOAqK5XAiGA Pn3F6p2LlQaLkDJPeKoK+J+YUg1pjgY+M0wKCkkSsUeXnsZTru11X0dtDLJSBHiD9paG so2i30F+S5x+bUnuEl050dQkFqJUAmqr3rYUqNT7YT4TOagp4X4WGom3bzRS3uzeMJ2h Uo+PANayujtO3NlFJwvVstNm3XUvzUgc8Vo8BuMe1henDuqBVyM/UQus4OgZh7WPs1WF mkmw== Received: by 10.224.181.6 with SMTP id bw6mr25970184qab.74.1341267480796; Mon, 02 Jul 2012 15:18:00 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id cz12sm33957314qab.5.2012.07.02.15.17.59 (version=SSLv3 cipher=OTHER); Mon, 02 Jul 2012 15:17:59 -0700 (PDT) Date: Mon, 2 Jul 2012 18:17:48 -0400 From: Alexander Kabaev To: Konstantin Belousov Message-ID: <20120702181748.6bb126f6@kan.dyndns.org> In-Reply-To: <20120702201206.GV2337@deviant.kiev.zoral.com.ua> References: <20120702061219.GA16671@infradead.org> <20120702150339.GA7226@kan.dyndns.org> <20120702201206.GV2337@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/tC9gBXvdben2oNR.d08Mkfp"; protocol="application/pgp-signature" Cc: Attilio Rao , "C. P. Ghost" , Russell, Christoph Hellwig , Cattelan , freebsd-current@freebsd.org, FreeBSD FS Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jul 2012 22:18:02 -0000 --Sig_/tC9gBXvdben2oNR.d08Mkfp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 2 Jul 2012 23:12:06 +0300 Konstantin Belousov wrote: > On Mon, Jul 02, 2012 at 11:03:40AM -0400, Alexander Kabaev wrote: > > On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote: > > > On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: > > > > anything by SoC involved people about NTFS and certainly I > > > > don't see a plan to get XFS locked. > > >=20 > > > Stupid question, but what amount of locking does XFS in FreeBSD > > > still need? I'm one of the maintainer of XFS on Linux, and while > > > I know FreeBSD imported a really old version compared to the > > > current one the codebases on IRIX and later Linux never relied on > > > any global Giant-style locking. So if there is anything to fix > > > it would be the in the small bits of FreeBSD-specific code. > > >=20 > >=20 > > When I stopped being interested in XFS, I left is marked as > > non-MPSAFE entirely because of the lack of proper testing and > > because VFS locking was still evolving, there was no officially > > proper way of locking the FS and no other FS in the tree was > > MPSAFE. At that time the only problematic area was around inode > > instantiation, but sereval other lockingi changes have made it into > > the tree since then, namely ones that deal with insmntque and also > > VOP_LOOKUP changes. To mark XFS MPSAFE, one needs to simply audit > > the code and make sure it still makse sense for today's VFS, which > > is not a huge amount of work. One step further woule be to take > > most of the XFS from under the exclusive vnode locking to improve > > the performance. >=20 > If filesystem uses some global internal locks, that locks usually are > placed after the vnode locks in global lock order, because VOP methods > call into fs with vnode locked. Then, VOP_LOOKUP() usual sequence of > events, when method is called with lookup directory locked, causes > LOR. It appears because you lock global lock upon entry into > VOP_LOOKUP(), and then need to lock the returned vnode. > Dropping global lock inside VOP_LOOKUP() usually exposes races which > were the reason to introduce the global lock. Having filesystem > non-MPSAFE makes the LOR go away without the need to drop global lock. >=20 > Example of FreeBSD native filesystem which suffered from this issue > and required quite non-trivial handling is devfs. Devfs uses per-mount > global lock. See devfs_allocv() and devfs_allocv_drop_refs() for > the gory details. All very informative, though misplaced in case of XFS. XFS does not use global lock internally, it is quite well locked inside and exclusive _VNODE_ lock we take by default in all methods is usually unnecessary as all it does it prevents other locks in XFS proper from having any useful function. --=20 Alexander Kabaev --Sig_/tC9gBXvdben2oNR.d08Mkfp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFP8h4VQ6z1jMm+XZYRAhbnAJwJ9FKxAHEhZQS3re4WJZZA5Jr4+wCcCXv8 AA5y7bwN5mHu/RbP0pxXh1M= =u2RK -----END PGP SIGNATURE----- --Sig_/tC9gBXvdben2oNR.d08Mkfp-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 01:21:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AA4E1065670 for ; Tue, 3 Jul 2012 01:21:48 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id DBF448FC08 for ; Tue, 3 Jul 2012 01:21:47 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 2895C83A0 for ; Tue, 3 Jul 2012 10:21:46 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id o3vFnZ0Y5xsc for ; Tue, 3 Jul 2012 10:21:41 +0900 (JST) Received: from biotite.tackymt.homeip.net (biotite.tackymt.homeip.net [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA for ; Tue, 3 Jul 2012 10:21:41 +0900 (JST) Date: Tue, 3 Jul 2012 10:21:42 +0900 From: Taku YAMAMOTO To: freebsd-current@freebsd.org Message-Id: <20120703102142.6554b10e.taku@tackymt.homeip.net> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: A suspicious warning in sys/boot/zfs/zfsimpl.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jul 2012 01:21:48 -0000 When I built the world as of r237813, clang reported a warning which caught my attention. ===> sys/boot/zfs (all) clang -O2 -pipe -march=pentium4 -DBOOTPROG=\"zfsloader\" -I/usr/src/sys/boot/zfs/../common -I/usr/src/sys/boot/zfs/../.. -I. -I/usr/src/sys/boot/zfs/../../../lib/libstand -I/usr/src/sys/boot/zfs/../../cddl/boot/zfs -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Wformat -Wall -DNDEBUG -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/zfs/zfs.c -o zfs.o In file included from /usr/src/sys/boot/zfs/zfs.c:48: /usr/src/sys/boot/zfs/zfsimpl.c:2033:19: warning: array index 264 is past the end of the array (which contains 192 elements) [-Warray-bounds] memcpy(path, &dn.dn_bonus[sizeof(znode_phys_t)], ^ ~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/boot/zfs/../../cddl/boot/zfs/zfsimpl.h:788:2: note: array 'dn_bonus' declared here uint8_t dn_bonus[DN_MAX_BONUSLEN - sizeof (blkptr_t)]; ^ I don't have a zfs-powered machine, so I'm not sure whether this warning is false-positive or not. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 01:24:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31701106564A; Tue, 3 Jul 2012 01:24:39 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id D574A8FC08; Tue, 3 Jul 2012 01:24:38 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with ESMTP id q631OY8T025277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 2 Jul 2012 20:24:35 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 2 Jul 2012 20:24:34 -0500 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <4FEF81F5.3050509@cran.org.uk> Date: Mon, 2 Jul 2012 18:24:31 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4FEF81F5.3050509@cran.org.uk> To: Bruce Cran X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-07-03_01:2012-07-02, 2012-07-03, 1970-01-01 signatures=0 Cc: Devin Teske , McDowell , Ron, freebsd-current@freebsd.org Subject: Re: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 01:24:39 -0000 On Jun 30, 2012, at 3:47 PM, Bruce Cran wrote: > On 28/06/2012 00:11, Devin Teske wrote: >> I'd like to announce that I intend to import bsdconfig(8) today. >=20 > I haven't seen this get committed yet - was there a problem? >=20 No problems. A long weekend put the damper on the process but it has picked= up again. By week's end there should be more info. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 01:12:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCF09106566B for ; Tue, 3 Jul 2012 01:12:35 +0000 (UTC) (envelope-from kaho@ed.niigata-u.ac.jp) Received: from caav02.cais.niigata-u.ac.jp (caav02.cais.niigata-u.ac.jp [133.35.17.134]) by mx1.freebsd.org (Postfix) with ESMTP id 895D98FC08 for ; Tue, 3 Jul 2012 01:12:35 +0000 (UTC) Received: from caav02.cais.niigata-u.ac.jp (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C98D8282CAE; Tue, 3 Jul 2012 09:52:02 +0900 (JST) Received: from pf2.ed.niigata-u.ac.jp (pf2.ed.niigata-u.ac.jp [133.35.172.22]) by caav02.cais.niigata-u.ac.jp (Postfix) with ESMTPS id B4932282C9A; Tue, 3 Jul 2012 09:52:02 +0900 (JST) Received: from pf2.ed.niigata-u.ac.jp (localhost [127.0.0.1]) by pf2.ed.niigata-u.ac.jp (8.14.5/8.14.5) with ESMTP id q630pbEN006040; Tue, 3 Jul 2012 09:51:38 +0900 (JST) (envelope-from kaho@pf2.ed.niigata-u.ac.jp) To: Matthias Apitz References: <20120629133422.GA2233@tiny.Sisis.de> <201206301349.58930.erich@alogreentechnologies.com> <20120630151130.GA1106@tiny.Sisis.de> <201207010629.29148.erich@alogreentechnologies.com> <20120701065849.GA2681@tinyCurrent> X-Mailer: MH-E 8.2; MH 6.8.4.JP-3.05; GNU Emacs 23.4.1 User-Agent: EMH/1.14.1 SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.4 (amd64-portbld-freebsd10.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP-2 Date: Tue, 03 Jul 2012 09:51:37 +0900 Message-ID: <6039.1341276697@pf2.ed.niigata-u.ac.jp> From: Kaho Toshikazu X-Mailman-Approved-At: Tue, 03 Jul 2012 02:27:56 +0000 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jul 2012 01:12:35 -0000 Hello Matthias Apitz and -current member, "sys/dev/atkbdc/atkbdc_isa.c" may not have your keyboard controller's ID. Run `acpidump -dt` and search your keyboard description. Is your keyboard controller "PNP0303" ? -- kaho@ed.niigata-u.ac.jp > El d$(D+c*$(B Sunday, July 01, 2012 a las 06:29:28AM +0700, Erich Dollansky escribi$(D+Q"k(B > > Hi, > > > and no older versions. I will install the USB booted system to harddisk > > and hope when booted from disk and not from USB the keyboard is working. > > > > I installed the system r235646 to disk and it shows the same problem: no > keyboard; > > if 7.4 still runs but not anything after 8.0, it is most likely what I have written. Some USB hardware is not supported anymore in 8 and later. > > I would install the old one just to see You will also know wat hwardware is used there and how it is supported. > > This might be the faster route before starting debugging something which is not there. > > I said already that it works with a r214444 version, CURRENT from > October 2010; so I booted this again and concerning keyboard, here is > the diff: > > r214444: > > $ fgrep -i kb /tmp/dmesg-r214444.txt > kbd1 at kbdmux0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > > $ ls -l /dev/kb* > lrwxr-xr-x 1 root wheel 6 Jul 1 08:39 /dev/kbd0 -> atkbd0 > lrwxr-xr-x 1 root wheel 7 Jul 1 08:39 /dev/kbd1 -> kbdmux0 > crw------- 1 root wheel 0, 17 Jul 1 08:39 /dev/kbdmux0 > > r235646: > > $ fgrep -i kb /tmp/dmesg-r235646.txt > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > atkbdc0 failed to probe at port 0x60 on isa0 > > $ ls -l /dev/kb* > lrwxr-xr-x 1 root wheel 7 Jul 1 08:39 /dev/kbd1 -> kbdmux0 > crw------- 1 root wheel 0, 17 Jul 1 08:39 /dev/kbdmux0 > > the complete /tmp/dmesg-r214444.txt is attached, the > /tmp/dmesg-r235646.txt was in some message of this thread; > > So the question is: why the is not > detected anymore in r235646, while it is in r214444? > > Thanks > > matthias From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 05:45:59 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F72F106566B; Tue, 3 Jul 2012 05:45:59 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2435C8FC0C; Tue, 3 Jul 2012 05:45:59 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id q635jwhQ069739; Mon, 2 Jul 2012 22:45:58 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.5/Submit) id q635jw5M069738; Mon, 2 Jul 2012 22:45:58 -0700 (PDT) (envelope-from obrien) Date: Mon, 2 Jul 2012 22:45:58 -0700 From: "David O'Brien" To: "Simon L. B. Nielsen" Message-ID: <20120703054558.GC69108@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "Simon L. B. Nielsen" , current@FreeBSD.org References: <2A1FD996-9AB7-4F8D-B22D-0B3F0437C0F2@FreeBSD.org> <20120702213955.GA96547@dragon.NUXI.org> <25EA13B6-10A2-404C-8DDA-8C1DD39B13DB@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25EA13B6-10A2-404C-8DDA-8C1DD39B13DB@FreeBSD.org> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@FreeBSD.org Subject: Re: SVN2CVS exporter down X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 05:45:59 -0000 On Mon, Jul 02, 2012 at 10:55:57PM +0100, Simon L. B. Nielsen wrote: > Tested patches are accepted (http://svnweb.freebsd.org/base/svnadmin/tools/export.py), or even better - work on killing off CVS sooner rather than later. I like the latter. :-) As we discussed at BSDcan -- I don't use CVS at all for src or docs. I use a svnsync'ed mirror at home and $WORK. :-) It works great. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 06:02:12 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A62E21065673 for ; Tue, 3 Jul 2012 06:02:12 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 487E38FC1D for ; Tue, 3 Jul 2012 06:02:12 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1Slvti-0003VW-75>; Tue, 03 Jul 2012 07:43:38 +0200 Received: from e178021161.adsl.alicedsl.de ([85.178.21.161] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1Slvti-0005jc-00>; Tue, 03 Jul 2012 07:43:38 +0200 Message-ID: <4FF28682.9020705@zedat.fu-berlin.de> Date: Tue, 03 Jul 2012 07:43:30 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Current FreeBSD X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig67EFFF3A43C1CDAF92F85079" X-Originating-IP: 85.178.21.161 Cc: Subject: 10.0-CURRENT: kernel: Fatal trap 12: page fault while in kernel 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, 03 Jul 2012 06:02:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig67EFFF3A43C1CDAF92F85079 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The most recent build of FreeBSD 10.0-CURRENT crashes on one of our boxes with recent Intel hardware, see dmesg extract below. FreeBSD does obviously only crash on hardware with modern "Sandy-Bridge" hardware, the very same kernel config and a very similar setup does work very well on an older Intel Core2Dua architecture. Machine in question runs an older kernel (set via nextboot -k kernel.old) very well: FreeBSD 10.0-CURRENT #0 r237697: Thu Jun 28 11:45:08 CEST 2012 Most recent buildworls/kernels crash after going into multiuser mode (/etc/rc-scripts getting executed). Below the kernel trap message. I do this report on the fly, so if there is need for deeper investigations let me know, I will provide necessary detail requested. Regards, Oliver Jul 2 13:34:26 sb211 kernel: Fatal trap 12: page fault while in kernel m= ode Jul 2 13:34:26 sb211 kernel: cpuid =3D 3; apic id =3D 03 Jul 2 13:34:26 sb211 kernel: fault virtual address =3D 0x6c Jul 2 13:34:26 sb211 kernel: fault code =3D supervisor read= data, page not present Jul 2 13:34:26 sb211 kernel: instruction pointer =3D 0x20:0xffffffff807ed8e0 Jul 2 13:34:26 sb211 kernel: stack pointer =3D 0x28:0xffffff88c5d5e570 Jul 2 13:34:26 sb211 kernel: frame pointer =3D 0x28:0xffffff88c5d5e620 Jul 2 13:34:26 sb211 kernel: code segment =3D base 0x0, limit= 0xfffff, type 0x1b Jul 2 13:34:26 sb211 kernel: =3D DPL 0, pres 1, long 1, def32 0, gran 1 Jul 2 13:34:26 sb211 kernel: processor eflags =3D interrupt enabled, resume, IOPL =3D 0 Jul 2 13:41:47 sb211 syslogd: kernel boot file is /boot/kernel/kernel Jul 2 13:41:47 sb211 kernel: Copyright (c) 1992-2012 The FreeBSD Project= =2E Jul 2 13:41:47 sb211 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 2 13:41:47 sb211 kernel: The Regents of the University of California. All rights reserved. Jul 2 13:41:47 sb211 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jul 2 13:41:47 sb211 kernel: FreeBSD 10.0-CURRENT #0 r237995: Mon Jul 2 14:49:08 CEST 2012 Jul 2 13:41:47 sb211 kernel: root@sb211.geoinf.fu-berlin.de:/usr/obj/usr/src/sys/sb211 amd64 Jul 2 13:41:47 sb211 kernel: module_register: module enc already exists!= Jul 2 13:41:47 sb211 kernel: Module enc failed to register: 17 Jul 2 13:41:47 sb211 kernel: CPU: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz (3209.59-MHz K8-class CPU) Jul 2 13:41:47 sb211 kernel: Origin =3D "GenuineIntel" Id =3D 0x206d7 Family =3D 6 Model =3D 2d Stepping =3D 7 Jul 2 13:41:47 sb211 kernel: Features=3D0xbfebfbff Jul 2 13:41:47 sb211 kernel: Features2=3D0x1fbee3bf Jul 2 13:41:47 sb211 kernel: AMD Features=3D0x2c100800 Jul 2 13:41:47 sb211 kernel: AMD Features2=3D0x1 Jul 2 13:41:47 sb211 kernel: TSC: P-state invariant, performance statist= ics Jul 2 13:41:47 sb211 kernel: real memory =3D 34359738368 (32768 MB) Jul 2 13:41:47 sb211 kernel: avail memory =3D 33072930816 (31540 MB) Jul 2 13:41:47 sb211 kernel: Event timer "LAPIC" quality 600 Jul 2 13:41:47 sb211 kernel: ACPI APIC Table: Jul 2 13:41:47 sb211 kernel: FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs Jul 2 13:41:47 sb211 kernel: FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 SMT threads --------------enig67EFFF3A43C1CDAF92F85079 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJP8oaJAAoJEOgBcD7A/5N8JzUIAM7MFqdzwUf2c2kOTDDKC2zs U6I8V6RzfjcPPfz+Phy4tvFQ3ZD9Cozictc3mC1wX2o+5dIjK/12dq6RIj6o8YBi WpzWE6DroxIEt9tT5Oz7FZ/D9iTbGyF0G6Bg9B94u336tKerCm8mrvi7NsxxRjNC NOvJb73ADRzwKEuTVYmSh+67DHGxbuE3IRrVQ8g5RpQv1NyLZTsDD+E9UGhdXVh3 hNtTblw46cBM0h80N5WwBNJhn1oRofsttv/oZAh4m/nGX5rNLAJEACaIXt9erLER Sc3meXlJg0d+D2JRGUENwyq6ypaCBhX1NdQGAYZ58kMplSBE4yhOwp9Q7oXSPjE= =K63i -----END PGP SIGNATURE----- --------------enig67EFFF3A43C1CDAF92F85079-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 08:59:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 910281065670; Tue, 3 Jul 2012 08:59:06 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 49D678FC15; Tue, 3 Jul 2012 08:59:06 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Slywr-0007g7-Cn>; Tue, 03 Jul 2012 10:59:05 +0200 Received: from munin.geoinf.fu-berlin.de ([130.133.86.110]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Slywr-0001fI-AD>; Tue, 03 Jul 2012 10:59:05 +0200 Message-ID: <4FF2B457.9030505@zedat.fu-berlin.de> Date: Tue, 03 Jul 2012 10:59:03 +0200 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sayetsky Anton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.110 Cc: FreeBSD Current , bug-followup@freebsd.org Subject: Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jul 2012 08:59:06 -0000 On 07/02/12 08:09, Sayetsky Anton wrote: > I will test libreoffice build on 8.3-RELEASE today or tomorrow. > I have both gstreamer and boost installed now. > We use FreeBSD 9.0STABLE and FreeBSD 10.0-CURRENT (both amd64). devel/boost-lib gets reeled in now by editors/libreoffice by default, so it doesn't need to be installed explicitely. I saw a patch flushed in yesterday, submitted by bapt@. This patch also installs LLVM/CLANG from the ports - with ASSERTS deactivated. I have on both systems, FreeBSD 9 and 10, LLVM/CLANG 3.1 as the standard backend compiler, I guess this version has the suspected ASSERTS activated. Why another LLVM port? We already have LLVM/CLANG in the base system (9 and 19). If the ASSERTS proble is the cause for breaks reported on the list and elsewhere on the net, why isn't the maintainer still stuck on the "old" version? I just managed it to install the prior version on broken systems and was really lucky having LibreOffice working again. But the other day I was bothered by the next non-working version and now I have lots of notebooks remaining with NO LibreOffice on FBSD 9-STABLE. This is not what I expect from quality securing! It is simply a mess and definitely another reason and point for the thread "Why NOT using FreeBSD". From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 10:30:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12E0D1065673 for ; Tue, 3 Jul 2012 10:30:30 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 915C58FC1C for ; Tue, 3 Jul 2012 10:30:29 +0000 (UTC) Received: by bkcje9 with SMTP id je9so1011355bkc.13 for ; Tue, 03 Jul 2012 03:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NNXrzgg3xNiOjnTzcF+KwHT05sRfDGxMcrdvMwKz5vc=; b=ciF9OwoQc/eO0MdpgKOlS23dbd3vZOYPNHK1fUQDhFcI5/SxIgHrqeS5BdnLOGEUBy sfrJn3tfIIGLvJINKiVoCKKOVCH9MCz6CI9j5f+zNbbbTGUlejVKptttpu7Bsn7fl75e HFfm4r2oKXwSwYUREyuXx+yiWmXk/CvEbDjyc6IexjanN1qjhRHr/uu3QcjfOzn0eVTS RoGV9buHzywv45xiPa6DD4ekYJSsc5Ner8OYbj5OhtkwQdgIM4oOOkiDAzHVihlM2Spk edXik/AtUUaae5RZSAV1Km6REbj7XC6tOgpw76iWwa83ANXbNoLxdyDxBsJHoM4zhF+V DN6w== MIME-Version: 1.0 Received: by 10.204.152.4 with SMTP id e4mr3534663bkw.2.1341311428245; Tue, 03 Jul 2012 03:30:28 -0700 (PDT) Received: by 10.204.49.87 with HTTP; Tue, 3 Jul 2012 03:30:28 -0700 (PDT) Received: by 10.204.49.87 with HTTP; Tue, 3 Jul 2012 03:30:28 -0700 (PDT) In-Reply-To: <4FF2B457.9030505@zedat.fu-berlin.de> References: <4FF2B457.9030505@zedat.fu-berlin.de> Date: Tue, 3 Jul 2012 11:30:28 +0100 Message-ID: From: Chris Rees To: "Hartmann, O." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Sayetsky Anton , FreeBSD Current Subject: Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jul 2012 10:30:30 -0000 On Jul 3, 2012 10:00 AM, "Hartmann, O." wrote: > > On 07/02/12 08:09, Sayetsky Anton wrote: > > I will test libreoffice build on 8.3-RELEASE today or tomorrow. > > I have both gstreamer and boost installed now. > > > > > We use FreeBSD 9.0STABLE and FreeBSD 10.0-CURRENT (both amd64). > > devel/boost-lib gets reeled in now by editors/libreoffice by default, so > it doesn't need to be installed explicitely. > > I saw a patch flushed in yesterday, submitted by bapt@. This patch also > installs LLVM/CLANG from the ports - with ASSERTS deactivated. > > I have on both systems, FreeBSD 9 and 10, LLVM/CLANG 3.1 as the standard > backend compiler, I guess this version has the suspected ASSERTS activated. > > Why another LLVM port? We already have LLVM/CLANG in the base system (9 > and 19). If the ASSERTS proble is the cause for breaks reported on the > list and elsewhere on the net, why isn't the maintainer still stuck on > the "old" version? > > I just managed it to install the prior version on broken systems and was > really lucky having LibreOffice working again. But the other day I was > bothered by the next non-working version and now I have lots of > notebooks remaining with NO LibreOffice on FBSD 9-STABLE. > > This is not what I expect from quality securing! It is simply a mess and > definitely another reason and point for the thread "Why NOT using FreeBSD". For anyone struggling with the new version of libreoffice, I made a package for 9/amd64. http://www.bayofrum.net/tb/packages/9-local/All/libreoffice-3.5.4.tbz Setting up a Tinderbox is easy, and will fix the problems you are having. Please heed advice before shouting and blaming about problems. Chris From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 10:40:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23AF01065674 for ; Tue, 3 Jul 2012 10:40:17 +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 9F2C98FC15 for ; Tue, 3 Jul 2012 10:40:16 +0000 (UTC) Received: from [88.217.83.27] (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 1Sm0Wi-0007ga-90; Tue, 03 Jul 2012 12:40:12 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id q63AeAjH003287; Tue, 3 Jul 2012 12:40:10 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id q63Ae843003286; Tue, 3 Jul 2012 12:40:08 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 3 Jul 2012 12:40:07 +0200 From: Matthias Apitz To: Kaho Toshikazu Message-ID: <20120703104007.GA2780@tinyCurrent> References: <20120629133422.GA2233@tiny.Sisis.de> <201206301349.58930.erich@alogreentechnologies.com> <20120630151130.GA1106@tiny.Sisis.de> <201207010629.29148.erich@alogreentechnologies.com> <20120701065849.GA2681@tinyCurrent> <6039.1341276697@pf2.ed.niigata-u.ac.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6039.1341276697@pf2.ed.niigata-u.ac.jp> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.83.27 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 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: Tue, 03 Jul 2012 10:40:17 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit El día Tuesday, July 03, 2012 a las 09:51:37AM +0900, Kaho Toshikazu escribió: > Hello Matthias Apitz and -current member, > > "sys/dev/atkbdc/atkbdc_isa.c" may not have your keyboard controller's ID. > Run `acpidump -dt` and search your keyboard description. > Is your keyboard controller "PNP0303" ? > > -- > kaho@ed.niigata-u.ac.jp Hello Kaho Toshikazu and all, The command `acpidump -dt` in both releases (r214444 and r235646) gives an error: # acpidump -dt > /tmp/acpidump-r214444.txt acpidump: RSDT entry 2 (sig OEMB) is corrupt the output in r235646 is only some 70 lines and in r214444 I do not see any keyboard related; so I can't answer your question if the keyboard controller is "PNP0303"; Based on r235646 sources, I have checked the SVN-diff between r214444 (where the keyboard is working) and r235646, see attachment /tmp/atkbdc_isa.c-r214444:r235646; and the logic of the kb detection has changed; I will just give it a try and will revert this SVN change, i.e. 'svn up -r r214444 atkbdc_isa.c to see if this works... it does not help; Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="atkbdc_isa.c-r214444:r235646" Index: atkbdc_isa.c =================================================================== --- atkbdc_isa.c (revision 214444) +++ atkbdc_isa.c (revision 235646) @@ -49,6 +49,11 @@ static int atkbdc_isa_attach(device_t dev); static device_t atkbdc_isa_add_child(device_t bus, u_int order, const char *name, int unit); +static struct resource *atkbdc_isa_alloc_resource(device_t dev, device_t child, + int type, int *rid, u_long start, u_long end, + u_long count, u_int flags); +static int atkbdc_isa_release_resource(device_t dev, device_t child, + int type, int rid, struct resource *r); static device_method_t atkbdc_isa_methods[] = { DEVMETHOD(device_probe, atkbdc_isa_probe), @@ -61,8 +66,8 @@ DEVMETHOD(bus_read_ivar, atkbdc_read_ivar), DEVMETHOD(bus_write_ivar, atkbdc_write_ivar), DEVMETHOD(bus_get_resource_list,atkbdc_get_resource_list), - DEVMETHOD(bus_alloc_resource, bus_generic_rl_alloc_resource), - DEVMETHOD(bus_release_resource, bus_generic_rl_release_resource), + DEVMETHOD(bus_alloc_resource, atkbdc_isa_alloc_resource), + DEVMETHOD(bus_release_resource, atkbdc_isa_release_resource), DEVMETHOD(bus_activate_resource, bus_generic_activate_resource), DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource), DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource), @@ -82,6 +87,7 @@ static struct isa_pnp_id atkbdc_ids[] = { { 0x0303d041, "Keyboard controller (i8042)" }, /* PNP0303 */ + { 0x2003d041, "Keyboard controller (i8042)" }, /* PNP0320 */ { 0 } }; @@ -170,8 +176,6 @@ device_verbose(dev); error = atkbdc_probe_unit(device_get_unit(dev), port0, port1); - if (error == 0) - bus_generic_probe(dev); bus_release_resource(dev, SYS_RES_IOPORT, 0, port0); bus_release_resource(dev, SYS_RES_IOPORT, 1, port1); @@ -216,14 +220,25 @@ return ENXIO; } + /* + * If the device is not created by the PnP BIOS or ACPI, then + * the hint for the IRQ is on the child atkbd device, not the + * keyboard controller, so this can fail. + */ + rid = 0; + sc->irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, RF_ACTIVE); + error = atkbdc_attach_unit(unit, sc, sc->port0, sc->port1); if (error) { bus_release_resource(dev, SYS_RES_IOPORT, 0, sc->port0); bus_release_resource(dev, SYS_RES_IOPORT, 1, sc->port1); + if (sc->irq != NULL) + bus_release_resource(dev, SYS_RES_IRQ, 0, sc->irq); return error; } *(atkbdc_softc_t **)device_get_softc(dev) = sc; + bus_generic_probe(dev); bus_generic_attach(dev); return 0; @@ -233,9 +248,11 @@ atkbdc_isa_add_child(device_t bus, u_int order, const char *name, int unit) { atkbdc_device_t *ivar; + atkbdc_softc_t *sc; device_t child; int t; + sc = *(atkbdc_softc_t **)device_get_softc(bus); ivar = malloc(sizeof(struct atkbdc_device), M_ATKBDDEV, M_NOWAIT | M_ZERO); if (!ivar) @@ -251,18 +268,21 @@ ivar->rid = order; /* - * If the device is not created by the PnP BIOS or ACPI, - * refer to device hints for IRQ. + * If the device is not created by the PnP BIOS or ACPI, refer + * to device hints for IRQ. We always populate the resource + * list entry so we can use a standard bus_get_resource() + * method. */ - if (ISA_PNP_PROBE(device_get_parent(bus), bus, atkbdc_ids) != 0) { - if (resource_int_value(name, unit, "irq", &t) != 0) - t = -1; - } else { - t = bus_get_resource_start(bus, SYS_RES_IRQ, ivar->rid); + if (order == KBDC_RID_KBD) { + if (sc->irq == NULL) { + if (resource_int_value(name, unit, "irq", &t) != 0) + t = -1; + } else + t = rman_get_start(sc->irq); + if (t > 0) + resource_list_add(&ivar->resources, SYS_RES_IRQ, + ivar->rid, t, t, 1); } - if (t > 0) - resource_list_add(&ivar->resources, SYS_RES_IRQ, ivar->rid, - t, t, 1); if (resource_disabled(name, unit)) device_disable(child); @@ -272,5 +292,30 @@ return child; } +struct resource * +atkbdc_isa_alloc_resource(device_t dev, device_t child, int type, int *rid, + u_long start, u_long end, u_long count, u_int flags) +{ + atkbdc_softc_t *sc; + + sc = *(atkbdc_softc_t **)device_get_softc(dev); + if (type == SYS_RES_IRQ && *rid == KBDC_RID_KBD && sc->irq != NULL) + return (sc->irq); + return (bus_generic_rl_alloc_resource(dev, child, type, rid, start, + end, count, flags)); +} + +static int +atkbdc_isa_release_resource(device_t dev, device_t child, int type, int rid, + struct resource *r) +{ + atkbdc_softc_t *sc; + + sc = *(atkbdc_softc_t **)device_get_softc(dev); + if (type == SYS_RES_IRQ && rid == KBDC_RID_KBD && r == sc->irq) + return (0); + return (bus_generic_rl_release_resource(dev, child, type, rid, r)); +} + DRIVER_MODULE(atkbdc, isa, atkbdc_isa_driver, atkbdc_devclass, 0, 0); DRIVER_MODULE(atkbdc, acpi, atkbdc_isa_driver, atkbdc_devclass, 0, 0); --9amGYk9869ThD9tj-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 11:28:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B07EA106564A for ; Tue, 3 Jul 2012 11:28:46 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB8D8FC15 for ; Tue, 3 Jul 2012 11:28:46 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Sm1Hh-0004Wp-Gp>; Tue, 03 Jul 2012 13:28:45 +0200 Received: from munin.geoinf.fu-berlin.de ([130.133.86.110]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Sm1Hh-00053M-E8>; Tue, 03 Jul 2012 13:28:45 +0200 Message-ID: <4FF2D76C.9010907@zedat.fu-berlin.de> Date: Tue, 03 Jul 2012 13:28:44 +0200 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Chris Rees References: <4FF2B457.9030505@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.110 Cc: Sayetsky Anton , FreeBSD Current Subject: Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jul 2012 11:28:46 -0000 On 07/03/12 12:30, Chris Rees wrote: > On Jul 3, 2012 10:00 AM, "Hartmann, O." wrote: >> >> On 07/02/12 08:09, Sayetsky Anton wrote: >>> I will test libreoffice build on 8.3-RELEASE today or tomorrow. >>> I have both gstreamer and boost installed now. >>> >> >> >> We use FreeBSD 9.0STABLE and FreeBSD 10.0-CURRENT (both amd64). >> >> devel/boost-lib gets reeled in now by editors/libreoffice by default, so >> it doesn't need to be installed explicitely. >> >> I saw a patch flushed in yesterday, submitted by bapt@. This patch also >> installs LLVM/CLANG from the ports - with ASSERTS deactivated. >> >> I have on both systems, FreeBSD 9 and 10, LLVM/CLANG 3.1 as the standard >> backend compiler, I guess this version has the suspected ASSERTS > activated. >> >> Why another LLVM port? We already have LLVM/CLANG in the base system (9 >> and 19). If the ASSERTS proble is the cause for breaks reported on the >> list and elsewhere on the net, why isn't the maintainer still stuck on >> the "old" version? >> >> I just managed it to install the prior version on broken systems and was >> really lucky having LibreOffice working again. But the other day I was >> bothered by the next non-working version and now I have lots of >> notebooks remaining with NO LibreOffice on FBSD 9-STABLE. >> >> This is not what I expect from quality securing! It is simply a mess and >> definitely another reason and point for the thread "Why NOT using > FreeBSD". > > For anyone struggling with the new version of libreoffice, I made a package > for 9/amd64. > > http://www.bayofrum.net/tb/packages/9-local/All/libreoffice-3.5.4.tbz > > Setting up a Tinderbox is easy, and will fix the problems you are having. > > Please heed advice before shouting and blaming about problems. > > Chris > Thank you very much for the package, I'll try it and report back in. Oliver From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 17:14:14 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61864106564A for ; Tue, 3 Jul 2012 17:14:14 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 353AF8FC0C for ; Tue, 3 Jul 2012 17:14:14 +0000 (UTC) Received: from [209.249.190.124] (port=44373 helo=punk.neville-neil.com.neville-neil.com) by vps.hungerhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1Sm6fw-0000S2-Gq for current@freebsd.org; Tue, 03 Jul 2012 13:14:13 -0400 Date: Tue, 03 Jul 2012 13:15:34 -0400 Message-ID: <86hatodavd.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: current@freebsd.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/23.4 (amd64-portbld-freebsd10.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Subject: Java and NIO? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jul 2012 17:14:14 -0000 Howdy, Can someone tell me if anyone is working on this Java NIO bug? http://freebsd.1045724.n5.nabble.com/i386-159787-openjdk-1-6-nio-muti-thread-bug-td4700530.html I would like to avoid using Linux just to run Zookeeper: http://zookeeper-user.578899.n2.nabble.com/What-s-the-problem-with-nio-on-FreeBSD-td5208183.html Best, George From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 18:34:18 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B00BA106566C; Tue, 3 Jul 2012 18:34:18 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7AC208FC15; Tue, 3 Jul 2012 18:34:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q63IYIr2093485; Tue, 3 Jul 2012 18:34:18 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q63IYIDi093482; Tue, 3 Jul 2012 18:34:18 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Tue, 3 Jul 2012 18:34:15 +0000 From: Baptiste Daroussin To: "Hartmann, O." Message-ID: <20120703183415.GB3379@ithaqua.etoilebsd.net> References: <4FF2B457.9030505@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PmA2V3Z32TCmWXqI" Content-Disposition: inline In-Reply-To: <4FF2B457.9030505@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Sayetsky Anton , FreeBSD Current , bug-followup@FreeBSD.org Subject: Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jul 2012 18:34:18 -0000 --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 03, 2012 at 10:59:03AM +0200, Hartmann, O. wrote: > On 07/02/12 08:09, Sayetsky Anton wrote: > > I will test libreoffice build on 8.3-RELEASE today or tomorrow. > > I have both gstreamer and boost installed now. > >=20 >=20 >=20 > We use FreeBSD 9.0STABLE and FreeBSD 10.0-CURRENT (both amd64). >=20 > devel/boost-lib gets reeled in now by editors/libreoffice by default, so > it doesn't need to be installed explicitely. >=20 > I saw a patch flushed in yesterday, submitted by bapt@. This patch also > installs LLVM/CLANG from the ports - with ASSERTS deactivated. >=20 > I have on both systems, FreeBSD 9 and 10, LLVM/CLANG 3.1 as the standard > backend compiler, I guess this version has the suspected ASSERTS activate= d. >=20 > Why another LLVM port? We already have LLVM/CLANG in the base system (9 > and 19). If the ASSERTS proble is the cause for breaks reported on the > list and elsewhere on the net, why isn't the maintainer still stuck on > the "old" version? >=20 > I just managed it to install the prior version on broken systems and was > really lucky having LibreOffice working again. But the other day I was > bothered by the next non-working version and now I have lots of > notebooks remaining with NO LibreOffice on FBSD 9-STABLE. >=20 > This is not what I expect from quality securing! It is simply a mess and > definitely another reason and point for the thread "Why NOT using FreeBSD= ". >=20 > _______________________________________________ > 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" sure libreoffice is so easy to port... /me officially gives up with that libreoffice port, open for new volunteers= =20 bapt --PmA2V3Z32TCmWXqI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/zOycACgkQ8kTtMUmk6ExBHQCggmOiuR0A9uEM+/hDxMMPDTTk gkcAoIj5OHgv4FXnwAMhlXCMr4udV3pg =h0Wf -----END PGP SIGNATURE----- --PmA2V3Z32TCmWXqI-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 18:38:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A0A71065673 for ; Tue, 3 Jul 2012 18:38:29 +0000 (UTC) (envelope-from uzimac@da3m0n8t3r.com) Received: from z.umatar.com (z.umatar.com [66.135.39.87]) by mx1.freebsd.org (Postfix) with ESMTP id 6A81F8FC17 for ; Tue, 3 Jul 2012 18:38:29 +0000 (UTC) Received: from z.umatar.com (localhost [127.0.0.1]) by z.umatar.com (8.14.5/8.14.3) with ESMTP id q63IcNUb006645 for ; Tue, 3 Jul 2012 11:38:23 -0700 (PDT) (envelope-from uzimac@da3m0n8t3r.com) Received: (from uzimac@localhost) by z.umatar.com (8.14.5/8.14.3/Submit) id q63IcNpV006644 for current@freebsd.org; Tue, 3 Jul 2012 11:38:23 -0700 (PDT) (envelope-from uzimac@da3m0n8t3r.com) X-Authentication-Warning: z.umatar.com: uzimac set sender to uzimac@da3m0n8t3r.com using -f From: "Waitman Gobble" To: current@freebsd.org Message-Id: <1341340703.6639@da3m0n8t3r.com> X-Originating-IP: 70.90.171.37 X-Mailer: Usermin 1.500 In-Reply-To: <86hatodavd.wl%gnn@neville-neil.com> Date: Tue, 03 Jul 2012 11:38:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1341340703" Cc: Subject: Re: Java and NIO? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jul 2012 18:38:29 -0000 This is a multi-part message in MIME format. --bound1341340703 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit gnn@freebsd.org wrote .. > Howdy, > > Can someone tell me if anyone is working on this Java NIO bug? > > http://freebsd.1045724.n5.nabble.com/i386-159787-openjdk-1-6-nio-muti-thread-bug-td4700530.html > > I would like to avoid using Linux just to run Zookeeper: > > http://zookeeper-user.578899.n2.nabble.com/What-s-the-problem-with-nio-on-FreeBSD-td5208183.html > > Best, > George > _______________________________________________ > 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" Hi George, There is/was a patch from David Xu http://lists.freebsd.org/pipermail/freebsd-java/2010-August/008747.html maybe this fixes it? also looks like New I/O was updated in jdk7... but would have to check it out to see if issue still exists.. -- Waitman Gobble San Jose California USA --bound1341340703-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 09:22:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CCC11065670 for ; Wed, 4 Jul 2012 09:22:19 +0000 (UTC) (envelope-from shigeru@iij.ad.jp) Received: from omgo.iij.ad.jp (mo30.iij.ad.jp [202.232.30.71]) by mx1.freebsd.org (Postfix) with ESMTP id C1D6A8FC15 for ; Wed, 4 Jul 2012 09:22:18 +0000 (UTC) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:Mime-Version:Content-Type: Content-Transfer-Encoding;i=shigeru@iij.ad.jp;s=omgo1;t=1341393670;x= 1342603270; bh=e/8D7af9Wp/w9RqwqFIO1HYsLnxntLUYS3BzJgIY7rA=; b=XmzMeK8oXxpJhj3F bAL8/B/cPKf+PP6+8SAIxfkq50WuQEw+eqqircob1Nmagm1sAc3/TBEleUjQkE4hGnliN6njJ4vCa 5oIYnSGqmCaobJXgu/Pqbd5tm+O9cstYZj+9OLLxeqSj5r5RIJYsKeJw/g+RQfOn9ekReaibR2XUy g=; Received: by omgo.iij.ad.jp (mo30) id q649L9PT011169; Wed, 4 Jul 2012 18:21:10 +0900 Date: Wed, 04 Jul 2012 18:21:04 +0900 (JST) Message-Id: <20120704.182104.533981338265444182.shigeru@iij.ad.jp> To: freebsd-current@freebsd.org From: YAMAMOTO Shigeru X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [panic] currnet(r238089) cause panic when using '/usr/sbin/amd' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jul 2012 09:22:19 -0000 Hi all, I try to update newest current (r238089). I have kernel panic when using '/usr/sbin/amd'. This kernel panic is not caused without using '/usr/sbin/amd'. In old current (r236371), I have no problem with using '/usr/sbin/amd'. Currently, I don't know how to fix it. So I can only report this proble to ML. Thanks, How to repeat: 1) "svn checkout" r238089 source code 2) "make buildworld" and "make buildkernel" 3) "make installworld" and "make installkernel" 4) reboot 5) boot "GENERIC" kernel 6) run amd, "/etc/rc.d/amd onestart" My environment: - version is 10-current # uname -a FreeBSD venus.tokyo.iiji.jp 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r238089M: Wed Jul 4 10:30:01 JST 2012 root@venus.tokyo.iiji.jp:/usr/obj/usr/src/sys/GENERIC amd64 - build by r238039 source code - using GENERIC kernel - load kernel modules are # kldstat Id Refs Address Size Name 1 19 0xffffffff80200000 15d3ad0 kernel 2 1 0xffffffff817d4000 22b260 zfs.ko 3 2 0xffffffff81a00000 8570 opensolaris.ko 4 1 0xffffffff81c12000 38fc ums.ko 5 1 0xffffffff81c16000 1b7a1 ng_btsocket.ko 6 1 0xffffffff81c32000 ba58 netgraph.ko 7 1 0xffffffff81c3e000 118b ng_bluetooth.ko ------- YAMAMOTO Shigeru From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 11:02:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10081106564A for ; Wed, 4 Jul 2012 11:02:45 +0000 (UTC) (envelope-from kaho@elam.kais.kyoto-u.ac.jp) Received: from elam.kais.kyoto-u.ac.jp (elam.kais.kyoto-u.ac.jp [130.54.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9CAB08FC08 for ; Wed, 4 Jul 2012 11:02:44 +0000 (UTC) Received: from elam.kais.kyoto-u.ac.jp (localhost [127.0.0.1]) by elam.kais.kyoto-u.ac.jp (8.14.4/8.14.4) with ESMTP id q64AX8Bj081816; Wed, 4 Jul 2012 19:33:09 +0900 (JST) (envelope-from kaho@elam.kais.kyoto-u.ac.jp) To: Matthias Apitz From: Kaho Toshikazu References: <20120629133422.GA2233@tiny.Sisis.de> <201206301349.58930.erich@alogreentechnologies.com> <20120630151130.GA1106@tiny.Sisis.de> <201207010629.29148.erich@alogreentechnologies.com> <20120701065849.GA2681@tinyCurrent> <6039.1341276697@pf2.ed.niigata-u.ac.jp> <20120703104007.GA2780@tinyCurrent> X-Mailer: MH-E 8.0.3; MH 6.8.4.JP-3.05; GNU Emacs 22.3.1 User-Agent: EMH/1.14.1 SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?S?= =?ISO-8859-4?Q?hij=F2?=) APEL/10.7 Emacs/22.3 (i386-portbld-freebsd7.3) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Date: Wed, 04 Jul 2012 19:33:08 +0900 Message-ID: <81815.1341397988@elam.kais.kyoto-u.ac.jp> Sender: kaho@elam.kais.kyoto-u.ac.jp Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jul 2012 11:02:45 -0000 Hello, Can you put the file "acpidump-r214444.txt" on the Internet? When you run `grep "Device" /tmp/acpidump-r214444.txt` to get device list, can you find "PS2K" or "KBC" or similar word? Matthias Apitz wrote: > The command `acpidump -dt` in both releases (r214444 and r235646) gives > an error: > > # acpidump -dt > /tmp/acpidump-r214444.txt > acpidump: RSDT entry 2 (sig OEMB) is corrupt > > the output in r235646 is only some 70 lines and in r214444 I do not see > any keyboard related; so I can't answer your question if the > keyboard controller is "PNP0303"; > > Based on r235646 sources, I have checked the SVN-diff between r214444 > (where the keyboard is working) and r235646, see attachment > /tmp/atkbdc_isa.c-r214444:r235646; and the logic of the kb detection has > changed; I will just give it a try and will revert this SVN change, i.e. > 'svn up -r r214444 atkbdc_isa.c > to see if this works... it does not help; > > Thanks > > matthias > -- > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ > UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) > UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 10:08:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF1AA1065670 for ; Wed, 4 Jul 2012 10:08:19 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1ABBC8FC12 for ; Wed, 4 Jul 2012 10:08:19 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 29532153436 for ; Wed, 4 Jul 2012 12:08:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5IKTp_wUIZQ for ; Wed, 4 Jul 2012 12:08:16 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 27CAF153433 for ; Wed, 4 Jul 2012 12:08:16 +0200 (CEST) Message-ID: <4FF41610.10402@digiware.nl> Date: Wed, 04 Jul 2012 12:08:16 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 04 Jul 2012 11:09:40 +0000 Subject: sk0 link bouncing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jul 2012 10:08:19 -0000 Hi, I've got tons of these since I stopped loading the port with traffic.... It seems to have a pretty steady 27 min interval. Jul 4 07:00:05 freetest kernel: sk0: link state changed to DOWN Jul 4 07:00:05 freetest kernel: sk0: link state changed to UP Jul 4 07:27:21 freetest kernel: sk0: link state changed to DOWN Jul 4 07:27:21 freetest kernel: sk0: link state changed to UP Jul 4 07:53:48 freetest kernel: sk0: link state changed to DOWN Jul 4 07:53:48 freetest kernel: sk0: link state changed to UP Jul 4 08:21:16 freetest kernel: sk0: link state changed to DOWN Jul 4 08:21:16 freetest kernel: sk0: link state changed to UP Jul 4 08:48:10 freetest kernel: sk0: link state changed to DOWN Jul 4 08:48:11 freetest kernel: sk0: link state changed to UP Jul 4 09:13:38 freetest kernel: sk0: link state changed to DOWN Jul 4 09:13:38 freetest kernel: sk0: link state changed to UP Jul 4 09:39:06 freetest kernel: sk0: link state changed to DOWN Jul 4 09:39:06 freetest kernel: sk0: link state changed to UP Very recent 10-current install with std GENERIC kernel. FreeBSD freetest.digiware.nl 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Sat Jun 30 09:35:43 UTC 2012 root@freetest.digiware.nl:/usr/obj/usr/src/sys/GENERIC amd64 The port is connected to a basic netgear 10/100/1000 switch with nothing modified in the config of that port. Other connections do not seem to suffer from disconnecting. Used the server to 'zfs send' a 360G backup to, and then it did not do anything like this, the port just stayed up. Suggestions where of what to look for this? Thanx, --WjW dmesg: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #1: Sat Jun 30 09:35:43 UTC 2012 root@freetest.digiware.nl:/usr/obj/usr/src/sys/GENERIC amd64 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM)2 Duo CPU E7200 @ 2.53GHz (2533.48-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbff Features2=0x8e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 6442450944 (6144 MB) avail memory = 6167552000 (5881 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 uhci0: port 0xb800-0xb81f irq 16 at device 26.0 on pci0 uhci0: LegSup = 0x2f00 usbus0 on uhci0 uhci1: port 0xb880-0xb89f irq 21 at device 26.1 on pci0 uhci1: LegSup = 0x2f00 usbus1 on uhci1 uhci2: port 0xbc00-0xbc1f irq 18 at device 26.2 on pci0 uhci2: LegSup = 0x2f00 usbus2 on uhci2 ehci0: mem 0xfe8ffc00-0xfe8fffff irq 18 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 hdac0: mem 0xfe8f8000-0xfe8fbfff irq 22 at device 27.0 on pci0 pcib1: irq 17 at device 28.0 on pci0 pci3: on pcib1 pcib2: irq 17 at device 28.4 on pci0 pci2: on pcib2 atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfeaffc00-0xfeafffff irq 16 at device 0.0 on pci2 ahci0: at channel -1 on atapci0 ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ata2: at channel 0 on atapci0 pcib3: irq 16 at device 28.5 on pci0 pci1: on pcib3 mskc0: port 0xc800-0xc8ff mem 0xfe9fc000-0xfe9fffff irq 17 at device 0.0 on pci1 msk0: on mskc0 msk0: Ethernet address: 00:22:15:46:17:9a miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow uhci3: port 0xb080-0xb09f irq 23 at device 29.0 on pci0 uhci3: LegSup = 0x2f00 usbus4 on uhci3 uhci4: port 0xb400-0xb41f irq 19 at device 29.1 on pci0 uhci4: LegSup = 0x2f00 usbus5 on uhci4 uhci5: port 0xb480-0xb49f irq 18 at device 29.2 on pci0 uhci5: LegSup = 0x2f00 usbus6 on uhci5 ehci1: mem 0xfe8ff800-0xfe8ffbff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 vgapci0: port 0xe000-0xe0ff mem 0xf0000000-0xf7ffffff,0xfebf0000-0xfebfffff irq 17 at device 1.0 on pci4 skc0: port 0xe800-0xe8ff mem 0xfebec000-0xfebeffff irq 18 at device 2.0 on pci4 skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) sk0: on skc0 sk0: Ethernet address: 00:22:15:46:2d:33 miibus1: on sk0 e1000phy1: PHY 0 on miibus1 e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto isab0: at device 31.0 on pci0 isa0: on isab0 ahci1: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f mem 0xfe8fe800-0xfe8fefff irq 19 at device 31.2 on pci0 ahci1: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich2: at channel 0 on ahci1 ahcich3: at channel 1 on ahci1 ahcich4: at channel 2 on ahci1 ahcich5: at channel 3 on ahci1 ahcich6: at channel 4 on ahci1 ahcich7: at channel 5 on ahci1 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xc0000-0xcbfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range ctl: CAM Target Layer loaded acpi_perf0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a491e0600491e device_attach: est1 attach returned 6 p4tcc1: on cpu1 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 18,36,22,37 and 23,21,24,20 on hdaa0 pcm1: at nid 17 on hdaa0 pcm2: at nid 27 on hdaa0 pcm3: at nid 29 on hdaa0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ada0 at ahcich2 bus 0 scbus3 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad10 ada1 at ahcich3 bus 0 scbus4 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad12 ada2 at ahcich4 bus 0 scbus5 target 0 lun 0 ada2: ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad14 ada3 at ahcich5 bus 0 scbus6 target 0 lun 0 ada3: ATA-8 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad16 ada4 at ahcich6 bus 0 scbus7 target 0 lun 0 ada4: ATA-8 SATA 2.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: Command Queueing enabled ada4: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada4: Previously was known as ad18 ada5 at ahcich7 bus 0 scbus8 target 0 lun 0 ada5: ATA-8 SATA 2.x device ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 512bytes) ada5: Command Queueing enabled ada5: 30533MB (62533296 512 byte sectors: 16H 63S/T 16383C) ada5: Previously was known as ad20 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zfsroot []... sk0: link state changed to UP coretemp0: on cpu0 coretemp1: on cpu1 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a491e0600491e device_attach: est1 attach returned 6 pid 7641 (try), uid 0: exited on signal 10 (core dumped) sk0: link state changed to DOWN sk0: link state changed to UP sk0: link state changed to DOWN sk0: link state changed to UP From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 14:33:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DEBAC1065670 for ; Wed, 4 Jul 2012 14:33:19 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 85E2D8FC0A for ; Wed, 4 Jul 2012 14:33:19 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 7531983A0 for ; Wed, 4 Jul 2012 23:33:18 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id QxsuUorDNGPl for ; Wed, 4 Jul 2012 23:33:17 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA for ; Wed, 4 Jul 2012 23:33:17 +0900 (JST) Date: Wed, 4 Jul 2012 23:33:16 +0900 From: Taku YAMAMOTO To: freebsd-current@freebsd.org Message-Id: <20120704233316.70ec8654.taku@tackymt.homeip.net> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.24.6; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: FYI: SIGBUS with world built by 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: Wed, 04 Jul 2012 14:33:20 -0000 For people having SIGBUS with clang-build world + gcc-build binaries, In short words, for any libraries (and never forget about rtld-elf!) which are potentially called from arbitrary binaries, compile them with either -mstackrealign or -mstack-alignment=8! The detail is as follows. I've observed that clang carelessly expects the stack being aligned at 16 byte boundary. For example, the following code: #include #include int foo(const char *format,...) { int ret; va_list ap; FILE f = {}; va_start(ap, format); ret = vfprintf(&f, format, ap); va_end(ap); return ret; } which turns into: pushl %ebp movl %esp, %ebp subl $264, %esp # imm = 0x108 xorps %xmm0, %xmm0 movaps %xmm0, -40(%ebp) movaps %xmm0, -56(%ebp) (snip; lots of movaps insns follows) which results in SIGBUS if %esp - 4 is not at 16 byte boundary. (Note: movaps expects the address aligned to 16 bytes!) This problem becomes visible when such functions get called from binaries compiled with other compilers which don't care about stack alignment. If the above code is compiled by clang with -mstackrealign: pushl %ebp movl %esp, %ebp andl $-16, %esp subl $272, %esp # imm = 0x110 xorps %xmm0, %xmm0 movaps %xmm0, 224(%esp) movaps %xmm0, 208(%esp) (snip; lots of movaps insns follows) it tries to align the stack prior to allocating local variables thus no problem. If the above code is compiled by clang with -mstack-alignment=8: pushl %ebp movl %esp, %ebp pushl %esi subl $252, %esp leal -240(%ebp), %esi movl %esi, (%esp) movl $232, 8(%esp) movl $0, 4(%esp) calll memset (snip) it calls memset instead of a bunch of movaps to clear the storage thus no problem, of course. # I don't know why clang doesn't utilize rep stosl, though. Pros and cons: -mstackrealign Pros: no function calls to memset probably faster because of SSE Cons: use of SSE means the need of saving FP registers potentially more stack consumption -mstack-alignment=# Pros: normal and predictive stack consumption don't spill SSE registers; no extra overhead on context switching Cons: depends on memset -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 15:08:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C7AF106564A for ; Wed, 4 Jul 2012 15:08:31 +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 388618FC0C for ; Wed, 4 Jul 2012 15:08:31 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:d061:cfb8:84ae:5c85] (unknown [IPv6:2001:7b8:3a7:0:d061:cfb8:84ae:5c85]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 40BE35C59; Wed, 4 Jul 2012 17:08:30 +0200 (CEST) Message-ID: <4FF45C6E.1080000@FreeBSD.org> Date: Wed, 04 Jul 2012 17:08:30 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120619 Thunderbird/14.0 MIME-Version: 1.0 To: Taku YAMAMOTO References: <20120704233316.70ec8654.taku@tackymt.homeip.net> In-Reply-To: <20120704233316.70ec8654.taku@tackymt.homeip.net> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FYI: SIGBUS with world built by 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: Wed, 04 Jul 2012 15:08:31 -0000 On 2012-07-04 16:33, Taku YAMAMOTO wrote: > For people having SIGBUS with clang-build world + gcc-build binaries, > > > In short words, for any libraries (and never forget about rtld-elf!) > which are potentially called from arbitrary binaries, > compile them with either -mstackrealign or -mstack-alignment=8! > > The detail is as follows. > > I've observed that clang carelessly expects the stack being aligned at > 16 byte boundary. Eh, this is a requirement of the amd64 ABI. Any compiler that *doesn't* align the stack on 16-byte boundaries is basically broken. Or are you experiencing this on i386? Even there, 16-byte alignment would be much better in combination with SSE instructions (which arent' enabled by default, btw). Note that you would get the same issue with newer versions of gcc, which will also assume this alignment. From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 15:32:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C56821065672; Wed, 4 Jul 2012 15:32:00 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 8977C8FC08; Wed, 4 Jul 2012 15:32:00 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id E379483A0; Thu, 5 Jul 2012 00:31:59 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id ufMI_mYLGDLv; Thu, 5 Jul 2012 00:31:58 +0900 (JST) Received: from biotite.tackymt.homeip.net (biotite.tackymt.homeip.net [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA; Thu, 5 Jul 2012 00:31:58 +0900 (JST) Date: Thu, 5 Jul 2012 00:32:01 +0900 From: Taku YAMAMOTO To: Dimitry Andric Message-Id: <20120705003201.bb297e8a.taku@tackymt.homeip.net> In-Reply-To: <4FF45C6E.1080000@FreeBSD.org> References: <20120704233316.70ec8654.taku@tackymt.homeip.net> <4FF45C6E.1080000@FreeBSD.org> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FYI: SIGBUS with world built by 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: Wed, 04 Jul 2012 15:32:00 -0000 On Wed, 04 Jul 2012 17:08:30 +0200 Dimitry Andric wrote: > On 2012-07-04 16:33, Taku YAMAMOTO wrote: > > For people having SIGBUS with clang-build world + gcc-build binaries, > > > > > > In short words, for any libraries (and never forget about rtld-elf!) > > which are potentially called from arbitrary binaries, > > compile them with either -mstackrealign or -mstack-alignment=8! > > > > The detail is as follows. > > > > I've observed that clang carelessly expects the stack being aligned at > > 16 byte boundary. > > Eh, this is a requirement of the amd64 ABI. Any compiler that *doesn't* > align the stack on 16-byte boundaries is basically broken. Or are you > experiencing this on i386? Even there, 16-byte alignment would be much > better in combination with SSE instructions (which arent' enabled by > default, btw). Oops, I had to be clear about that! Yes, the experiment was took on i386 (actually -march=pentium4). > Note that you would get the same issue with newer versions of gcc, which > will also assume this alignment. Interesting, but the base gcc we currently have won't on i386, I think. (I occationally get bitten by similar problem when using -ftree-vectorize) -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 19:15:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5BF01065672; Wed, 4 Jul 2012 19:15:37 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0AC8FC14; Wed, 4 Jul 2012 19:15:36 +0000 (UTC) Received: by lbon10 with SMTP id n10so13561785lbo.13 for ; Wed, 04 Jul 2012 12:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=xc3N3/5bfTL3ukLflXlk1zMLE1kiGtwB09SZRagzS6s=; b=ktieQwlBKORf4uBtqaMCyXpLzr0jJFnJJ64Ev+77ztD1MB23JdeRbGgE91dQfNhdDa 7RmMHsFXocPaewrR5D8cbCqTYDb2Fbjau9ig2DtHBmbvoi2o1H/+54KSCogw33AqJVFT x4lMwoMiV4YrYqAwsRZgs8gqooL7wkZfCekSduNqQi2GFYd4M1HubHqqXTE92dW+esm3 A6unC3ktUPTVtcF6GIe490pG1Ea7LCLsH08wVJ9P6HQawhPhtnHvjT+bahumJLP32fM7 DjmAPdlFUQQveSqLHUKnoQQ3JuRNSncCMX3zWH+vidrPbLySEhsKrhpbogM8me1Jas2I ue6Q== MIME-Version: 1.0 Received: by 10.112.11.100 with SMTP id p4mr10649516lbb.35.1341429335301; Wed, 04 Jul 2012 12:15:35 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Wed, 4 Jul 2012 12:15:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Jul 2012 20:15:35 +0100 X-Google-Sender-Auth: 1mjJI24TgxwgjsoHfdJ21le5nI8 Message-ID: From: Attilio Rao To: FreeBSD FS , freebsd-current@freebsd.org, Peter Holm , =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= , Vivien Botton Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jul 2012 19:15:38 -0000 2012/6/29 Attilio Rao : > As already published several times, according to the following plan: > http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS > I still haven't heard from Vivien or Edward, anyway as NTFS is basically only used RO these days (also the mount_ntfs code just permits RO mounting) I stripped all the uncomplete/bogus write support with the following patch: http://www.freebsd.org/~attilio/ntfs_remove_write.patch This is an attempt to make the code smaller and possibly just focus on the locking that really matter (as read-only filesystem). On some points of the patch I'm a bit less sure as we could easily take into account also write for things like vaccess() arguments, and make easier to re-add correct write support at some point in the future, but still force RO, even if the approach used in the patch is more correct IMHO. As an added bonus this patch cleans some dirty code in the mount operation and fixes a bug as vfs_mountedfrom() is called before real mounting is completed and can still fail. The patch has been kindly tested by pho@. If none has objections I will commit it friday evening. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 19:49:33 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E3601065673; Wed, 4 Jul 2012 19:49:33 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (gerbercreations.com [71.39.140.16]) by mx1.freebsd.org (Postfix) with ESMTP id D6FDF8FC08; Wed, 4 Jul 2012 19:49:32 +0000 (UTC) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.14.5/8.14.5) with ESMTP id q64JnIbq015661; Wed, 4 Jul 2012 12:49:18 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.14.5/8.14.5/Submit) id q64JnHLL015660; Wed, 4 Jul 2012 12:49:17 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Wed, 4 Jul 2012 12:49:17 -0700 From: Greg Lewis To: Waitman Gobble , gnn@FreeBSD.org Message-ID: <20120704194917.GA15426@misty.eyesbeyond.com> References: <86hatodavd.wl%gnn@neville-neil.com> <1341340703.6639@da3m0n8t3r.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1341340703.6639@da3m0n8t3r.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org Subject: Re: Java and NIO? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jul 2012 19:49:33 -0000 On Tue, Jul 03, 2012 at 11:38:23AM -0700, Waitman Gobble wrote: > gnn@freebsd.org wrote .. > > Howdy, > > > > Can someone tell me if anyone is working on this Java NIO bug? > > > > http://freebsd.1045724.n5.nabble.com/i386-159787-openjdk-1-6-nio-muti-thread-bug-td4700530.html > > > > I would like to avoid using Linux just to run Zookeeper: > > > > http://zookeeper-user.578899.n2.nabble.com/What-s-the-problem-with-nio-on-FreeBSD-td5208183.html > > Hi George, > > There is/was a patch from David Xu > http://lists.freebsd.org/pipermail/freebsd-java/2010-August/008747.html > maybe this fixes it? This patch was incorporated into the openjdk6 port soon after it was posted. However, I can still reproduce the problem. Using -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KqueueSelectorProvider makes no difference. > also looks like New I/O was updated in jdk7... but would have to check it out to see if issue still exists.. I can't reproduce the problem with the current openjdk7 port. I haven't tried out Zookeeper though, so YMMV. I would say it's definitely worth a try though. I don't believe anyone is currently working on a fix for the openjdk6 port for this. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 21:14:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77659106566C; Wed, 4 Jul 2012 21:14:20 +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 E2DC78FC17; Wed, 4 Jul 2012 21:14:19 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q64LER3A045777; Thu, 5 Jul 2012 00:14:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q64LEFZ2016307; Thu, 5 Jul 2012 00:14:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q64LEEQ7016306; Thu, 5 Jul 2012 00:14:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Jul 2012 00:14:14 +0300 From: Konstantin Belousov To: Taku YAMAMOTO Message-ID: <20120704211414.GR2337@deviant.kiev.zoral.com.ua> References: <20120704233316.70ec8654.taku@tackymt.homeip.net> <4FF45C6E.1080000@FreeBSD.org> <20120705003201.bb297e8a.taku@tackymt.homeip.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="udoRqEMdU50CdIRN" Content-Disposition: inline In-Reply-To: <20120705003201.bb297e8a.taku@tackymt.homeip.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Dimitry Andric Subject: Re: FYI: SIGBUS with world built by 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: Wed, 04 Jul 2012 21:14:20 -0000 --udoRqEMdU50CdIRN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 05, 2012 at 12:32:01AM +0900, Taku YAMAMOTO wrote: > On Wed, 04 Jul 2012 17:08:30 +0200 > Dimitry Andric wrote: >=20 > > On 2012-07-04 16:33, Taku YAMAMOTO wrote: > > > For people having SIGBUS with clang-build world + gcc-build binaries, > > >=20 > > >=20 > > > In short words, for any libraries (and never forget about rtld-elf!) > > > which are potentially called from arbitrary binaries, > > > compile them with either -mstackrealign or -mstack-alignment=3D8! > > >=20 > > > The detail is as follows. > > >=20 > > > I've observed that clang carelessly expects the stack being aligned at > > > 16 byte boundary. > >=20 > > Eh, this is a requirement of the amd64 ABI. Any compiler that *doesn't* > > align the stack on 16-byte boundaries is basically broken. Or are you > > experiencing this on i386? Even there, 16-byte alignment would be much > > better in combination with SSE instructions (which arent' enabled by > > default, btw). >=20 > Oops, I had to be clear about that! > Yes, the experiment was took on i386 (actually -march=3Dpentium4). >=20 > > Note that you would get the same issue with newer versions of gcc, which > > will also assume this alignment. >=20 > Interesting, but the base gcc we currently have won't on i386, I think. > (I occationally get bitten by similar problem when using -ftree-vectorize) As far as I understand the rules, $esp % 16 must be zero before call instruction is executed. i386 csu explicitely aligns the stack before calling into C land, everything else should be the C compiler own offence :). --udoRqEMdU50CdIRN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/0siUACgkQC3+MBN1Mb4g32QCff5GaW0Rvk4uuUiNlh++/kj6Y oD0An2u8FqC6zVpCdMHi/gwE069pgNGj =Q70s -----END PGP SIGNATURE----- --udoRqEMdU50CdIRN-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 21:26:31 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 9D54A106566B; Wed, 4 Jul 2012 21:26:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2B22C178CB0; Wed, 4 Jul 2012 21:22:48 +0000 (UTC) Message-ID: <4FF4B427.1010808@FreeBSD.org> Date: Wed, 04 Jul 2012 14:22:47 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: Baptiste Daroussin References: <4FF2B457.9030505@zedat.fu-berlin.de> <20120703183415.GB3379@ithaqua.etoilebsd.net> In-Reply-To: <20120703183415.GB3379@ithaqua.etoilebsd.net> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sayetsky Anton , FreeBSD Current , "Hartmann, O." , bug-followup@FreeBSD.org Subject: Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jul 2012 21:26:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/03/2012 11:34, Baptiste Daroussin wrote: > On Tue, Jul 03, 2012 at 10:59:03AM +0200, Hartmann, O. wrote: >> On 07/02/12 08:09, Sayetsky Anton wrote: >>> I will test libreoffice build on 8.3-RELEASE today or tomorrow. >>> I have both gstreamer and boost installed now. >>> >> >> >> We use FreeBSD 9.0STABLE and FreeBSD 10.0-CURRENT (both amd64). >> >> devel/boost-lib gets reeled in now by editors/libreoffice by default, so >> it doesn't need to be installed explicitely. >> >> I saw a patch flushed in yesterday, submitted by bapt@. This patch also >> installs LLVM/CLANG from the ports - with ASSERTS deactivated. >> >> I have on both systems, FreeBSD 9 and 10, LLVM/CLANG 3.1 as the standard >> backend compiler, I guess this version has the suspected ASSERTS activated. >> >> Why another LLVM port? We already have LLVM/CLANG in the base system (9 >> and 19). If the ASSERTS proble is the cause for breaks reported on the >> list and elsewhere on the net, why isn't the maintainer still stuck on >> the "old" version? >> >> I just managed it to install the prior version on broken systems and was >> really lucky having LibreOffice working again. But the other day I was >> bothered by the next non-working version and now I have lots of >> notebooks remaining with NO LibreOffice on FBSD 9-STABLE. >> >> This is not what I expect from quality securing! It is simply a mess and >> definitely another reason and point for the thread "Why NOT using FreeBSD". > > sure libreoffice is so easy to port... > > /me officially gives up with that libreoffice port, open for new volunteers If you don't have time to work on the port, then don't, that's not a problem. But throwing a hissy fit here doesn't help at all. It's a plain fact that a working office suite is a basic requirement for most desktop users. If _we_ can't provide that (note, not you, personally, we, as a project), it's a valid reason for users to avoid FreeBSD for desktop use. If we're ever going to make progress in this area we have to be willing to examine and absorb facts; and then act accordingly. Doug - -- This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP9LQnAAoJEFzGhvEaGryEYk4H/0TcxjVnax0xgrt4/3WMvwWU t/GNQ7Fws3EJSrZN2vB3LSnmwRv7UbkmotXLzirS+f/SmwREUH0677DV3EFlxuxx WvXvtYexu4XHWOeODZi5m8crbNUM94HLnwTfo2gecMah+eL6M46EoBAfCJT4NtUD 1AYIsZTpiEqEvLHJCNj+Mwt0YiH3XxAdRhhfSMolKBm7B6lqOsEA5cEnA2QTWBWI bDeUB8hZuW1q6O5U60xdTZMjDQNGroVg6nuCtTihXj7/DWKR41Wgzezh14qFKs7m Hki/eRGzQA3DTLKuf51PY+FO7epBeWC5YCNxe52ASqU+pKdUYpfS3vCw3BmbqPg= =4Mp6 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 21:41:23 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34B941065672 for ; Wed, 4 Jul 2012 21:41:23 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]) by mx1.freebsd.org (Postfix) with ESMTP id E32FA8FC0A for ; Wed, 4 Jul 2012 21:41:22 +0000 (UTC) Received: from [IPv6:2001:470:8:58f:21c:b3ff:feb5:bf32] ([IPv6:2001:470:8:58f:21c:b3ff:feb5:bf32]) (authenticated bits=0) by mouf.net (8.14.5/8.14.5) with ESMTP id q64LfKb3003859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 4 Jul 2012 17:41:21 -0400 (EDT) (envelope-from swills@FreeBSD.org) From: Steve Wills Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jul 2012 17:41:14 -0400 Message-Id: <7F5E65B1-24AF-4942-A273-093EBAE94B7D@FreeBSD.org> To: current@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]); Wed, 04 Jul 2012 17:41:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.97.5 at mouf.net X-Virus-Status: Clean Cc: Subject: panic after starting X with r238120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jul 2012 21:41:23 -0000 Hi, After updating to r238120, I get a panic whenever X starts up. It works = for a few seconds, then panics. The messages don't look too useful to = me, but here they are: Unread portion of the kernel message buffer: processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 3610 (kdm_greet) trap number =3D 12 panic: page fault cpuid =3D 0 (kgdb) bt #0 doadump (textdump=3Ddwarf2_read_address: Corrupted DWARF expression. ) at pcpu.h:224 #1 0xffffffff8087ef79 in kern_reboot (howto=3Ddwarf2_read_address: = Corrupted DWARF expression. ) at kern_shutdown.c:449 #2 0xffffffff8087f413 in panic (fmt=3Ddwarf2_read_address: Corrupted = DWARF expression. ) at kern_shutdown.c:637 #3 0xffffffff80b77d08 in trap_fatal (frame=3Ddwarf2_read_address: = Corrupted DWARF expression. ) at trap.c:852 #4 0xffffffff80b78012 in trap_pfault (frame=3Ddwarf2_read_address: = Corrupted DWARF expression. ) at trap.c:678 #5 0xffffffff80b777aa in trap (frame=3DVariable "frame" is not = available. ) at trap.c:456 #6 0xffffffff80b62142 in calltrap () at /tmp/exception-vH8hmc.s:179 #7 0xffffffff80b6f6b0 in pmap_enter (pmap=3Ddwarf2_read_address: = Corrupted DWARF expression. ) at pmap.c:3587 #8 0xffffffff80adafa0 in vm_fault_hold (map=3Ddwarf2_read_address: = Corrupted DWARF expression. ) at vm_fault.c:935 #9 0xffffffff80ad9787 in vm_fault (map=3DVariable "map" is not = available. ) at vm_fault.c:229 #10 0xffffffff80b77f26 in trap_pfault (frame=3Ddwarf2_read_address: = Corrupted DWARF expression. ) at trap.c:736 #11 0xffffffff80b77670 in trap (frame=3DVariable "frame" is not = available. ) at trap.c:358 #12 0xffffffff80b62142 in calltrap () at /tmp/exception-vH8hmc.s:179 #13 0x00000008040d7796 in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb)=20 Something I saw in a previous panic made me think this was drm related, = but I don't see it in this particular one. Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 21:57:47 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 505C4106566C for ; Wed, 4 Jul 2012 21:57:47 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2D28FC20 for ; Wed, 4 Jul 2012 21:57:46 +0000 (UTC) Received: from [IPv6:2001:470:8:58f:21c:b3ff:feb5:bf32] ([IPv6:2001:470:8:58f:21c:b3ff:feb5:bf32]) (authenticated bits=0) by mouf.net (8.14.5/8.14.5) with ESMTP id q64LvjVL004035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 4 Jul 2012 17:57:46 -0400 (EDT) (envelope-from swills@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Steve Wills In-Reply-To: <7F5E65B1-24AF-4942-A273-093EBAE94B7D@FreeBSD.org> Date: Wed, 4 Jul 2012 17:57:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <168031EF-1CBD-4B14-A99E-D5C90B01111C@FreeBSD.org> References: <7F5E65B1-24AF-4942-A273-093EBAE94B7D@FreeBSD.org> To: current@FreeBSD.org X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]); Wed, 04 Jul 2012 17:57:46 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.97.5 at mouf.net X-Virus-Status: Clean Cc: Subject: Re: panic after starting X with r238120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jul 2012 21:57:47 -0000 Setting kern.ipc.shm_use_phys back to 0 (the default) fixed it. I had = set it to 1 for some reason that I can't recall. Steve On Jul 4, 2012, at 5:41 PM, Steve Wills wrote: > Hi, >=20 > After updating to r238120, I get a panic whenever X starts up. It = works for a few seconds, then panics. The messages don't look too useful = to me, but here they are: >=20 > Unread portion of the kernel message buffer: > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 3610 (kdm_greet) > trap number =3D 12 > panic: page fault > cpuid =3D 0 >=20 > (kgdb) bt > #0 doadump (textdump=3Ddwarf2_read_address: Corrupted DWARF = expression. > ) at pcpu.h:224 > #1 0xffffffff8087ef79 in kern_reboot (howto=3Ddwarf2_read_address: = Corrupted DWARF expression. > ) at kern_shutdown.c:449 > #2 0xffffffff8087f413 in panic (fmt=3Ddwarf2_read_address: Corrupted = DWARF expression. > ) at kern_shutdown.c:637 > #3 0xffffffff80b77d08 in trap_fatal (frame=3Ddwarf2_read_address: = Corrupted DWARF expression. > ) at trap.c:852 > #4 0xffffffff80b78012 in trap_pfault (frame=3Ddwarf2_read_address: = Corrupted DWARF expression. > ) at trap.c:678 > #5 0xffffffff80b777aa in trap (frame=3DVariable "frame" is not = available. > ) at trap.c:456 > #6 0xffffffff80b62142 in calltrap () at /tmp/exception-vH8hmc.s:179 > #7 0xffffffff80b6f6b0 in pmap_enter (pmap=3Ddwarf2_read_address: = Corrupted DWARF expression. > ) at pmap.c:3587 > #8 0xffffffff80adafa0 in vm_fault_hold (map=3Ddwarf2_read_address: = Corrupted DWARF expression. > ) at vm_fault.c:935 > #9 0xffffffff80ad9787 in vm_fault (map=3DVariable "map" is not = available. > ) at vm_fault.c:229 > #10 0xffffffff80b77f26 in trap_pfault (frame=3Ddwarf2_read_address: = Corrupted DWARF expression. > ) at trap.c:736 > #11 0xffffffff80b77670 in trap (frame=3DVariable "frame" is not = available. > ) at trap.c:358 > #12 0xffffffff80b62142 in calltrap () at /tmp/exception-vH8hmc.s:179 > #13 0x00000008040d7796 in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb)=20 >=20 > Something I saw in a previous panic made me think this was drm = related, but I don't see it in this particular one. >=20 > Steve >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 22:02:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A31631065674 for ; Wed, 4 Jul 2012 22:02:23 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm28-vm1.bullet.mail.sp2.yahoo.com (nm28-vm1.bullet.mail.sp2.yahoo.com [98.139.91.235]) by mx1.freebsd.org (Postfix) with SMTP id 734EC8FC1D for ; Wed, 4 Jul 2012 22:02:23 +0000 (UTC) Received: from [98.139.91.64] by nm28.bullet.mail.sp2.yahoo.com with NNFMP; 04 Jul 2012 22:02:23 -0000 Received: from [72.30.22.202] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 04 Jul 2012 22:02:23 -0000 Received: from [127.0.0.1] by omp1064.mail.sp2.yahoo.com with NNFMP; 04 Jul 2012 22:02:23 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 425407.21598.bm@omp1064.mail.sp2.yahoo.com Received: (qmail 61744 invoked by uid 60001); 4 Jul 2012 22:02:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1341439343; bh=XxlaZ9hKX2+ulaUpmzdfrrtfzzKqpHp+RE77SNMfzAk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=w2jKBWqSO2DkmtVCILtz4ETJAn45nT/cbv6Iopk1b0RhTFL4Fm+laF3zCTFg4SmEFfyCYcutXJ1ENui8hDiS0Q/fFlHU5zIJBw5eBSlKGmGzndYM6z/vxnZtB0Fwph1Ba2D3DhGZZXqBemaTRqGrtfo63fVF2n7gh+HlYOAGdr8= X-YMail-OSG: S3XOaAkVM1loBiAijK8Q5ARQj8SdaYMNZR0d2OY4p3ws02I cwLL5_U16PAgBSP2SW2ezEblHq4G75CPNb3EDnLCOemWsnAI.lewgn6z8p2W BV2M353xZ9arkjzCjH4NJAHiaJ1gBFZ2ElqV0XzFbTmrendsY0HJxc.6kfyi 9htidrrBiZa0d7KO7llUS3UwcBRm.IG48QeX16Zq0OwXRkAY5Mr8MZpNZw9N a_VHzsy3XE2Is9ATtlGJb1t1C8usCl3XKhT3YiK72lRF7hn6h07pM5wGtXcC M4EpthpPDh90isen70AhTQv40S65FouFiMlaoj8Uq4qgfEdlBuYlghhjMysB A_7Lidq42EOXlqjzVd8PGTyQr7fAI94UMSEnad4L3l0iYYlboZQ1QHhcgVZG zcmLVjufJCKzK6rn5I.TgZekU7ri8RX8vTmgLc3cRRNAiL98I6_H9XpgDt1y sf55U Received: from [200.118.157.7] by web113503.mail.gq1.yahoo.com via HTTP; Wed, 04 Jul 2012 15:02:22 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.120.356233 Message-ID: <1341439342.60791.YahooMailClassic@web113503.mail.gq1.yahoo.com> Date: Wed, 4 Jul 2012 15:02:22 -0700 (PDT) From: Pedro Giffuni To: Baptiste Daroussin , Doug Barton In-Reply-To: <4FF4B427.1010808@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Sayetsky Anton , FreeBSD Current , " O.Hartmann" Subject: Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfg@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 22:02:23 -0000 Just IMHO;=0A=0A--- Mer 4/7/12, Doug Barton ha scritto:= =0A...=0A> >>=0A> >> This is not what I expect from quality securing! It=0A= > >> is simply a mess and definitely another reason=0A> >> and point for th= e thread "Why NOT using FreeBSD".=0A> >=0A> > sure libreoffice is so easy t= o port...=0A> > =0A> > /me officially gives up with that libreoffice port,= =0A> > open for new volunteers =0A> =0A> If you don't have time to work on = the port, then don't,=0A> that's not a problem. But throwing a hissy fit he= re=0A> doesn't help at all.=0A=0AEven on paid jobs, people always have the = right to quit.=0A=0AThe thing, as I see it, is that people have to understa= nd=0Athis is a volunteer project and if people don't do things=0Aby themsel= ves they really can't demand someone else to=0Ado it for them.=0A=0A=0A> It= 's a plain fact that a working office suite is a basic=0A> requirement for = most desktop users. If _we_ can't provide=0A> that (note, not you, personal= ly, we, as a=0A> project), it's a valid reason for users to avoid FreeBSD f= or=0A> desktop use.=0A> =0A=0AThe system is as strong as it's weakest link.= There=0Aare perfectly good office suites for FreeBSD and even=0Athen for s= ome of us that is not enough to use FreeBSD=0A(or linux) as a desktop.=0A= =0A> If we're ever going to make progress in this area we=0A> have to be wi= lling to examine and absorb facts; and=0A> then act accordingly.=0A>=0A=0AI= f people think a particular office suite is critical=0Athen *they* have to = spend time on it. If no one has=0Athe time or skills then maybe it's not th= at important=0Aat all.=0A=0A=0APedro. From owner-freebsd-current@FreeBSD.ORG Wed Jul 4 22:09:39 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 0B9FB106564A; Wed, 4 Jul 2012 22:09:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id DC6572005A2; Wed, 4 Jul 2012 22:06:48 +0000 (UTC) Message-ID: <4FF4BE78.5010006@FreeBSD.org> Date: Wed, 04 Jul 2012 15:06:48 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: pfg@freebsd.org References: <1341439342.60791.YahooMailClassic@web113503.mail.gq1.yahoo.com> In-Reply-To: <1341439342.60791.YahooMailClassic@web113503.mail.gq1.yahoo.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sayetsky Anton , Baptiste Daroussin , FreeBSD Current , "O.Hartmann" Subject: Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jul 2012 22:09:39 -0000 On 07/04/2012 15:02, Pedro Giffuni wrote: > The thing, as I see it, is that people have to understand > this is a volunteer project and if people don't do things > by themselves they really can't demand someone else to > do it for them. Of course. But that's totally different from, "I don't use FreeBSD because it doesn't offer $feature, which is important to me." Don't forget the original purpose of this thread. :) -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 03:49:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 297451065670 for ; Thu, 5 Jul 2012 03:49:43 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id D57D48FC0A for ; Thu, 5 Jul 2012 03:49:42 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.10]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q653nRZb002234 for ; Wed, 4 Jul 2012 21:49:29 -0600 From: Erich Dollansky To: freebsd-current@freebsd.org Date: Thu, 5 Jul 2012 10:49:26 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201207051049.26199.erichfreebsdlist@ovitrap.com> Subject: side note on the X220 running CURRENT: head phone jack works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 03:49:43 -0000 Hi, there have been some people here - including me - wondering whether the head phone jack works. Yes, it does. I just have had the chance to connect the head phone jack. It works when vlc is set to use /dev/dsp1.0. Using /dev/dsp0.1 brings sound to the built-in speakers. Erich From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 05:19:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A11991065672; Thu, 5 Jul 2012 05:19:50 +0000 (UTC) (envelope-from uzimac@da3m0n8t3r.com) Received: from z.umatar.com (z.umatar.com [66.135.39.87]) by mx1.freebsd.org (Postfix) with ESMTP id 667968FC14; Thu, 5 Jul 2012 05:19:50 +0000 (UTC) Received: from z.umatar.com (localhost [127.0.0.1]) by z.umatar.com (8.14.5/8.14.3) with ESMTP id q655Jiwd077268; Wed, 4 Jul 2012 22:19:44 -0700 (PDT) (envelope-from uzimac@da3m0n8t3r.com) Received: (from uzimac@localhost) by z.umatar.com (8.14.5/8.14.3/Submit) id q655Jhd5077267; Wed, 4 Jul 2012 22:19:43 -0700 (PDT) (envelope-from uzimac@da3m0n8t3r.com) X-Authentication-Warning: z.umatar.com: uzimac set sender to uzimac@da3m0n8t3r.com using -f From: "Waitman Gobble" To: Baptiste Daroussin Message-Id: <1341465583.77262@da3m0n8t3r.com> X-Originating-IP: 75.36.149.244 X-Mailer: Usermin 1.500 Date: Wed, 04 Jul 2012 22:19:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1341465583" Cc: Sayetsky Anton , FreeBSD Current , "Hartmann, O." , bug-followup@freebsd.org Subject: Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 05:19:50 -0000 This is a multi-part message in MIME format. --bound1341465583 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Baptiste Daroussin wrote .. > On Tue, Jul 03, 2012 at 10:59:03AM +0200, Hartmann, O. wrote: > > On 07/02/12 08:09, Sayetsky Anton wrote: > > > I will test libreoffice build on 8.3-RELEASE today or tomorrow. > > > I have both gstreamer and boost installed now. > > > > > > > > > We use FreeBSD 9.0STABLE and FreeBSD 10.0-CURRENT (both amd64). > > > > devel/boost-lib gets reeled in now by editors/libreoffice by default, so > > it doesn't need to be installed explicitely. > > > > I saw a patch flushed in yesterday, submitted by bapt@. This patch also > > installs LLVM/CLANG from the ports - with ASSERTS deactivated. > > > > I have on both systems, FreeBSD 9 and 10, LLVM/CLANG 3.1 as the standard > > backend compiler, I guess this version has the suspected ASSERTS activated. > > > > Why another LLVM port? We already have LLVM/CLANG in the base system (9 > > and 19). If the ASSERTS proble is the cause for breaks reported on the > > list and elsewhere on the net, why isn't the maintainer still stuck on > > the "old" version? > > > > I just managed it to install the prior version on broken systems and was > > really lucky having LibreOffice working again. But the other day I was > > bothered by the next non-working version and now I have lots of > > notebooks remaining with NO LibreOffice on FBSD 9-STABLE. > > > > This is not what I expect from quality securing! It is simply a mess and > > definitely another reason and point for the thread "Why NOT using FreeBSD". > > > > _______________________________________________ > > 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" > > sure libreoffice is so easy to port... > > /me officially gives up with that libreoffice port, open for new volunteers > > bapt LibreOffice is pretty massive. I've spent much of the day working on building 3.6.0.0 on 10-CURRENT with gcc48 and openjdk6. I have been using AbiWord but the word-wrap is crazy. Try writing a novel with weird word breaks and moving paragraphs and it's driving me koo-koo pants. Also it does not appear to do right-left opposing margins. I was interested in building AbiWord dev on my machine but the dev team seems very MS-centric, much of a chore using their HEAD. Gnumeric works great, I have successfully interoperated, no urgent issues. on to LibreOffice... I can create and submit a port for libreoffice 3.6.0.0 if anyone is interested in trying the "beta" version. Might take a few days. Still working on it. At the moment, there is one small change to configure.in. It stubbornly demands libclucene-core instead of libclucene. Most of the libraries are built from ports, then using --with-system-foo in autogen.sh -- Waitman Gobble San Jose California USA -- Waitman Gobble San Jose California USA --bound1341465583-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 05:28:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 931A9106564A for ; Thu, 5 Jul 2012 05:28:47 +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 1ED4A8FC12 for ; Thu, 5 Jul 2012 05:28:47 +0000 (UTC) Received: from [46.244.129.177] (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 1SmecI-0001f7-2K; Thu, 05 Jul 2012 07:28:38 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id q655Sac5002434; Thu, 5 Jul 2012 07:28:36 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id q655SYf9002433; Thu, 5 Jul 2012 07:28:34 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Thu, 5 Jul 2012 07:28:33 +0200 From: Matthias Apitz To: Kaho Toshikazu Message-ID: <20120705052833.GA2386@tinyCurrent> References: <20120629133422.GA2233@tiny.Sisis.de> <201206301349.58930.erich@alogreentechnologies.com> <20120630151130.GA1106@tiny.Sisis.de> <201207010629.29148.erich@alogreentechnologies.com> <20120701065849.GA2681@tinyCurrent> <6039.1341276697@pf2.ed.niigata-u.ac.jp> <20120703104007.GA2780@tinyCurrent> <81815.1341397988@elam.kais.kyoto-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <81815.1341397988@elam.kais.kyoto-u.ac.jp> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 46.244.129.177 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 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: Thu, 05 Jul 2012 05:28:47 -0000 El día Wednesday, July 04, 2012 a las 07:33:08PM +0900, Kaho Toshikazu escribió: > Hello, > > Can you put the file "acpidump-r214444.txt" on the Internet? > When you run `grep "Device" /tmp/acpidump-r214444.txt` > to get device list, can you find "PS2K" or "KBC" or similar word? Hello, For some unknown reason today it gives more lines: # acpidump -dt | wc -l acpidump: RSDT entry 2 (sig OEMB) is corrupt 3815 when I did this the other day it was only around 2000 lines; and there is now an entry for "PS2K" (not for "KBC"): Device (PS2K) { Name (_HID, EisaId ("PNP030B")) Name (_CID, EisaId ("PNP030B")) Method (_STA, 0, NotSerialized) { ShiftLeft (0x01, 0x0A, Local0) If (And (IOST, Local0)) { Return (0x0F.... the full file is here: http://www.unixarea.de/acpidump-r214444.txt Thanks for your help matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 05:57:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EFB71065672 for ; Thu, 5 Jul 2012 05:57:36 +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 D27B28FC14 for ; Thu, 5 Jul 2012 05:57:35 +0000 (UTC) Received: from [46.244.129.177] (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 1Smf4G-0003E9-WC; Thu, 05 Jul 2012 07:57:33 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id q655vVXI002542; Thu, 5 Jul 2012 07:57:31 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id q655vUhr002541; Thu, 5 Jul 2012 07:57:30 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Thu, 5 Jul 2012 07:57:30 +0200 From: Matthias Apitz To: Kaho Toshikazu , freebsd-current@freebsd.org, Hans Petter Selasky Message-ID: <20120705055730.GA2516@tinyCurrent> References: <20120629133422.GA2233@tiny.Sisis.de> <201206301349.58930.erich@alogreentechnologies.com> <20120630151130.GA1106@tiny.Sisis.de> <201207010629.29148.erich@alogreentechnologies.com> <20120701065849.GA2681@tinyCurrent> <6039.1341276697@pf2.ed.niigata-u.ac.jp> <20120703104007.GA2780@tinyCurrent> <81815.1341397988@elam.kais.kyoto-u.ac.jp> <20120705052833.GA2386@tinyCurrent> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120705052833.GA2386@tinyCurrent> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 46.244.129.177 Cc: Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 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: Thu, 05 Jul 2012 05:57:36 -0000 El día Thursday, July 05, 2012 a las 07:28:33AM +0200, Matthias Apitz escribió: > and there is now an entry for "PS2K" (not for "KBC"): > > Device (PS2K) > { > Name (_HID, EisaId ("PNP030B")) > Name (_CID, EisaId ("PNP030B")) > Method (_STA, 0, NotSerialized) > { > ShiftLeft (0x01, 0x0A, Local0) > If (And (IOST, Local0)) > { > Return (0x0F.... > > the full file is here: http://www.unixarea.de/acpidump-r214444.txt maybe it helps to add a line like this: static struct isa_pnp_id atkbdc_ids[] = { { 0x0303d041, "Keyboard controller (i8042)" }, /* PNP0303 */ { 0x2003d041, "Keyboard controller (i8042)" }, /* PNP0320 */ + { 0x0b03d041, "Keyboard controller (i8042)" }, /* PNP030B */ { 0 } -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 07:00:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB5DD106564A; Thu, 5 Jul 2012 07:00:43 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9BA8FC0C; Thu, 5 Jul 2012 07:00:43 +0000 (UTC) Received: by ghbz22 with SMTP id z22so8308010ghb.13 for ; Thu, 05 Jul 2012 00:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VQIA0zHGvyl0olWdpvNavxdjU2dohsxGHQrqV0+q5xc=; b=HiWRpc0641UUHxf5oxmELlwdMRKlCnNKxKyqhD4SmJPQkwkUGzW7PJWa5KVtms+8nY uUAD0maCmik+pBnkCeS/jhoGiedw4rCrSq8xg7GSfQmzsich/C/mG0ZYbC80SOcGYPoH nnsVG0KMl4veFWzK3FXLF3azo81QPnuaDkr5AYqFZIdduhZizwcW1S2fwyiXabGxuklP xo6lDdVhE75E+dnzD+yIVLouIj7hYpfYxgPJA+LBhAfyN8jGtvnqC4UjCBYTZq2iS0k7 4swj+3u5qwP1glH4IZ2TLQmysa0lxaMOa4hlhmK9c7d5hfADcCch3LwODI7CSZc75FZP 8NBA== MIME-Version: 1.0 Received: by 10.68.136.229 with SMTP id qd5mr25606989pbb.2.1341471642405; Thu, 05 Jul 2012 00:00:42 -0700 (PDT) Received: by 10.68.226.7 with HTTP; Thu, 5 Jul 2012 00:00:42 -0700 (PDT) In-Reply-To: <168031EF-1CBD-4B14-A99E-D5C90B01111C@FreeBSD.org> References: <7F5E65B1-24AF-4942-A273-093EBAE94B7D@FreeBSD.org> <168031EF-1CBD-4B14-A99E-D5C90B01111C@FreeBSD.org> Date: Thu, 5 Jul 2012 02:00:42 -0500 Message-ID: From: Alan Cox To: Steve Wills Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: panic after starting X with r238120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 07:00:43 -0000 On Wed, Jul 4, 2012 at 4:57 PM, Steve Wills wrote: > Setting kern.ipc.shm_use_phys back to 0 (the default) fixed it. I had set > it to 1 for some reason that I can't recall. > > That shouldn't cause a crash in pmap_enter(). What is line 3587 of pmap.c in your sources? You mentioned DRM. Are you using the new Intel graphics driver? Alan From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 07:23:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60DEA1065701 for ; Thu, 5 Jul 2012 07:23:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id E4BD78FC15 for ; Thu, 5 Jul 2012 07:23:00 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 293061363 for freebsd-current@freebsd.org; Thu, 05 Jul 2012 09:22:53 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 5 Jul 2012 09:22:51 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201207050922.51906.hselasky@c2i.net> Subject: bus_dmamem_alloc failed to align memory properly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 07:23:01 -0000 Hi, Someone reported to me that the following happens when allocating a 64K block aligned to 64K: freebsd/sys/x86/x86/busdma_machdep.c: printf("bus_dmamem_alloc failed to align memory properly.\n"); Any clues how to debug? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 08:29:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38B301065672 for ; Thu, 5 Jul 2012 08:29:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 09D3C8FC12 for ; Thu, 5 Jul 2012 08:29:39 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so13418953pbb.13 for ; Thu, 05 Jul 2012 01:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QhWtghO+14GnV+dPTUjlVjx30H4tInBbZkbacOeHXZk=; b=zoXOatIZRGV7Rw5mxMpFtM4m9wvDU0ZYR9G2kAk9kPwdOy67kiCqb/Oq3KKx+D+3JQ 3jDfH9Z+fIMNgmucTKWsBr37A7AMp4SxfZsWORQuMAzXamlgJeQEEhYrHBdpNbd3glIj i5ZFAoBNi7Ww0UvSJx57dKdRJZriCIbvWhC8t5LuUJDuISflCRTlglHO66my7/8TyO7A dqrnJfvIQOS2Eb4KbPTeNauFMqPeMKavUKj/JsWncLkhDE389AfSGIMe+iggRgbzRlLq +0db72qz1shTTeOeJrpUSXhpk18EKglxnJBEEkr13ZSec+VHSQ3bVSesHzOlgmbPWZgM xPxA== Received: by 10.68.239.103 with SMTP id vr7mr19188714pbc.0.1341476978407; Thu, 05 Jul 2012 01:29:38 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id og4sm19346305pbb.48.2012.07.05.01.29.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 01:29:37 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 05 Jul 2012 17:29:31 -0700 From: YongHyeon PYUN Date: Thu, 5 Jul 2012 17:29:30 -0700 To: Willem Jan Withagen Message-ID: <20120706002930.GA1466@michelle.cdnetworks.com> References: <4FF41610.10402@digiware.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF41610.10402@digiware.nl> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current Subject: Re: sk0 link bouncing 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: Thu, 05 Jul 2012 08:29:39 -0000 On Wed, Jul 04, 2012 at 12:08:16PM +0200, Willem Jan Withagen wrote: > Hi, > > I've got tons of these since I stopped loading the port with traffic.... > It seems to have a pretty steady 27 min interval. > > Jul 4 07:00:05 freetest kernel: sk0: link state changed to DOWN > Jul 4 07:00:05 freetest kernel: sk0: link state changed to UP > Jul 4 07:27:21 freetest kernel: sk0: link state changed to DOWN > Jul 4 07:27:21 freetest kernel: sk0: link state changed to UP > Jul 4 07:53:48 freetest kernel: sk0: link state changed to DOWN > Jul 4 07:53:48 freetest kernel: sk0: link state changed to UP > Jul 4 08:21:16 freetest kernel: sk0: link state changed to DOWN > Jul 4 08:21:16 freetest kernel: sk0: link state changed to UP > Jul 4 08:48:10 freetest kernel: sk0: link state changed to DOWN > Jul 4 08:48:11 freetest kernel: sk0: link state changed to UP > Jul 4 09:13:38 freetest kernel: sk0: link state changed to DOWN > Jul 4 09:13:38 freetest kernel: sk0: link state changed to UP > Jul 4 09:39:06 freetest kernel: sk0: link state changed to DOWN > Jul 4 09:39:06 freetest kernel: sk0: link state changed to UP > > Very recent 10-current install with std GENERIC kernel. > FreeBSD freetest.digiware.nl 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Sat > Jun 30 09:35:43 UTC 2012 > root@freetest.digiware.nl:/usr/obj/usr/src/sys/GENERIC amd64 > > The port is connected to a basic netgear 10/100/1000 switch with nothing > modified in the config of that port. > Other connections do not seem to suffer from disconnecting. > > Used the server to 'zfs send' a 360G backup to, and then it did not do > anything like this, the port just stayed up. > > Suggestions where of what to look for this? Probably you have to implement link state change handler for Marvell controller(i.e. sk_marv_miibus_statchg()). Locking for MII access should be revisited too. Sorry, don't have spare time to do that. > > Thanx, > --WjW From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 08:32:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD75A106567A for ; Thu, 5 Jul 2012 08:32:01 +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 6B31C8FC14 for ; Thu, 5 Jul 2012 08:32:01 +0000 (UTC) Received: from [46.244.129.177] (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 1SmhTi-0005bP-4Z; Thu, 05 Jul 2012 10:31:58 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id q658VuoQ003034; Thu, 5 Jul 2012 10:31:56 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id q658VsuK003033; Thu, 5 Jul 2012 10:31:54 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Thu, 5 Jul 2012 10:31:53 +0200 From: Matthias Apitz To: Kaho Toshikazu Message-ID: <20120705083153.GA3020@tinyCurrent> References: <201206301349.58930.erich@alogreentechnologies.com> <20120630151130.GA1106@tiny.Sisis.de> <201207010629.29148.erich@alogreentechnologies.com> <20120701065849.GA2681@tinyCurrent> <6039.1341276697@pf2.ed.niigata-u.ac.jp> <20120703104007.GA2780@tinyCurrent> <81815.1341397988@elam.kais.kyoto-u.ac.jp> <20120705052833.GA2386@tinyCurrent> <20120705055730.GA2516@tinyCurrent> <26978.1341470182@elam.kais.kyoto-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <26978.1341470182@elam.kais.kyoto-u.ac.jp> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 46.244.129.177 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 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: Thu, 05 Jul 2012 08:32:02 -0000 El día Thursday, July 05, 2012 a las 03:36:22PM +0900, Kaho Toshikazu escribió: > Hello Matthias Apitz, and ML members, > > Thanks to upload acpi dump. Your keyboard controller ID is "PNP030B", > and your posted patch may be correct. Please undo your reversion, > and try your patch. Hello Kaho and all, Yes! Now it works after inserting the line shown below: $ dmesg | fgrep kbd kbd1 at kbdmux0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 also the mouse works fine; Thanks for helping me getting to the point. I will later comment the bug report in the issue tracker. Interesting question remains: why it works in the older revision r214444? matthias > > maybe it helps to add a line like this: > > > > static struct isa_pnp_id atkbdc_ids[] = { > > { 0x0303d041, "Keyboard controller (i8042)" }, /* PNP0303 */ > > { 0x2003d041, "Keyboard controller (i8042)" }, /* PNP0320 */ > > + { 0x0b03d041, "Keyboard controller (i8042)" }, /* PNP030B */ > > { 0 } > > > > -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 09:02:13 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BF36106566C; Thu, 5 Jul 2012 09:02:13 +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 4C6468FC0C; Thu, 5 Jul 2012 09:02:12 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA19567; Thu, 05 Jul 2012 12:02:06 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Smhws-00043U-50; Thu, 05 Jul 2012 12:02:06 +0300 Message-ID: <4FF5580B.9060305@FreeBSD.org> Date: Thu, 05 Jul 2012 12:02:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Waitman Gobble References: <1341465583.77262@da3m0n8t3r.com> In-Reply-To: <1341465583.77262@da3m0n8t3r.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Baptiste Daroussin , FreeBSD Current Subject: Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 09:02:13 -0000 on 05/07/2012 08:19 Waitman Gobble said the following: > I can create and submit a port for libreoffice 3.6.0.0 if anyone is > interested in trying the "beta" version. Might take a few days. Still working > on it. We have mailing list office@FreeBSD.org for people who are interested in openoffice, libreoffice, etc. Thank you for your work! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 09:20:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 596201065743 for ; Thu, 5 Jul 2012 09:20:46 +0000 (UTC) (envelope-from kaho@elam.kais.kyoto-u.ac.jp) Received: from elam.kais.kyoto-u.ac.jp (elam.kais.kyoto-u.ac.jp [130.54.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id E7E9F8FC16 for ; Thu, 5 Jul 2012 09:20:45 +0000 (UTC) Received: from elam.kais.kyoto-u.ac.jp (localhost [127.0.0.1]) by elam.kais.kyoto-u.ac.jp (8.14.4/8.14.4) with ESMTP id q659KZIW084819; Thu, 5 Jul 2012 18:20:35 +0900 (JST) (envelope-from kaho@elam.kais.kyoto-u.ac.jp) To: Matthias Apitz From: Kaho Toshikazu References: <201206301349.58930.erich@alogreentechnologies.com> <20120630151130.GA1106@tiny.Sisis.de> <201207010629.29148.erich@alogreentechnologies.com> <20120701065849.GA2681@tinyCurrent> <6039.1341276697@pf2.ed.niigata-u.ac.jp> <20120703104007.GA2780@tinyCurrent> <81815.1341397988@elam.kais.kyoto-u.ac.jp> <20120705052833.GA2386@tinyCurrent> <20120705055730.GA2516@tinyCurrent> <26978.1341470182@elam.kais.kyoto-u.ac.jp> <20120705083153.GA3020@tinyCurrent> X-Mailer: MH-E 8.0.3; MH 6.8.4.JP-3.05; GNU Emacs 22.3.1 User-Agent: EMH/1.14.1 SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?S?= =?ISO-8859-4?Q?hij=F2?=) APEL/10.7 Emacs/22.3 (i386-portbld-freebsd7.3) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Date: Thu, 05 Jul 2012 18:20:35 +0900 Message-ID: <84818.1341480035@elam.kais.kyoto-u.ac.jp> Sender: kaho@elam.kais.kyoto-u.ac.jp Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 09:20:46 -0000 Hello, > Interesting question remains: why it works in the older revision r214444? I don't know exactly resource management, but ISA_PNP_PROBE() ignores device.hints if acpi unknown device takes resources. I think this problem is related to some acpi changes. -- kaho@elam.kais.kyoto-u.ac.jp From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 10:31:49 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1190D106566B for ; Thu, 5 Jul 2012 10:31:49 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward2h.mail.yandex.net (forward2h.mail.yandex.net [84.201.187.147]) by mx1.freebsd.org (Postfix) with ESMTP id B92A38FC15 for ; Thu, 5 Jul 2012 10:31:48 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward2h.mail.yandex.net (Yandex) with ESMTP id A4162700B88 for ; Thu, 5 Jul 2012 14:31:13 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 85203170025B for ; Thu, 5 Jul 2012 14:31:13 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id VCK8IoaQ-VDKKXMo9; Thu, 5 Jul 2012 14:31:13 +0400 X-Yandex-Rcpt-Suid: freebsd-current@FreeBSD.org Message-ID: <4FF56CF0.9040507@passap.ru> Date: Thu, 05 Jul 2012 14:31:12 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [clang] world crossbuilding amd64 at i386 fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 10:31:49 -0000 Hi List, I've got a fresh CURRENT and try to build amd64 world at i386 host (TARGET=amd64). I get the error: ----- [...] ===> sbin/conscontrol (depend) ./gengenrtl -h > genrtl.h ./gengenrtl: Exec format error *** [genrtl.h] Error code 126 1 error ----- The system at the host is built with clang and with options: ----- WITH_CLANG_IS_CC="YES" WITH_LIBCPLUSPLUS="YES" ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 06:36:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60F0D106564A for ; Thu, 5 Jul 2012 06:36:34 +0000 (UTC) (envelope-from kaho@elam.kais.kyoto-u.ac.jp) Received: from elam.kais.kyoto-u.ac.jp (elam.kais.kyoto-u.ac.jp [130.54.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0FB8FC0A for ; Thu, 5 Jul 2012 06:36:33 +0000 (UTC) Received: from elam.kais.kyoto-u.ac.jp (localhost [127.0.0.1]) by elam.kais.kyoto-u.ac.jp (8.14.4/8.14.4) with ESMTP id q656aMWM026979; Thu, 5 Jul 2012 15:36:22 +0900 (JST) (envelope-from kaho@elam.kais.kyoto-u.ac.jp) To: Matthias Apitz References: <20120629133422.GA2233@tiny.Sisis.de> <201206301349.58930.erich@alogreentechnologies.com> <20120630151130.GA1106@tiny.Sisis.de> <201207010629.29148.erich@alogreentechnologies.com> <20120701065849.GA2681@tinyCurrent> <6039.1341276697@pf2.ed.niigata-u.ac.jp> <20120703104007.GA2780@tinyCurrent> <81815.1341397988@elam.kais.kyoto-u.ac.jp> <20120705052833.GA2386@tinyCurrent> <20120705055730.GA2516@tinyCurrent> X-Mailer: MH-E 8.0.3; MH 6.8.4.JP-3.05; GNU Emacs 22.3.1 User-Agent: EMH/1.14.1 SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?S?= =?ISO-8859-4?Q?hij=F2?=) APEL/10.7 Emacs/22.3 (i386-portbld-freebsd7.3) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Date: Thu, 05 Jul 2012 15:36:22 +0900 Message-ID: <26978.1341470182@elam.kais.kyoto-u.ac.jp> From: Kaho Toshikazu X-Mailman-Approved-At: Thu, 05 Jul 2012 11:14:05 +0000 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 06:36:34 -0000 Hello Matthias Apitz, and ML members, Thanks to upload acpi dump. Your keyboard controller ID is "PNP030B", and your posted patch may be correct. Please undo your reversion, and try your patch. Matthias Apitz wrote: > > and there is now an entry for "PS2K" (not for "KBC"): > > > > Device (PS2K) > > { > > Name (_HID, EisaId ("PNP030B")) > > Name (_CID, EisaId ("PNP030B")) > > Method (_STA, 0, NotSerialized) > > { > > ShiftLeft (0x01, 0x0A, Local0) > > If (And (IOST, Local0)) > > { > > Return (0x0F.... > > > > the full file is here: http://www.unixarea.de/acpidump-r214444.txt > > maybe it helps to add a line like this: > > static struct isa_pnp_id atkbdc_ids[] = { > { 0x0303d041, "Keyboard controller (i8042)" }, /* PNP0303 */ > { 0x2003d041, "Keyboard controller (i8042)" }, /* PNP0320 */ > + { 0x0b03d041, "Keyboard controller (i8042)" }, /* PNP030B */ > { 0 } > > -- kaho@elam.kais.kyoto-u.ac.jp From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 08:41:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0895D106566B for ; Thu, 5 Jul 2012 08:41:54 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 948908FC0A for ; Thu, 5 Jul 2012 08:41:53 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 4BAE815343E; Thu, 5 Jul 2012 10:41:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEqXXWcCQKvg; Thu, 5 Jul 2012 10:41:51 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 9B219153433; Thu, 5 Jul 2012 10:41:51 +0200 (CEST) Message-ID: <4FF5534F.7050106@digiware.nl> Date: Thu, 05 Jul 2012 10:41:51 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4FF41610.10402@digiware.nl> <20120706002930.GA1466@michelle.cdnetworks.com> In-Reply-To: <20120706002930.GA1466@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 05 Jul 2012 11:14:20 +0000 Cc: FreeBSD Current Subject: Re: sk0 link bouncing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 08:41:54 -0000 On 2012-07-06 2:29, YongHyeon PYUN wrote: > On Wed, Jul 04, 2012 at 12:08:16PM +0200, Willem Jan Withagen wrote: >> Hi, >> >> I've got tons of these since I stopped loading the port with traffic.... >> It seems to have a pretty steady 27 min interval. >> >> Jul 4 07:00:05 freetest kernel: sk0: link state changed to DOWN >> Jul 4 07:00:05 freetest kernel: sk0: link state changed to UP >> Jul 4 07:27:21 freetest kernel: sk0: link state changed to DOWN >> Jul 4 07:27:21 freetest kernel: sk0: link state changed to UP >> Jul 4 07:53:48 freetest kernel: sk0: link state changed to DOWN >> Jul 4 07:53:48 freetest kernel: sk0: link state changed to UP >> Jul 4 08:21:16 freetest kernel: sk0: link state changed to DOWN >> Jul 4 08:21:16 freetest kernel: sk0: link state changed to UP >> Jul 4 08:48:10 freetest kernel: sk0: link state changed to DOWN >> Jul 4 08:48:11 freetest kernel: sk0: link state changed to UP >> Jul 4 09:13:38 freetest kernel: sk0: link state changed to DOWN >> Jul 4 09:13:38 freetest kernel: sk0: link state changed to UP >> Jul 4 09:39:06 freetest kernel: sk0: link state changed to DOWN >> Jul 4 09:39:06 freetest kernel: sk0: link state changed to UP >> >> Very recent 10-current install with std GENERIC kernel. >> FreeBSD freetest.digiware.nl 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Sat >> Jun 30 09:35:43 UTC 2012 >> root@freetest.digiware.nl:/usr/obj/usr/src/sys/GENERIC amd64 >> >> The port is connected to a basic netgear 10/100/1000 switch with nothing >> modified in the config of that port. >> Other connections do not seem to suffer from disconnecting. >> >> Used the server to 'zfs send' a 360G backup to, and then it did not do >> anything like this, the port just stayed up. >> >> Suggestions where of what to look for this? > > Probably you have to implement link state change handler for > Marvell controller(i.e. sk_marv_miibus_statchg()). Locking for > MII access should be revisited too. > Sorry, don't have spare time to do that. I think I understand you comments. But I do not have the knowledge to do this. :( The board also has an msk0, which I'm now trying. Thanx, --WjW From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 14:38:34 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C59A1065687 for ; Thu, 5 Jul 2012 14:38:34 +0000 (UTC) (envelope-from gnn@FreeBSD.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 4FE798FC1B for ; Thu, 5 Jul 2012 14:38:34 +0000 (UTC) Received: from [209.249.190.124] (port=55044 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SmnCO-0001xv-63; Thu, 05 Jul 2012 10:38:28 -0400 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <20120704194917.GA15426@misty.eyesbeyond.com> Date: Thu, 5 Jul 2012 10:38:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2244ACD7-892A-4CA7-90B1-FFF41AF6B317@FreeBSD.org> References: <86hatodavd.wl%gnn@neville-neil.com> <1341340703.6639@da3m0n8t3r.com> <20120704194917.GA15426@misty.eyesbeyond.com> To: Greg Lewis X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org Cc: Waitman Gobble , current@FreeBSD.org Subject: Re: Java and NIO? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 14:38:34 -0000 On Jul 4, 2012, at 15:49 , Greg Lewis wrote: > On Tue, Jul 03, 2012 at 11:38:23AM -0700, Waitman Gobble wrote: >> gnn@freebsd.org wrote .. >>> Howdy, >>>=20 >>> Can someone tell me if anyone is working on this Java NIO bug? >>>=20 >>> = http://freebsd.1045724.n5.nabble.com/i386-159787-openjdk-1-6-nio-muti-thre= ad-bug-td4700530.html >>>=20 >>> I would like to avoid using Linux just to run Zookeeper: >>>=20 >>> = http://zookeeper-user.578899.n2.nabble.com/What-s-the-problem-with-nio-on-= FreeBSD-td5208183.html >>=20 >> Hi George, >>=20 >> There is/was a patch from David Xu=20 >> = http://lists.freebsd.org/pipermail/freebsd-java/2010-August/008747.html >> maybe this fixes it?=20 >=20 > This patch was incorporated into the openjdk6 port soon after it was > posted. However, I can still reproduce the problem. Using > = -Djava.nio.channels.spi.SelectorProvider=3Dsun.nio.ch.KqueueSelectorProvid= er > makes no difference. >=20 >> also looks like New I/O was updated in jdk7... but would have to = check it out to see if issue still exists.. >=20 > I can't reproduce the problem with the current openjdk7 port. I = haven't > tried out Zookeeper though, so YMMV. I would say it's definitely = worth > a try though. >=20 > I don't believe anyone is currently working on a fix for the openjdk6 = port > for this. I'm going to give zookeeper a try with openjdk7. Thanks! Best, George From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 17:40:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3F6B1065679; Thu, 5 Jul 2012 17:40:48 +0000 (UTC) (envelope-from i@levsha.me) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id A4D028FC23; Thu, 5 Jul 2012 17:40:48 +0000 (UTC) Received: from [178.94.25.155] (helo=laptop.levsha.me) by expo.ukrweb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Smq2k-0008YL-NQ; Thu, 05 Jul 2012 20:40:47 +0300 Received: from levsha by laptop.levsha.me with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Smq2S-0000jd-WF; Thu, 05 Jul 2012 20:40:25 +0300 Date: Thu, 5 Jul 2012 20:40:24 +0300 From: Mykola Dzham To: theraven@freebsd.org Message-ID: <20120705174024.GA2779@laptop.levsha.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Mykola Dzham X-SA-Exim-Connect-IP: 178.94.25.155 X-SA-Exim-Mail-From: i@levsha.me X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on expo.ukrweb.net X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=no version=3.3.2 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on expo.ukrweb.net) X-Spam-Level: -- X-Spam-Report: -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-current@freebsd.org Subject: Can't build x11/rxvt-unicode after r236890 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 17:40:49 -0000 Hi! After r236890 x11/rxvt-unicode is unbuildable: ... c++ -I.. -I. -I. -I./../libev -I./../libptytty/src -I./../libecb -DHAVE_CONFIG_H -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include -O2 -pipe -fno-strict-aliasing -w -I/usr/local/include -D_REENTRANT -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libpng15 -I/usr/local/include/glib-2.0 -c rxvtc.C PERL="/usr/bin/perl5" /usr/bin/perl5 /usr/local/lib/perl5/5.12.4/ExtUtils/xsubpp -C++ -typemap /usr/local/lib/perl5/5.12.4/ExtUtils/typemap -typemap typemap.iom -typemap typemap -prototypes ./rxvtperl.xs >rxvtperl.C /usr/bin/perl5 -MExtUtils::Embed -e xsinit -- -std urxvt cc -o rxvtc rxvtc.o rxvtdaemon.o fdpass_wrapper.o -lutil -lsupc++ -lm rxvtdaemon.o: In function `rxvt_connection::recv(auto_ptr&, int*)': rxvtdaemon.C:(.text+0x28e): undefined reference to `operator new[](unsigned long)' On r236889 rxvt-unicode builds properly. Full build log from tb: http://levsha.me/tb/errors/10-HEAD.amd64/rxvt-unicode-9.15_1.log -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 19:15:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA10C1065691 for ; Thu, 5 Jul 2012 19:15:25 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 71EF38FC0C for ; Thu, 5 Jul 2012 19:15:25 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 1E79883A0; Fri, 6 Jul 2012 04:15:24 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id lSE11PZXRBUO; Fri, 6 Jul 2012 04:15:19 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA; Fri, 6 Jul 2012 04:15:19 +0900 (JST) Date: Fri, 6 Jul 2012 04:15:18 +0900 From: Taku YAMAMOTO To: Konstantin Belousov Message-Id: <20120706041518.de7e2ab5.taku@tackymt.homeip.net> In-Reply-To: <20120704211414.GR2337@deviant.kiev.zoral.com.ua> References: <20120704233316.70ec8654.taku@tackymt.homeip.net> <4FF45C6E.1080000@FreeBSD.org> <20120705003201.bb297e8a.taku@tackymt.homeip.net> <20120704211414.GR2337@deviant.kiev.zoral.com.ua> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.24.6; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FYI: SIGBUS with world built by 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: Thu, 05 Jul 2012 19:15:25 -0000 On Thu, 5 Jul 2012 00:14:14 +0300 Konstantin Belousov wrote: > On Thu, Jul 05, 2012 at 12:32:01AM +0900, Taku YAMAMOTO wrote: > > On Wed, 04 Jul 2012 17:08:30 +0200 > > Dimitry Andric wrote: > > > > > On 2012-07-04 16:33, Taku YAMAMOTO wrote: > > > > For people having SIGBUS with clang-build world + gcc-build binaries, > > > > > > > > > > > > In short words, for any libraries (and never forget about rtld-elf!) > > > > which are potentially called from arbitrary binaries, > > > > compile them with either -mstackrealign or -mstack-alignment=8! > > > > > > > > The detail is as follows. > > > > > > > > I've observed that clang carelessly expects the stack being aligned at > > > > 16 byte boundary. > > > > > > Eh, this is a requirement of the amd64 ABI. Any compiler that *doesn't* > > > align the stack on 16-byte boundaries is basically broken. Or are you > > > experiencing this on i386? Even there, 16-byte alignment would be much > > > better in combination with SSE instructions (which arent' enabled by > > > default, btw). > > > > Oops, I had to be clear about that! > > Yes, the experiment was took on i386 (actually -march=pentium4). > > > > > Note that you would get the same issue with newer versions of gcc, which > > > will also assume this alignment. > > > > Interesting, but the base gcc we currently have won't on i386, I think. > > (I occationally get bitten by similar problem when using -ftree-vectorize) > As far as I understand the rules, $esp % 16 must be zero before call > instruction is executed. I googled and found that it is enforced by MacOS X ABI for IA32 but i386 SysV ABI defines otherwise (8 bytes instead of 16 bytes). > i386 csu explicitely aligns the stack before calling into C land, everything > else should be the C compiler own offence :). Unfortunately it is difficult when we have to deal with binaries produced by random compilers, such as Win32 app via wine, mplayer with win32-codecs, etc. ;) JITs, like Java and mono, also have possibility to become victims if they emit native codes without paying attention to the stack alignment, though I'm not sure. Just my random thoughts, -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 20:02:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64AD51065700 for ; Thu, 5 Jul 2012 20:02:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 382F48FC12 for ; Thu, 5 Jul 2012 20:02:23 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 98A30B963; Thu, 5 Jul 2012 16:02:22 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 5 Jul 2012 07:39:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201206301349.58930.erich@alogreentechnologies.com> <20120705083153.GA3020@tinyCurrent> <84818.1341480035@elam.kais.kyoto-u.ac.jp> In-Reply-To: <84818.1341480035@elam.kais.kyoto-u.ac.jp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207050739.18457.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Jul 2012 16:02:22 -0400 (EDT) Cc: Matthias Apitz , Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 20:02:23 -0000 On Thursday, July 05, 2012 5:20:35 am Kaho Toshikazu wrote: > Hello, > > > Interesting question remains: why it works in the older revision r214444? > > I don't know exactly resource management, but ISA_PNP_PROBE() > ignores device.hints if acpi unknown device takes resources. > I think this problem is related to some acpi changes. The system in general in 9.0 and later is more strict about honoring what the BIOS says in terms of allocating resources, so we have to be more correct in probing devices. The only wrinkles so far do in fact seem to stem from the keyboard controller. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 20:11:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2FFC106564A for ; Thu, 5 Jul 2012 20:11:36 +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 4C3608FC0A for ; Thu, 5 Jul 2012 20:11:35 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q65KBig3088887; Thu, 5 Jul 2012 23:11:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q65KBVaT005324; Thu, 5 Jul 2012 23:11:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q65KBVJJ005323; Thu, 5 Jul 2012 23:11:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Jul 2012 23:11:31 +0300 From: Konstantin Belousov To: Taku YAMAMOTO Message-ID: <20120705201131.GC2338@deviant.kiev.zoral.com.ua> References: <20120704233316.70ec8654.taku@tackymt.homeip.net> <4FF45C6E.1080000@FreeBSD.org> <20120705003201.bb297e8a.taku@tackymt.homeip.net> <20120704211414.GR2337@deviant.kiev.zoral.com.ua> <20120706041518.de7e2ab5.taku@tackymt.homeip.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3siQDZowHQqNOShm" Content-Disposition: inline In-Reply-To: <20120706041518.de7e2ab5.taku@tackymt.homeip.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: FYI: SIGBUS with world built by 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: Thu, 05 Jul 2012 20:11:36 -0000 --3siQDZowHQqNOShm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 06, 2012 at 04:15:18AM +0900, Taku YAMAMOTO wrote: > On Thu, 5 Jul 2012 00:14:14 +0300 > Konstantin Belousov wrote: >=20 > > On Thu, Jul 05, 2012 at 12:32:01AM +0900, Taku YAMAMOTO wrote: > > > On Wed, 04 Jul 2012 17:08:30 +0200 > > > Dimitry Andric wrote: > > >=20 > > > > On 2012-07-04 16:33, Taku YAMAMOTO wrote: > > > > > For people having SIGBUS with clang-build world + gcc-build binar= ies, > > > > >=20 > > > > >=20 > > > > > In short words, for any libraries (and never forget about rtld-el= f!) > > > > > which are potentially called from arbitrary binaries, > > > > > compile them with either -mstackrealign or -mstack-alignment=3D8! > > > > >=20 > > > > > The detail is as follows. > > > > >=20 > > > > > I've observed that clang carelessly expects the stack being align= ed at > > > > > 16 byte boundary. > > > >=20 > > > > Eh, this is a requirement of the amd64 ABI. Any compiler that *doe= sn't* > > > > align the stack on 16-byte boundaries is basically broken. Or are = you > > > > experiencing this on i386? Even there, 16-byte alignment would be = much > > > > better in combination with SSE instructions (which arent' enabled by > > > > default, btw). > > >=20 > > > Oops, I had to be clear about that! > > > Yes, the experiment was took on i386 (actually -march=3Dpentium4). > > >=20 > > > > Note that you would get the same issue with newer versions of gcc, = which > > > > will also assume this alignment. > > >=20 > > > Interesting, but the base gcc we currently have won't on i386, I thin= k. > > > (I occationally get bitten by similar problem when using -ftree-vecto= rize) > > As far as I understand the rules, $esp % 16 must be zero before call > > instruction is executed. >=20 > I googled and found that it is enforced by MacOS X ABI for IA32 but > i386 SysV ABI defines otherwise (8 bytes instead of 16 bytes). No, SysV ABI only requires 4-byte alignment for the stack on i386. >=20 > > i386 csu explicitely aligns the stack before calling into C land, every= thing > > else should be the C compiler own offence :). >=20 > Unfortunately it is difficult when we have to deal with binaries produced= by > random compilers, such as Win32 app via wine, mplayer with win32-codecs, = etc. ;) >=20 > JITs, like Java and mono, also have possibility to become victims if they > emit native codes without paying attention to the stack alignment, though > I'm not sure. >=20 > Just my random thoughts, > --=20 > -|-__ YAMAMOTO, Taku > | __ < >=20 > - A chicken is an egg's way of producing more eggs. - --3siQDZowHQqNOShm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/19PMACgkQC3+MBN1Mb4iEcACg718pKmwEUvCLhSqe7K3c7sFI 5lQAoLl5BwSokpjEHdm4FOmiomJ/lph/ =c8qA -----END PGP SIGNATURE----- --3siQDZowHQqNOShm-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 20:24:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 156361065670 for ; Thu, 5 Jul 2012 20:24:41 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9CAB28FC12 for ; Thu, 5 Jul 2012 20:24:40 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so8511750wgb.31 for ; Thu, 05 Jul 2012 13:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/Gqc1BpSXfp/QqglPZvW76dWM+Ro0p59rRK3HUAn6x4=; b=I8iDSMFXmDa0qy3LFY+I8NOL+xuRi5uaizR8iJ6wtnS3xMBjN/rTrjKox0cxcysAkH WJfKCTwUo0LXtHvQNUBO5fwbtukUNaAa0Ns9idkWW/UrX67csD3WX6g8jCxcpxTrWOQo /J5jon78khbvCJG6QSBeoQbry71C+ypoUL1G1NCqivd53n4F7O2b4R5KofYM75tZLx4O JRz82ILn/w8Mo4fuHONJ2dhdTM702zc+CZJxgKWSZls6uYhHj4PDCyu4So8VQD3oUcGO 2owiW1Cof227mITmfn5EMefkyPjxyYqBB5JxfS7ObGWJPzrA33DCNTRMxACo+z2lzSTG 33vA== MIME-Version: 1.0 Received: by 10.180.96.3 with SMTP id do3mr2115374wib.5.1341519874163; Thu, 05 Jul 2012 13:24:34 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Thu, 5 Jul 2012 13:24:34 -0700 (PDT) In-Reply-To: <201207051049.26199.erichfreebsdlist@ovitrap.com> References: <201207051049.26199.erichfreebsdlist@ovitrap.com> Date: Thu, 5 Jul 2012 13:24:34 -0700 Message-ID: From: Kevin Oberman To: Erich Dollansky Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: side note on the X220 running CURRENT: head phone jack works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 20:24:41 -0000 On Wed, Jul 4, 2012 at 8:49 PM, Erich Dollansky wrote: > Hi, > > there have been some people here - including me - wondering whether the head phone jack works. Yes, it does. > > I just have had the chance to connect the head phone jack. It works when vlc is set to use /dev/dsp1.0. > > Using /dev/dsp0.1 brings sound to the built-in speakers. The "proper" fix is to add the following to /boot/loader.conf: # Out : speaker + headphones hint.hdac.0.cad0.nid25.config="as=1 seq=15" # In : mic + external mic hint.hdac.0.cad0.nid35.config="as=2" hint.hdac.0.cad0.nid27.config="as=2 seq=15" This will make the mic work for headsets that have a mic and will make the headphones DTRT so that audio is sent to the headphones and the speakers are muted when headphones are plugged in. NOTE: This works on the T520, but the X220 seems to be very similar in most every way I have seen. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 20:25:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77AD8106564A; Thu, 5 Jul 2012 20:25:28 +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 2FDAC8FC12; Thu, 5 Jul 2012 20:25:28 +0000 (UTC) Received: from [89.204.130.92] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Smsc9-0001C5-3c; Thu, 05 Jul 2012 22:25:25 +0200 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q65KPM1g001664; Thu, 5 Jul 2012 22:25:23 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q65KPLpL001663; Thu, 5 Jul 2012 22:25:21 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Thu, 5 Jul 2012 22:25:21 +0200 From: Matthias Apitz To: John Baldwin Message-ID: <20120705202520.GA1637@tiny.Sisis.de> References: <201206301349.58930.erich@alogreentechnologies.com> <20120705083153.GA3020@tinyCurrent> <84818.1341480035@elam.kais.kyoto-u.ac.jp> <201207050739.18457.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201207050739.18457.jhb@freebsd.org> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.130.92 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 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: Thu, 05 Jul 2012 20:25:28 -0000 El día Thursday, July 05, 2012 a las 07:39:18AM -0400, John Baldwin escribió: > On Thursday, July 05, 2012 5:20:35 am Kaho Toshikazu wrote: > > Hello, > > > > > Interesting question remains: why it works in the older revision r214444? > > > > I don't know exactly resource management, but ISA_PNP_PROBE() > > ignores device.hints if acpi unknown device takes resources. > > I think this problem is related to some acpi changes. > > The system in general in 9.0 and later is more strict about honoring what the > BIOS says in terms of allocating resources, so we have to be more correct in > probing devices. The only wrinkles so far do in fact seem to stem from the > keyboard controller. > Somehow the system should bring up at least console in- and output; if not you are completely locked out; in my case it was simple, because I was booting fron an USB key and could tailor the USB booted system to bring up interface+DHCP+SSH to login via SSH; but without this you are lost matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 20:44:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E0EC106564A for ; Thu, 5 Jul 2012 20:44:38 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2A98FC0A for ; Thu, 5 Jul 2012 20:44:38 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 249BB83A0; Fri, 6 Jul 2012 05:44:37 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id RBO3pAt9C2Na; Fri, 6 Jul 2012 05:44:35 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA; Fri, 6 Jul 2012 05:44:35 +0900 (JST) Date: Fri, 6 Jul 2012 05:44:35 +0900 From: Taku YAMAMOTO To: Konstantin Belousov Message-Id: <20120706054435.f23fb592.taku@tackymt.homeip.net> In-Reply-To: <20120705201131.GC2338@deviant.kiev.zoral.com.ua> References: <20120704233316.70ec8654.taku@tackymt.homeip.net> <4FF45C6E.1080000@FreeBSD.org> <20120705003201.bb297e8a.taku@tackymt.homeip.net> <20120704211414.GR2337@deviant.kiev.zoral.com.ua> <20120706041518.de7e2ab5.taku@tackymt.homeip.net> <20120705201131.GC2338@deviant.kiev.zoral.com.ua> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.24.6; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FYI: SIGBUS with world built by 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: Thu, 05 Jul 2012 20:44:38 -0000 On Thu, 5 Jul 2012 23:11:31 +0300 Konstantin Belousov wrote: > On Fri, Jul 06, 2012 at 04:15:18AM +0900, Taku YAMAMOTO wrote: > > On Thu, 5 Jul 2012 00:14:14 +0300 > > Konstantin Belousov wrote: > > > > > On Thu, Jul 05, 2012 at 12:32:01AM +0900, Taku YAMAMOTO wrote: > > > > On Wed, 04 Jul 2012 17:08:30 +0200 > > > > Dimitry Andric wrote: > > > > > > > > > On 2012-07-04 16:33, Taku YAMAMOTO wrote: > > > > > > For people having SIGBUS with clang-build world + gcc-build binaries, > > > > > > > > > > > > > > > > > > In short words, for any libraries (and never forget about rtld-elf!) > > > > > > which are potentially called from arbitrary binaries, > > > > > > compile them with either -mstackrealign or -mstack-alignment=8! > > > > > > > > > > > > The detail is as follows. > > > > > > > > > > > > I've observed that clang carelessly expects the stack being aligned at > > > > > > 16 byte boundary. > > > > > > > > > > Eh, this is a requirement of the amd64 ABI. Any compiler that *doesn't* > > > > > align the stack on 16-byte boundaries is basically broken. Or are you > > > > > experiencing this on i386? Even there, 16-byte alignment would be much > > > > > better in combination with SSE instructions (which arent' enabled by > > > > > default, btw). > > > > > > > > Oops, I had to be clear about that! > > > > Yes, the experiment was took on i386 (actually -march=pentium4). > > > > > > > > > Note that you would get the same issue with newer versions of gcc, which > > > > > will also assume this alignment. > > > > > > > > Interesting, but the base gcc we currently have won't on i386, I think. > > > > (I occationally get bitten by similar problem when using -ftree-vectorize) > > > As far as I understand the rules, $esp % 16 must be zero before call > > > instruction is executed. > > > > I googled and found that it is enforced by MacOS X ABI for IA32 but > > i386 SysV ABI defines otherwise (8 bytes instead of 16 bytes). > No, SysV ABI only requires 4-byte alignment for the stack on i386. (snip) Oh, I stand corrected. Thank you :) -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 21:32:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14291106564A for ; Thu, 5 Jul 2012 21:32:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DCA498FC08 for ; Thu, 5 Jul 2012 21:32:25 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4D5E1B939; Thu, 5 Jul 2012 17:32:25 -0400 (EDT) From: John Baldwin To: Matthias Apitz Date: Thu, 5 Jul 2012 17:22:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201206301349.58930.erich@alogreentechnologies.com> <201207050739.18457.jhb@freebsd.org> <20120705202520.GA1637@tiny.Sisis.de> In-Reply-To: <20120705202520.GA1637@tiny.Sisis.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201207051722.22269.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Jul 2012 17:32:25 -0400 (EDT) Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 21:32:26 -0000 On Thursday, July 05, 2012 4:25:21 pm Matthias Apitz wrote: > El d=EDa Thursday, July 05, 2012 a las 07:39:18AM -0400, John Baldwin esc= ribi=F3: >=20 > > On Thursday, July 05, 2012 5:20:35 am Kaho Toshikazu wrote: > > > Hello, > > >=20 > > > > Interesting question remains: why it works in the older revision r2= 14444? > > >=20 > > > I don't know exactly resource management, but ISA_PNP_PROBE() > > > ignores device.hints if acpi unknown device takes resources. > > > I think this problem is related to some acpi changes. > >=20 > > The system in general in 9.0 and later is more strict about honoring wh= at the=20 > > BIOS says in terms of allocating resources, so we have to be more corre= ct in=20 > > probing devices. The only wrinkles so far do in fact seem to stem from= the=20 > > keyboard controller. > >=20 >=20 > Somehow the system should bring up at least console in- and output; if > not you are completely locked out; in my case it was simple, because I > was booting fron an USB key and could tailor the USB booted system to > bring up interface+DHCP+SSH to login via SSH; but without this you are > lost So far I can't think of a non-hackish way to special case keyboard and mouse controllers, though I'm close to doing so (i.e. just ignore any device that tries to allocate resources in the "default" range for those devices unless it is a "known" device ID). The patch in this thread should be committed though. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 21:32:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1E8D1065670 for ; Thu, 5 Jul 2012 21:32:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C8E7F8FC16 for ; Thu, 5 Jul 2012 21:32:27 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 32D1CB993; Thu, 5 Jul 2012 17:32:27 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 5 Jul 2012 17:27:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FF28682.9020705@zedat.fu-berlin.de> In-Reply-To: <4FF28682.9020705@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201207051727.59295.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Jul 2012 17:32:27 -0400 (EDT) Cc: "O. Hartmann" Subject: Re: 10.0-CURRENT: kernel: Fatal trap 12: page fault while in kernel 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: Thu, 05 Jul 2012 21:32:28 -0000 On Tuesday, July 03, 2012 1:43:30 am O. Hartmann wrote: > The most recent build of FreeBSD 10.0-CURRENT crashes on one of our > boxes with recent Intel hardware, see dmesg extract below. FreeBSD does > obviously only crash on hardware with modern "Sandy-Bridge" hardware, > the very same kernel config and a very similar setup does work very well > on an older Intel Core2Dua architecture. > > Machine in question runs an older kernel (set via nextboot -k > kernel.old) very well: > FreeBSD 10.0-CURRENT #0 r237697: Thu Jun 28 11:45:08 CEST 2012 > > Most recent buildworls/kernels crash after going into multiuser mode > (/etc/rc-scripts getting executed). Below the kernel trap message. > > I do this report on the fly, so if there is need for deeper > investigations let me know, I will provide necessary detail requested. We would need a stack trace to debug this further. Do you have a crashdump? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 22:21:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5A9F1065672; Thu, 5 Jul 2012 22:21:52 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8698FC12; Thu, 5 Jul 2012 22:21:52 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SmuQk-0008TQ-4X>; Fri, 06 Jul 2012 00:21:46 +0200 Received: from e178034011.adsl.alicedsl.de ([85.178.34.11] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SmuQj-000167-Ux>; Fri, 06 Jul 2012 00:21:46 +0200 Message-ID: <4FF61370.4000200@zedat.fu-berlin.de> Date: Fri, 06 Jul 2012 00:21:36 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Baldwin References: <4FF28682.9020705@zedat.fu-berlin.de> <201207051727.59295.jhb@freebsd.org> In-Reply-To: <201207051727.59295.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig547646070B1645203D695045" X-Originating-IP: 85.178.34.11 Cc: freebsd-current@freebsd.org Subject: Re: 10.0-CURRENT: kernel: Fatal trap 12: page fault while in kernel 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: Thu, 05 Jul 2012 22:21:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig547646070B1645203D695045 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 07/05/12 23:27, John Baldwin wrote: > On Tuesday, July 03, 2012 1:43:30 am O. Hartmann wrote: >> The most recent build of FreeBSD 10.0-CURRENT crashes on one of our >> boxes with recent Intel hardware, see dmesg extract below. FreeBSD doe= s >> obviously only crash on hardware with modern "Sandy-Bridge" hardware, >> the very same kernel config and a very similar setup does work very we= ll >> on an older Intel Core2Dua architecture. >> >> Machine in question runs an older kernel (set via nextboot -k >> kernel.old) very well: >> FreeBSD 10.0-CURRENT #0 r237697: Thu Jun 28 11:45:08 CEST 2012 >> >> Most recent buildworls/kernels crash after going into multiuser mode >> (/etc/rc-scripts getting executed). Below the kernel trap message. >> >> I do this report on the fly, so if there is need for deeper >> investigations let me know, I will provide necessary detail requested.= >=20 > We would need a stack trace to debug this further. Do you have a crash= dump? >=20 Well, I built a GENERIC kernel and bootet that, it also crashes, but I didn't find any coredump (as found in the crashes with the custom kernel). I was able to do a backtrace with the GENERIC kernel, but incapable of saving the trace - I did this in a rush, sorry. I went back, just on a hunch, to FreeBSD 10.0-CURRENT #1 r237000, which works, but this isn't the last working revision. I will look tomorrow for how to generate a dump or backtrace and save that somehow (if available in the handbook). Otherwise, if not not much efford, I would appreciate any hint (for the impatient) how to generate suiatbel debug informations. Regards, Oliver --------------enig547646070B1645203D695045 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJP9hN5AAoJEOgBcD7A/5N81RsH/077oPhzRvG0R6ilzJkm7O2m w5s7x+HaOrj4uZ+BsV0hmAwsEQVCDJCleFMDbcA9IkVDRRYDouhQn88C7CmiYcf/ paKSwgCChajCAPx4GuKSQermESaczqviY7bvzc/vVha272LsHcfYGa3GVlSgGJ5+ sGGBmDMQL7YgWPNngZwfCFpnFQeYcgNQmqkpOajihnP/Eq6Veb/Iuad6YE+2R50W UOFWfYRrwt0uLozdTB5IwO3P2U8DKJF6zmCWf6+1bYBefRaqR3dAWsVhIvwzomkK Pf0nzAPPyWvOa0F5oP1JbYZ29nZktRqxaUXp1mn+dDEAyGGgb7vz/XPQqVR7P3Y= =i3+5 -----END PGP SIGNATURE----- --------------enig547646070B1645203D695045-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 22:23:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BF5D106564A for ; Thu, 5 Jul 2012 22:23:51 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id E4AEF8FC19 for ; Thu, 5 Jul 2012 22:23:50 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q65MNnCw036775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Jul 2012 08:23:50 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q65MNi9q086174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jul 2012 08:23:44 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q65MNi1L086173 for freebsd-current@freebsd.org; Fri, 6 Jul 2012 08:23:44 +1000 (EST) (envelope-from peter) Date: Fri, 6 Jul 2012 08:23:44 +1000 From: Peter Jeremy To: freebsd-current@freebsd.org Message-ID: <20120705222344.GC85696@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YD3LsXFS42OYHhNZ" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Subject: RAM fragmention problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 22:23:51 -0000 --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I am running into a problem with RAM fragmentation causing contigmalloc() failures and wonder if anyone has a tool that that would allow me to identify the owner(s) of pages of RAM within a region on amd64. --=20 Peter Jeremy --YD3LsXFS42OYHhNZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/2E/AACgkQ/opHv/APuIelogCfVTuKYo3djzxuhaMrebs/xLLP +T8An0yNPVXTpD+Br3JqANh/Q6hV4Zl7 =a0sb -----END PGP SIGNATURE----- --YD3LsXFS42OYHhNZ-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 23:14:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C035B106566C; Thu, 5 Jul 2012 23:14:29 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 29F5B8FC15; Thu, 5 Jul 2012 23:14:29 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so8618397wgb.31 for ; Thu, 05 Jul 2012 16:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Tg3u0LwO0lSgOxLar0RrzCMgWg4SWbYlWdj/SpUcQHA=; b=xF8y1awOvBlH2MZmN0zLp69Hz0Avn+HexbogxCIhpmOF1HuJz0w6qoHjEFVJLpiiet kTsA6EappWvfQD9NWPLJUfqfHgNtC3W8ASHo/KYAQD8/Zle5MfGi4PPQLpv+ZMxa4asz 0fQ9+q8OvygRzke5/6InkA80AjLMhkZaa6pyjHZ2LNSiKZsFccOtrxZdaizTU2UFIc0+ Ut40kMoniYZBeLqDxa53h5sMherDOUdfNVwS3/7dnRZKScP49MKFxR8y23ooDaBNigPS A7GqtLFLilQhx9YGd1C2+ni9fsSUG3aHK4zjJo+I21XHcNMpLRM5zoaQhOHxyK+BNTXZ 9fIw== MIME-Version: 1.0 Received: by 10.217.3.209 with SMTP id r59mr8701254wes.108.1341530068015; Thu, 05 Jul 2012 16:14:28 -0700 (PDT) Received: by 10.216.47.3 with HTTP; Thu, 5 Jul 2012 16:14:28 -0700 (PDT) Date: Thu, 5 Jul 2012 19:14:28 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers Subject: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 23:14:29 -0000 Hi folks, The problem has been raised in the last BSDCan during a talk, but no clear answer has been given. Some (pseudo-)devices might require resources from multiple other (pseudo-)devices. For example, a device is sitting on an SMBus, but need to access a software controlled LED, sitting on a GPIO bus, itself sitting on an LPC bus... Or a variant where everything is controlled on the same chip, but different GPIO banks. For that specific example, all the GPIO pin could be implement on the same GPIObus, however, gpiobus(4) is limited to 32 pins and the chip provides 5 banks of 8 pins, ie. a total of 40 pins[0]. In the same idea, a device sitting on GPIOs controlled by two independant chips, say one being an ICH10R chipset on a PCI device function, and the other being a SuperIO on an LPC bus. This situation make me really dubious that FreeBSD will be able to support configuration such as: esdhc@50004000 { /* ESDHC1 */ cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */ wp-gpios = <&gpio3 11 0>; /* GPIO4_11 */ status = "okay"; }; or: ecspi@50010000 { /* ECSPI1 */ fsl,spi-num-chipselects = <2>; cs-gpios = <&gpio1 30 0>, /* GPIO2_30 */ <&gpio2 19 0>; /* GPIO3_19 */ status = "okay"; [...] This example is taken from Linux' `arch/arm/boot/dts/imx53-smd.dts'. Here, SDHC or SPI controller are using different GPIO devices. Note that these GPIO pins does not seem to be multi-function pins as another .dts defines ESDHC1 as: esdhc@50004000 { /* ESDHC1 */ cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */ wp-gpios = <&gpio2 14 0>; /* GPIO3_14 */ status = "okay"; }; AFAIK, newbus is unable to model any of the above situation without being bypassed one way or another. any hints ? Thanks, - Arnaud [0]: as a matter of comparison, old PXA27x have up to 121 GPIOs From owner-freebsd-current@FreeBSD.ORG Thu Jul 5 23:59:42 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E33A71065670; Thu, 5 Jul 2012 23:59:42 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]) by mx1.freebsd.org (Postfix) with ESMTP id 9CC068FC0A; Thu, 5 Jul 2012 23:59:42 +0000 (UTC) Received: from meatwad.mouf.net (cpe-024-162-230-236.nc.res.rr.com [24.162.230.236]) (authenticated bits=0) by mouf.net (8.14.5/8.14.5) with ESMTP id q65Nxe3D029495 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 5 Jul 2012 19:59:41 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4FF62A6C.7090408@FreeBSD.org> Date: Thu, 05 Jul 2012 19:59:40 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120604 Thunderbird/12.0.1 MIME-Version: 1.0 To: alc@FreeBSD.org References: <7F5E65B1-24AF-4942-A273-093EBAE94B7D@FreeBSD.org> <168031EF-1CBD-4B14-A99E-D5C90B01111C@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 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.7 (mouf.net [204.109.58.86]); Thu, 05 Jul 2012 19:59:41 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.97.5 at mouf.net X-Virus-Status: Clean Cc: Alan Cox , current@FreeBSD.org Subject: Re: panic after starting X with r238120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jul 2012 23:59:43 -0000 On 07/05/12 03:00, Alan Cox wrote: > On Wed, Jul 4, 2012 at 4:57 PM, Steve Wills wrote: > >> Setting kern.ipc.shm_use_phys back to 0 (the default) fixed it. I had set >> it to 1 for some reason that I can't recall. >> >> > That shouldn't cause a crash in pmap_enter(). What is line 3587 of pmap.c > in your sources? 3587 if ((newpte & PG_RW) == 0) > You mentioned DRM. Are you using the new Intel graphics > driver? > No, I'm using ATI Radeon. Steve From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 03:04:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1647B106564A; Fri, 6 Jul 2012 03:04:25 +0000 (UTC) (envelope-from kaho@elam.kais.kyoto-u.ac.jp) Received: from elam.kais.kyoto-u.ac.jp (elam.kais.kyoto-u.ac.jp [130.54.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id A64D58FC15; Fri, 6 Jul 2012 03:04:24 +0000 (UTC) Received: from elam.kais.kyoto-u.ac.jp (localhost [127.0.0.1]) by elam.kais.kyoto-u.ac.jp (8.14.4/8.14.4) with ESMTP id q66347NE001163; Fri, 6 Jul 2012 12:04:07 +0900 (JST) (envelope-from kaho@elam.kais.kyoto-u.ac.jp) To: John Baldwin From: Kaho Toshikazu References: <201206301349.58930.erich@alogreentechnologies.com> <20120705083153.GA3020@tinyCurrent> <84818.1341480035@elam.kais.kyoto-u.ac.jp> <201207050739.18457.jhb@freebsd.org> X-Mailer: MH-E 8.0.3; MH 6.8.4.JP-3.05; GNU Emacs 22.3.1 User-Agent: EMH/1.14.1 SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?S?= =?ISO-8859-4?Q?hij=F2?=) APEL/10.7 Emacs/22.3 (i386-portbld-freebsd7.3) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Jul 2012 12:04:07 +0900 Message-ID: <1162.1341543847@elam.kais.kyoto-u.ac.jp> Sender: kaho@elam.kais.kyoto-u.ac.jp Cc: Matthias Apitz , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jul 2012 03:04:25 -0000 Hello John Baldwin, and all, John Baldwin wrote: > The system in general in 9.0 and later is more strict about honoring what the > BIOS says in terms of allocating resources, so we have to be more correct in > probing devices. The only wrinkles so far do in fact seem to stem from the > keyboard controller. I don't have any plans for treating unknown ID device's resources. Many keyboard PNP ID are listed on a file at the below URL, and FreeBSD doesn't know almost of them. http://download.microsoft.com/download/5/7/7/577a5684-8a83-43ae-9272-ff260a9c20e2/pnp_legacy.doc -- kaho@elam.kais.kyoto-u.ac.jp From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 05:04:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2022B1065670 for ; Fri, 6 Jul 2012 05:04:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DCE5C8FC08 for ; Fri, 6 Jul 2012 05:04:23 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so15015151pbb.13 for ; Thu, 05 Jul 2012 22:04:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=wYaNIKB4Ewj9Zc0rDwUVuMdsQXHv+eI1uu3urjZcR+o=; b=PUkf2qxxkXmEtBjqvIte3mJwr23cot6qyHg6SfByaGVOYQEbwD9Jsiu8zJ3Z3iIGvL levZ/XcJ2ris5VYa+d/eaQ0EIEh6lj3vTueFTiwPX8OLR/yxdbzLoL83t4uEwgMJtbwK wHzQwk4JE9Xx7MouLMD6oaqdAyygdabRlgfDN8W89hyISWHxDiU4sv4etuhwTE3BoNwU Xa9pzqSyfC8jD5qXiHzbceHUGunrh/6BiT4Zh+9UMCjjNtKv/7LKVPOT3GnxEp7Qi/H0 /uz/ME8cn6rLPjtP3QL4UZI9aXuilWYD5gJfGVfrNKC5ztl+BRJLAP02xNxjE4vM4Hbv NfgQ== Received: by 10.68.238.166 with SMTP id vl6mr33664171pbc.96.1341551063464; Thu, 05 Jul 2012 22:04:23 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id nh8sm21117559pbc.60.2012.07.05.22.04.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 22:04:23 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 5 Jul 2012 23:04:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmcgkFVlzYJ6Yp3vxSp1Sg4SxAvEIPWUtVBVVELN/PSR768D2n8ZGOIZHK6Acjqmc2VR+ey Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jul 2012 05:04:24 -0000 On Jul 5, 2012, at 5:14 PM, Arnaud Lacombe wrote: > Hi folks, >=20 > The problem has been raised in the last BSDCan during a talk, but no > clear answer has been given. Some (pseudo-)devices might require > resources from multiple other (pseudo-)devices. >=20 > For example, a device is sitting on an SMBus, but need to access a > software controlled LED, sitting on a GPIO bus, itself sitting on an > LPC bus... Or a variant where everything is controlled on the same > chip, but different GPIO banks. For that specific example, all the > GPIO pin could be implement on the same GPIObus, however, gpiobus(4) > is limited to 32 pins and the chip provides 5 banks of 8 pins, ie. a > total of 40 pins[0]. In the same idea, a device sitting on GPIOs > controlled by two independant chips, say one being an ICH10R chipset > on a PCI device function, and the other being a > SuperIO on an LPC bus. >=20 > This situation make me really dubious that FreeBSD will be able to > support configuration such as: >=20 > esdhc@50004000 { /* ESDHC1 */ > cd-gpios =3D <&gpio2 13 0>; /* GPIO3_13 */ > wp-gpios =3D <&gpio3 11 0>; /* GPIO4_11 */ > status =3D "okay"; > }; >=20 > or: >=20 > ecspi@50010000 { /* ECSPI1 */ > fsl,spi-num-chipselects =3D <2>; > cs-gpios =3D <&gpio1 30 0>, /* GPIO2_30 */ > <&gpio2 19 0>; /* GPIO3_19 */ > status =3D "okay"; > [...] >=20 > This example is taken from Linux' `arch/arm/boot/dts/imx53-smd.dts'. > Here, SDHC or SPI controller are using different GPIO devices. Note > that these GPIO pins does not seem to be multi-function pins as > another .dts defines ESDHC1 as: >=20 > esdhc@50004000 { /* ESDHC1 */ > cd-gpios =3D <&gpio2 13 0>; /* GPIO3_13 */ > wp-gpios =3D <&gpio2 14 0>; /* GPIO3_14 */ > status =3D "okay"; > }; >=20 > AFAIK, newbus is unable to model any of the above situation without > being bypassed one way or another. >=20 > any hints ? That's not correct. You don't need a parent-child relationship in = newbus to interact with another node in the tree. You can look up the = other node by name, and then call functions based on finding that other = device. Warner From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 05:08:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B6B4106566C; Fri, 6 Jul 2012 05:08:41 +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 02D0E8FC08; Fri, 6 Jul 2012 05:08:41 +0000 (UTC) Received: from [46.244.156.78] (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 1Sn0mV-0003cg-G6; Fri, 06 Jul 2012 07:08:39 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id q6658bAN002372; Fri, 6 Jul 2012 07:08:37 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id q6658bZW002371; Fri, 6 Jul 2012 07:08:37 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Fri, 6 Jul 2012 07:08:36 +0200 From: Matthias Apitz To: John Baldwin Message-ID: <20120706050836.GA2333@tinyCurrent> References: <201206301349.58930.erich@alogreentechnologies.com> <201207050739.18457.jhb@freebsd.org> <20120705202520.GA1637@tiny.Sisis.de> <201207051722.22269.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201207051722.22269.jhb@freebsd.org> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 46.244.156.78 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 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: Fri, 06 Jul 2012 05:08:41 -0000 El día Thursday, July 05, 2012 a las 05:22:22PM -0400, John Baldwin escribió: > So far I can't think of a non-hackish way to special case keyboard and > mouse controllers, though I'm close to doing so (i.e. just ignore any > device that tries to allocate resources in the "default" range for those > devices unless it is a "known" device ID). > > The patch in this thread should be committed though. And one should close this issue with this: http://www.freebsd.org/cgi/query-pr.cgi?pr=169571 thx for all your helping hands matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 11:06:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F4011065670 for ; Fri, 6 Jul 2012 11:06:10 +0000 (UTC) (envelope-from shigeru@iij.ad.jp) Received: from omgo.iij.ad.jp (mo00.iij.ad.jp [202.232.30.145]) by mx1.freebsd.org (Postfix) with ESMTP id DE0008FC18 for ; Fri, 6 Jul 2012 11:06:09 +0000 (UTC) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:In-Reply-To:References:Mime-Version:Content-Type: Content-Transfer-Encoding;i=shigeru@iij.ad.jp;s=omgo1;t=1341572642;x= 1342782242; bh=6MIeLrliuE9Cm3oZ//swH3BAnbNdunahS5Hcl22vSSg=; b=iFah1YQO5zpY8zRd HoxOAqfnMxzAy20QOLFkmLBmdD/hWhkVRpLg/TQpAN0riyVRfjkwjgquXXiW5sVIVZ6bM4AdBxrkd zdhdg2DJPAZQL/g/K3fuTuxal0AKjUW7XBhd47LzVH9NqEgnhtD5NBKWP4LY+Cyk9u9SE8AibpUtl w=; Received: by omgo.iij.ad.jp (mo00) id q66B416t008357; Fri, 6 Jul 2012 20:04:01 +0900 Date: Fri, 06 Jul 2012 20:03:56 +0900 (JST) Message-Id: <20120706.200356.2087640778621065954.shigeru@iij.ad.jp> To: freebsd-current@freebsd.org From: YAMAMOTO Shigeru In-Reply-To: <20120704.182104.533981338265444182.shigeru@iij.ad.jp> References: <20120704.182104.533981338265444182.shigeru@iij.ad.jp> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [panic] currnet(r238089) cause panic when using '/usr/sbin/amd' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jul 2012 11:06:10 -0000 Hi all, After my e-mail, some fixes for sys/amd64/amd64/pmapc. are commited. I try to update newest current (r238163) and I hove no trouble. My problem is fixed. Thanks, ------- YAMAMOTO Shigeru From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 15:07:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E368E106567E for ; Fri, 6 Jul 2012 15:07:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B768D8FC16 for ; Fri, 6 Jul 2012 15:07:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0F599B977; Fri, 6 Jul 2012 11:07:02 -0400 (EDT) From: John Baldwin To: Kaho Toshikazu Date: Fri, 6 Jul 2012 08:13:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201206301349.58930.erich@alogreentechnologies.com> <201207050739.18457.jhb@freebsd.org> <1162.1341543847@elam.kais.kyoto-u.ac.jp> In-Reply-To: <1162.1341543847@elam.kais.kyoto-u.ac.jp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207060813.39867.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 06 Jul 2012 11:07:02 -0400 (EDT) Cc: Matthias Apitz , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jul 2012 15:07:03 -0000 On Thursday, July 05, 2012 11:04:07 pm Kaho Toshikazu wrote: > Hello John Baldwin, and all, > > John Baldwin wrote: > > > The system in general in 9.0 and later is more strict about honoring what the > > BIOS says in terms of allocating resources, so we have to be more correct in > > probing devices. The only wrinkles so far do in fact seem to stem from the > > keyboard controller. > > I don't have any plans for treating unknown ID device's resources. > Many keyboard PNP ID are listed on a file at the below URL, > and FreeBSD doesn't know almost of them. Almost all systems use one of the IDs we do support as a _CID if not a _HID. In fact, in this case it likely seems to be a BIOS bug as it used the same value for the _CID and _HID. I suspect it is supposed to be using 0303 as its _CID. > http://download.microsoft.com/download/5/7/7/577a5684-8a83-43ae-9272-ff260a9c20e2/pnp_legacy.doc Note that 030B is listed as reserved in this table, and not a valid keyboard device. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 15:33:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B374F1065670; Fri, 6 Jul 2012 15:33:58 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 21CFE8FC16; Fri, 6 Jul 2012 15:33:57 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so9280543wgb.31 for ; Fri, 06 Jul 2012 08:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8tZs1+xnwWmNDwtHtKjhk12i2ML5kEFXMoj0IZm3wg0=; b=HwwzH8SmnTmWCDmdjvwJqfGq8ndPTahwSHrIU+NhUuspea0/guRgNMEVpxgm1qxCJE AwBBT9AuazYb6RGyIGjvkEwoe9NT/Q75hI6DapE9YR3Nho9c5LTGj9i9l7+O7+xhpaAB UHzx89QAUL7eheujbsv1hqDk4CY/4ll3K2V9a2mZUt4+/Z/g8OTb7i2vL9NHUKz3rvN4 vBmxiZMne/Pklb4QOYLgZNL73TgP34tFYoNot7m0LCC24ujmXwQRdTr5APkd26/zY3zn nf3ZC3YbCEIi/RR7PC8TFwGLlgOP28hGffRGwkKC1e7juIv6MSjS+qmbLwiBJBQHtHdD /Gog== MIME-Version: 1.0 Received: by 10.217.3.209 with SMTP id r59mr10001747wes.108.1341588836915; Fri, 06 Jul 2012 08:33:56 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Fri, 6 Jul 2012 08:33:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 11:33:56 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jul 2012 15:33:58 -0000 Hi, On Fri, Jul 6, 2012 at 1:04 AM, Warner Losh wrote: > > On Jul 5, 2012, at 5:14 PM, Arnaud Lacombe wrote: > >> Hi folks, >> >> The problem has been raised in the last BSDCan during a talk, but no >> clear answer has been given. Some (pseudo-)devices might require >> resources from multiple other (pseudo-)devices. >> >> For example, a device is sitting on an SMBus, but need to access a >> software controlled LED, sitting on a GPIO bus, itself sitting on an >> LPC bus... Or a variant where everything is controlled on the same >> chip, but different GPIO banks. For that specific example, all the >> GPIO pin could be implement on the same GPIObus, however, gpiobus(4) >> is limited to 32 pins and the chip provides 5 banks of 8 pins, ie. a >> total of 40 pins[0]. In the same idea, a device sitting on GPIOs >> controlled by two independant chips, say one being an ICH10R chipset >> on a PCI device function, and the other being a >> SuperIO on an LPC bus. >> >> This situation make me really dubious that FreeBSD will be able to >> support configuration such as: >> >> esdhc@50004000 { /* ESDHC1 */ >> cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */ >> wp-gpios = <&gpio3 11 0>; /* GPIO4_11 */ >> status = "okay"; >> }; >> >> or: >> >> ecspi@50010000 { /* ECSPI1 */ >> fsl,spi-num-chipselects = <2>; >> cs-gpios = <&gpio1 30 0>, /* GPIO2_30 */ >> <&gpio2 19 0>; /* GPIO3_19 */ >> status = "okay"; >> [...] >> >> This example is taken from Linux' `arch/arm/boot/dts/imx53-smd.dts'. >> Here, SDHC or SPI controller are using different GPIO devices. Note >> that these GPIO pins does not seem to be multi-function pins as >> another .dts defines ESDHC1 as: >> >> esdhc@50004000 { /* ESDHC1 */ >> cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */ >> wp-gpios = <&gpio2 14 0>; /* GPIO3_14 */ >> status = "okay"; >> }; >> >> AFAIK, newbus is unable to model any of the above situation without >> being bypassed one way or another. >> >> any hints ? > > That's not correct. You don't need a parent-child relationship in newbus to interact with another node in the tree. You can look up the other node by name, and then call functions based on finding that other device. > I assume you are talking about devclass_get_device()/device_find_child(). That's neither correct nor robust in a couple of way: 1) you have no guarantee a device unit will always give you the same resource. 2) there is no reference counting on the returned device. 3) there is no track record of the reference being given. About (1), lower unit devices can fails to attach[0], thus newly attached bus will now have a negative offset. About (2) and (3), referenced device (think KLD) might go away and the child will not be told. In this situation, I want the child to be detached prior to its parent. As such, looking up other node by name would fit in what I call "bypassing newbus purpose". I might just as well export a damn function pointer and make my life easier. What would be need is an interface where the child need to have a way to say "resources I need are not complete, tell me when a new device in devclass Z is attached that I can check if it fills my need", ala: - dev0 is probed - dev0 tells it is present, but need unavailable resource in devclass X and devclass Y - dev0 is marked as pending - dev1 is attached in devclass X - dev0 is asked if dev1 would suit it - dev0 answers negatively - dev2 is attached in devclass X - dev0 is asked if dev2 would suit it - dev0 answers positively - dev0 continues its probe, but still need unavailable resource in devclass Y - dev3 is attached in devclass Y - dev0 is asked if dev3 would suit it - dev0 answers positively - dev0 finishes its probe - dev0 is attached [...] - dev3 is to be detached - dev0 is detached - dev3 is detached - Arnaud [0]: for many reason; hardware failure, configuration change (think GPIO on multi-function pin) From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 18:46:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E19231065680; Fri, 6 Jul 2012 18:46:41 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC568FC19; Fri, 6 Jul 2012 18:46:41 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so9435838wgb.31 for ; Fri, 06 Jul 2012 11:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hOugMstE6M00znJMurQZau5r9ib46wX0MqbqNmTpjMY=; b=nAJrCql3tVgz5aqE2Riujt7ymqIBP2NlpvwrAnOT76de5S5q0Gj2eq63ocfdU0gWB2 0Ek3SgGU8vRdZy0rOg3vQOfREWhzhaGyXXGmyQ5DM+P5nKgr6hg8WPlAdbsYm43zRTli a/3IwvLrM7eTXC5//Z1k1XjTY8VccxadwjRvaCXDYNv3ATbr2nQX8xFZ5QkbX/jwNLCB kTsHfuWEbQZyEbcRC08PQFyRYJsHJ646pcNSQbFO0m1H/H9FkmdHLB+/Ou5x7xHO5+gt 5vuVOsxadcVmG2bOFXX2wDTA2kIcCrULP3Y5zp9ZPfWAXaNJEhdiKjJJardwkSrF05Ue hNTg== MIME-Version: 1.0 Received: by 10.180.98.69 with SMTP id eg5mr9941011wib.3.1341600400354; Fri, 06 Jul 2012 11:46:40 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Fri, 6 Jul 2012 11:46:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 14:46:40 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jul 2012 18:46:42 -0000 Hi, On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe wrote: > That's neither correct nor robust in a couple of way: > 1) you have no guarantee a device unit will always give you the same resource. this raises the following question: how can a device, today, figure out which parent in a given devclass would give it access to resources it needs. Say, you have gpiobus0 provided by a superio and gpiobus1 provided by the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 attachment is conditional to some BIOS setting. How can you tell gpioled(4) to attach on the chipset provided GPIO without hardcoding unit number either way ? AFAIK, you can not. Even hints provided layout description is defeated. Each device in a given devclass need to have a set of unique attribute to allow a child to distinguish it from other potential parent in the same devclass... - Arnaud From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 18:57:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34592106566B for ; Fri, 6 Jul 2012 18:57:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id D834C8FC0A for ; Fri, 6 Jul 2012 18:57:05 +0000 (UTC) Received: by ggnm2 with SMTP id m2so10377854ggn.13 for ; Fri, 06 Jul 2012 11:57:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MeqTKp1m1xMTqd2+L6pcWtzdaEHQpKliBPwU5XEEROE=; b=Ag8nQy9Th3Az19jM+rvxUSuzXZFR3+8sfV1yzhhPvWDZo54uabpr2B2mXDDRSkCWVT UJB9C0jLllbRDGJ6WB4W5I4VyPE+1EkE21651H3Y6hzIj6hM1rJZOsZzLDv+1fwD97EE LX3LPsRzr7bLomdOb2PfDu1ei9EZkzUk1TSe7k/KwjmVwFI+RziQaFTMMNyCQQRJWOQc s6687hanYFnxrMR44GDQs8PBL0B7RBk4wSntpAGdVUgYioBX8zgiA+NsYb0YBt5RLgOR enyv7wAMKJoUrNVdpCfRzdw9vfOG1uBsibXUpO25urlFva/ynOW9nT3mz4wxU3GDM3FK uoKQ== Received: by 10.60.22.5 with SMTP id z5mr32265106oee.2.1341601025048; Fri, 06 Jul 2012 11:57:05 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id tn8sm23723383obc.21.2012.07.06.11.57.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 11:57:04 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 6 Jul 2012 12:57:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlFn/FDuuKiaS6/5XMnWjfoZetYaGtkr1Tct+lGMFhQa+t9nA9cR1aYRmeYoP/z5t5K4xRt Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jul 2012 18:57:06 -0000 On Jul 6, 2012, at 12:46 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe = wrote: >> That's neither correct nor robust in a couple of way: >> 1) you have no guarantee a device unit will always give you the same = resource. > this raises the following question: how can a device, today, figure > out which parent in a given devclass would give it access to resources > it needs. >=20 > Say, you have gpiobus0 provided by a superio and gpiobus1 provided by > the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 > attachment is conditional to some BIOS setting. How can you tell > gpioled(4) to attach on the chipset provided GPIO without hardcoding > unit number either way ? >=20 > AFAIK, you can not. >=20 > Even hints provided layout description is defeated. Each device in a > given devclass need to have a set of unique attribute to allow a child > to distinguish it from other potential parent in the same devclass... hints can hard-wire the device to a given bus. This also can hard-wire = the unit number, which will be stable even if one of them fails to = attach. But since the FDT language provides a richer set of connections than is = possible with raw newbus, perhaps the solution to your problem should be = handled in the FDT domain where you can look up a device name and have = the FDT layer do the proper mapping into newbus rather than trying to = guess at unit numbers. The reference count problem would still be there, but that's a different = issue that we have all over the place and need to solve before we can = properly lock NEWBUS. Warner From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 19:10:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 842231065670 for ; Fri, 6 Jul 2012 19:10:20 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 63BCF8FC16 for ; Fri, 6 Jul 2012 19:10:20 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta03.emeryville.ca.mail.comcast.net with comcast id X6Hf1j0061wfjNsA379E81; Fri, 06 Jul 2012 19:09:14 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta23.emeryville.ca.mail.comcast.net with comcast id X79C1j00c4NgCEG8j79DN0; Fri, 06 Jul 2012 19:09:13 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q66J9BUD008889; Fri, 6 Jul 2012 13:09:11 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Arnaud Lacombe In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Jul 2012 13:09:11 -0600 Message-ID: <1341601751.70246.7.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jul 2012 19:10:20 -0000 On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: > Hi, > > On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe wrote: > > That's neither correct nor robust in a couple of way: > > 1) you have no guarantee a device unit will always give you the same resource. > this raises the following question: how can a device, today, figure > out which parent in a given devclass would give it access to resources > it needs. > > Say, you have gpiobus0 provided by a superio and gpiobus1 provided by > the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 > attachment is conditional to some BIOS setting. How can you tell > gpioled(4) to attach on the chipset provided GPIO without hardcoding > unit number either way ? > > AFAIK, you can not. > > Even hints provided layout description is defeated. Each device in a > given devclass need to have a set of unique attribute to allow a child > to distinguish it from other potential parent in the same devclass... > > - Arnaud Talking about a child being unable to choose the correct parent seems to indicate that this whole problem is turned upside-down somehow; children don't choose their parents. Just blue-sky dreaming here on the fly... what we really have is a resource-management problem. A device comes along that needs a GPIO resource, how does it find and use that resource? Well, we have a resource manager, could that help somehow? Could a driver that provides access to GPIO somehow register its availability so that another driver can find and access it? The "resource" may be a callable interface, it doesn't really matter, I'm just wondering if the current rman stuff could be leveraged to help make the connection between unrelated devices. I think that implies that there would have to be something near the root of the hiearchy willing to be the owner/manager of dynamic resources. -- Ian From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 20:46:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4174E106566B; Fri, 6 Jul 2012 20:46:03 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 960758FC08; Fri, 6 Jul 2012 20:46:02 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so9517061wgb.31 for ; Fri, 06 Jul 2012 13:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QAYZapSJexHMMVubfb7Go0srs3GpVg9RSlurht4Qmhc=; b=rcATSVVSqkcQXA3GPU1tUSYXULmmzJ8miq20NAk1Q1sxRHPE9oIHUmyK84dSU5RD1n Ymlhuc8xHNq8DA/qxj8RNXYSjxPC7N5u27PzIK/H7FZJiuDTJ0A4H39BadIs/SstTxjy 3mCqPyBHGhhsL5884czXJadLBnLw0lbk621ctVUJCeI1VbYF/9wZaxZ6PK6420gLGV2j A7o4nDfIJ5qitd4456mB83UBO8U4Y9Al9t1tDVlhFDFuk3FidXrmi4raQYuraM0IRI8T iE5zJT+4yJndkR3vzysotsIofo5P5w85qRKXuFm4q8mZK9BuKx3CbjUbJmWojWqsXY0z fMsQ== MIME-Version: 1.0 Received: by 10.181.13.142 with SMTP id ey14mr10401225wid.19.1341607555784; Fri, 06 Jul 2012 13:45:55 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Fri, 6 Jul 2012 13:45:55 -0700 (PDT) In-Reply-To: <1341601751.70246.7.camel@revolution.hippie.lan> References: <1341601751.70246.7.camel@revolution.hippie.lan> Date: Fri, 6 Jul 2012 16:45:55 -0400 Message-ID: From: Arnaud Lacombe To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jul 2012 20:46:03 -0000 Hi, On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore wrote: > On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe wrote: >> > That's neither correct nor robust in a couple of way: >> > 1) you have no guarantee a device unit will always give you the same resource. >> this raises the following question: how can a device, today, figure >> out which parent in a given devclass would give it access to resources >> it needs. >> >> Say, you have gpiobus0 provided by a superio and gpiobus1 provided by >> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 >> attachment is conditional to some BIOS setting. How can you tell >> gpioled(4) to attach on the chipset provided GPIO without hardcoding >> unit number either way ? >> >> AFAIK, you can not. >> >> Even hints provided layout description is defeated. Each device in a >> given devclass need to have a set of unique attribute to allow a child >> to distinguish it from other potential parent in the same devclass... >> >> - Arnaud > > Talking about a child being unable to choose the correct parent seems to > indicate that this whole problem is turned upside-down somehow; children > don't choose their parents. > actually, I think I was wrong, I thought device were attached to a devclass, but they are truly attached to a given device. My mistake. > Just blue-sky dreaming here on the fly... what we really have is a > resource-management problem. A device comes along that needs a GPIO > resource, how does it find and use that resource? > > Well, we have a resource manager, could that help somehow? Could a > driver that provides access to GPIO somehow register its availability so > that another driver can find and access it? The "resource" may be a > callable interface, it doesn't really matter, I'm just wondering if the > current rman stuff could be leveraged to help make the connection > between unrelated devices. I think that implies that there would have > to be something near the root of the hiearchy willing to be the > owner/manager of dynamic resources. > AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. The more I think about it, the more FTD is the answer. The open question now being "how to map a flexible device structure (FTD) to a less flexible structure (Newbus)" :/ - Arnaud From owner-freebsd-current@FreeBSD.ORG Fri Jul 6 23:26:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFEAA106564A; Fri, 6 Jul 2012 23:26:06 +0000 (UTC) (envelope-from kaho@elam.kais.kyoto-u.ac.jp) Received: from elam.kais.kyoto-u.ac.jp (elam.kais.kyoto-u.ac.jp [130.54.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id 5AC0A8FC0C; Fri, 6 Jul 2012 23:26:06 +0000 (UTC) Received: from elam.kais.kyoto-u.ac.jp (localhost [127.0.0.1]) by elam.kais.kyoto-u.ac.jp (8.14.4/8.14.4) with ESMTP id q66NPt16014214; Sat, 7 Jul 2012 08:25:55 +0900 (JST) (envelope-from kaho@elam.kais.kyoto-u.ac.jp) To: John Baldwin From: Kaho Toshikazu In-reply-to: Your message of "Fri, 06 Jul 2012 08:13:39 -0400" References: <201206301349.58930.erich@alogreentechnologies.com> <201207050739.18457.jhb@freebsd.org> <1162.1341543847@elam.kais.kyoto-u.ac.jp> <201207060813.39867.jhb@freebsd.org> X-Mailer: MH-E 8.0.3; MH 6.8.4.JP-3.05; GNU Emacs 22.3.1 User-Agent: EMH/1.14.1 SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?S?= =?ISO-8859-4?Q?hij=F2?=) APEL/10.7 Emacs/22.3 (i386-portbld-freebsd7.3) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Date: Sat, 07 Jul 2012 08:25:55 +0900 Message-ID: <14213.1341617155@elam.kais.kyoto-u.ac.jp> Sender: kaho@elam.kais.kyoto-u.ac.jp Cc: Matthias Apitz , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jul 2012 23:26:06 -0000 Hello, John Baldwin wrote: > Almost all systems use one of the IDs we do support as a _CID if not a _HID. > In fact, in this case it likely seems to be a BIOS bug as it used the same > value for the _CID and _HID. I suspect it is supposed to be using 0303 as its > _CID. I don't think the BIOS should say PNP0303 as a keyboard _CID. Using _CID may help some systems, but it may not be helpful for many systems having keyboard probe problem. I think it's a specification bug made by Microsoft, same devices connected different type devices should not have different ID but same ID. > > http://download.microsoft.com/download/5/7/7/577a5684-8a83-43ae-9272-ff260a9c20e2/pnp_legacy.doc > > Note that 030B is listed as reserved in this table, and not a valid keyboard > device. Yes, it's a invalid type, but reserved as a keyborad. I don't know why the BIOS builder puts PNP030B as a keyboard, but it seems to be not a bug. People with this problem can override AML code, but I don't think it is a bad idea adding other IDs to the list for probing. -- kaho@elam.kais.kyoto-u.ac.jp From owner-freebsd-current@FreeBSD.ORG Sat Jul 7 05:53:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D906B106566B; Sat, 7 Jul 2012 05:53:49 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8B6388FC0A; Sat, 7 Jul 2012 05:53:49 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SnNxe-0002Ha-Mr>; Sat, 07 Jul 2012 07:53:42 +0200 Received: from e178003016.adsl.alicedsl.de ([85.178.3.16] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SnNxe-00088s-GW>; Sat, 07 Jul 2012 07:53:42 +0200 Message-ID: <4FF7CEDE.1060202@zedat.fu-berlin.de> Date: Sat, 07 Jul 2012 07:53:34 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Baldwin References: <4FF28682.9020705@zedat.fu-berlin.de> <201207051727.59295.jhb@freebsd.org> <4FF61370.4000200@zedat.fu-berlin.de> In-Reply-To: <4FF61370.4000200@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig55C6373CF2C44A2A9DECA63C" X-Originating-IP: 85.178.3.16 Cc: freebsd-current@freebsd.org Subject: Re: 10.0-CURRENT: kernel: Fatal trap 12: page fault while in kernel 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: Sat, 07 Jul 2012 05:53:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig55C6373CF2C44A2A9DECA63C Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 07/06/12 00:21, O. Hartmann wrote: > On 07/05/12 23:27, John Baldwin wrote: >> On Tuesday, July 03, 2012 1:43:30 am O. Hartmann wrote: >>> The most recent build of FreeBSD 10.0-CURRENT crashes on one of our >>> boxes with recent Intel hardware, see dmesg extract below. FreeBSD do= es >>> obviously only crash on hardware with modern "Sandy-Bridge" hardware,= >>> the very same kernel config and a very similar setup does work very w= ell >>> on an older Intel Core2Dua architecture. >>> >>> Machine in question runs an older kernel (set via nextboot -k >>> kernel.old) very well: >>> FreeBSD 10.0-CURRENT #0 r237697: Thu Jun 28 11:45:08 CEST 2012 >>> >>> Most recent buildworls/kernels crash after going into multiuser mode >>> (/etc/rc-scripts getting executed). Below the kernel trap message. >>> >>> I do this report on the fly, so if there is need for deeper >>> investigations let me know, I will provide necessary detail requested= =2E >> >> We would need a stack trace to debug this further. Do you have a cras= hdump? >> >=20 > Well, I built a GENERIC kernel and bootet that, it also crashes, but I > didn't find any coredump (as found in the crashes with the custom > kernel). I was able to do a backtrace with the GENERIC kernel, but > incapable of saving the trace - I did this in a rush, sorry. >=20 > I went back, just on a hunch, to FreeBSD 10.0-CURRENT #1 r237000, which= > works, but this isn't the last working revision. >=20 > I will look tomorrow for how to generate a dump or backtrace and save > that somehow (if available in the handbook). Otherwise, if not not much= > efford, I would appreciate any hint (for the impatient) how to generate= > suiatbel debug informations. >=20 > Regards, > Oliver >=20 Yesterday, I made a buildworld with the most recent sources and the system is now running well and shiny with FreeBSD 10.0-CURRENT #0 r238164: Fri Jul 6 15:07:59 CEST 201 (amd64) I saw a lot of pmap.h stuff being changed for amd64 last days. If it would be of interest, I can go back in the source's revision and build again a faulty kernel. Regards, Oliver --------------enig55C6373CF2C44A2A9DECA63C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJP987mAAoJEOgBcD7A/5N8KGsH/0njlAcGKQgEdNqVo3nHzAN3 LLwZUibq8fdNpjt2WR1p7z5o9BTIlQkvOhpeTE4R/XMz+J54LaLKzR7E4cXC3ADZ 8DI5PlVqh5cSAE9IjQx1ek1SmZkOztyox+n1WMYKNdU3Qux3VV7O9dIgfkDX5Qi+ sfZdSj+TVTg8Rf7TUR2nsKtRzGy1YbARX4PZT4wcmPd7q44X/Mq94udgvwjoEIO2 FpXMYPegt1kgtfOOTi1aL1gZ07m2goTkLY/G/O+ES9TYaMhzMSv0e+NJgedTQhRy sdLTWuL/9/0Ys1eL+pK+taXfUEEhnUOBy0ZLv9CAagmuTQ+pe0p2jFVAyWWiqeI= =a+vl -----END PGP SIGNATURE----- --------------enig55C6373CF2C44A2A9DECA63C-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 7 09:41:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 549C0106564A for ; Sat, 7 Jul 2012 09:41:43 +0000 (UTC) (envelope-from lukasz.wojcik@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.103]) by mx1.freebsd.org (Postfix) with ESMTP id 30A108FC0A for ; Sat, 7 Jul 2012 09:41:43 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type; b=qwc+mxrybfV8ky3xTKKVr+NIr8eitP/Ic9y+S7qlmbgzpa2kd/ItXkx6Hh4DVpaf8LUP1cQ2oZYo zT+I2IZdTf16tMlBRMpC+WhFV+d8ZNPrg5om0Gk40Iqt72AI+C/b Received: from [192.168.100.103] (46.174.212.99 [46.174.212.99]) by mx.zohomail.com with SMTPS id 1341650894441999.1730511452198; Sat, 7 Jul 2012 01:48:14 -0700 (PDT) Message-ID: <4FF7F784.9090701@zoho.com> Date: Sat, 07 Jul 2012 10:47:00 +0200 From: Lukasz Wojcik User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Arnaud Lacombe References: <1341601751.70246.7.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-Mailman-Approved-At: Sat, 07 Jul 2012 12:09:43 +0000 Cc: Ian Lepore , FreeBSD Current , FreeBSD Hackers Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Jul 2012 09:41:43 -0000 On 07/06/12 22:45, Arnaud Lacombe wrote: > Hi, > > On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore > wrote: >> On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe wrote: >>>> That's neither correct nor robust in a couple of way: >>>> 1) you have no guarantee a device unit will always give you the same resource. >>> this raises the following question: how can a device, today, figure >>> out which parent in a given devclass would give it access to resources >>> it needs. >>> >>> Say, you have gpiobus0 provided by a superio and gpiobus1 provided by >>> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 >>> attachment is conditional to some BIOS setting. How can you tell >>> gpioled(4) to attach on the chipset provided GPIO without hardcoding >>> unit number either way ? >>> >>> AFAIK, you can not. >>> >>> Even hints provided layout description is defeated. Each device in a >>> given devclass need to have a set of unique attribute to allow a child >>> to distinguish it from other potential parent in the same devclass... >>> >>> - Arnaud >> >> Talking about a child being unable to choose the correct parent seems to >> indicate that this whole problem is turned upside-down somehow; children >> don't choose their parents. >> I am unsure whether I understand the problem completely, but.. > actually, I think I was wrong, I thought device were attached to a > devclass, but they are truly attached to a given device. My mistake. > >> Just blue-sky dreaming here on the fly... what we really have is a >> resource-management problem. A device comes along that needs a GPIO >> resource, how does it find and use that resource? >> >> Well, we have a resource manager, could that help somehow? Could a >> driver that provides access to GPIO somehow register its availability so >> that another driver can find and access it? The "resource" may be a >> callable interface, it doesn't really matter, I'm just wondering if the >> current rman stuff could be leveraged to help make the connection >> between unrelated devices. I think that implies that there would have >> to be something near the root of the hiearchy willing to be the >> owner/manager of dynamic resources. >> I agree, that on a very abstract level, this is exactly how this should work. In my opinion, what we need here is: a) A way for a driver to locate the resource it needs. That can be done using FDT facility. If the driver knows, that it needs certain resource (like memory, gpio or whatever else), it could process DTB (using OF_*) looking up the node holding that resource. b) Knowing the node (phandle or name), OS could locate appropriate device_t (or even driver) in the tree-hierarchy created by fdtbus (e.g. by iterating by every device_t in the tree). Each device_t created by fdtbus (or simplebus) does keep the information about the DTS (or DTB) node name via ivars. So iterating through device_t-s, we could compare node names hold in ivars with the name of the node for needed resource, and thus find proper device_t. I think this is not currently possible. Note, that other way around -- getting node's phandle based on device_t *is* implemented via ofwbus(fdtbus_ofw_get_node()). I think if this is really needed, ofwbus(fdtbus) could be easily extended by adding a routine like fdtbus_ofw_get_device_for_node(). -LW > AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. > The more I think about it, the more FTD is the answer. The open > question now being "how to map a flexible device structure (FTD) to a > less flexible structure (Newbus)" :/ > > - Arnaud > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- From owner-freebsd-current@FreeBSD.ORG Sat Jul 7 12:08:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70ADE1065673 for ; Sat, 7 Jul 2012 12:08:20 +0000 (UTC) (envelope-from ruM1cRO@yandex.ru) Received: from forward14.mail.yandex.net (forward14.mail.yandex.net [IPv6:2a02:6b8:0:801::4]) by mx1.freebsd.org (Postfix) with ESMTP id DAB008FC08 for ; Sat, 7 Jul 2012 12:08:19 +0000 (UTC) Received: from web8f.yandex.ru (web8f.yandex.ru [95.108.130.105]) by forward14.mail.yandex.net (Yandex) with ESMTP id 8037D198134F for ; Sat, 7 Jul 2012 16:08:18 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341662898; bh=jAeku1AMJ5lE6GzBtpZMkqqDUdt4muc4OeyrX590j0c=; h=From:To:Subject:MIME-Version:Message-Id:Date:Content-Type; b=KUBb0qfLHOj54yovWcYrQFA9jMyVF9Vy8p59DBiOWAGLKKh5R72f07UxfO/m7BO0t lTb9O+g943LdvM/wWUL0HOjjiGEYBI9l3QXm75CWEGTmmL4bP/kqwUXmz0RlAUM6Y4 GwAMABaG3oSii3j8NyLmVFZbJ4TjaIJZj7FbLOE8= Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web8f.yandex.ru (Yandex) with ESMTP id 4C26B5290037; Sat, 7 Jul 2012 16:08:18 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341662898; bh=jAeku1AMJ5lE6GzBtpZMkqqDUdt4muc4OeyrX590j0c=; h=From:To:Subject:MIME-Version:Message-Id:Date:Content-Type; b=KUBb0qfLHOj54yovWcYrQFA9jMyVF9Vy8p59DBiOWAGLKKh5R72f07UxfO/m7BO0t lTb9O+g943LdvM/wWUL0HOjjiGEYBI9l3QXm75CWEGTmmL4bP/kqwUXmz0RlAUM6Y4 GwAMABaG3oSii3j8NyLmVFZbJ4TjaIJZj7FbLOE8= Received: from 95-24-196-236.broadband.corbina.ru (95-24-196-236.broadband.corbina.ru [95.24.196.236]) by web8f.yandex.ru with HTTP; Sat, 07 Jul 2012 16:08:18 +0400 From: Ilya A. Arkhipov To: freebsd-current@freebsd.org MIME-Version: 1.0 Message-Id: <782661341662898@web8f.yandex.ru> Date: Sat, 07 Jul 2012 16:08:18 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Type: multipart/mixed; boundary="----==--bound.78267.web8f.yandex.ru" X-Mailman-Approved-At: Sat, 07 Jul 2012 12:10:28 +0000 Subject: R flag in newsyslog works incorrect X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Jul 2012 12:08:20 -0000 ------==--bound.78267.web8f.yandex.ru Content-Transfer-Encoding: 7bit Content-Type: text/plain Hi All, Looks as R flag with archiving works incorrect, for example: root@mhome:/tmp/test# less nsl.cfg /tmp/test/test.log micro:wheel 640 20 10 * BZR /tmp/test/test.sh root@mhome:/tmp/test# less test.sh echo atata root@mhome:/tmp/test# newsyslog -vF -f nsl.cfg Processing nsl.cfg /tmp/test/test.log <20Z>: size (Kb): 1 [10] --> trimming log.... Signal all daemon process(es)... Run command: /tmp/test/test.sh 1 atata Pause 10 seconds to allow daemon(s) to close log file(s) Compress all rotated log file(s)... newsyslog: log /tmp/test/test.log.0 not compressed because daemon(s) not notified http://micro.heavennet.ru/patch/newsyslog.patch fix it. root@mhome:/tmp/test# newsyslog -vF -f nsl.cfg Processing nsl.cfg /tmp/test/test.log <20Z>: size (Kb): 68 [10] --> trimming log.... Signal all daemon process(es)... Run command: /tmp/test/test.sh 1 atata Pause 10 seconds to allow daemon(s) to close log file(s) Compress all rotated log file(s)... Could you please review and fix it. Thanks in advance! -- With Best Regards, Ilya A. Arkhipov ------==--bound.78267.web8f.yandex.ru Content-Disposition: attachment; filename="newsyslog.patch" Content-Transfer-Encoding: base64 Content-Type: text/plain; name="newsyslog.patch" LS0tIG5ld3N5c2xvZy5jX29sZAkyMDEyLTA3LTA3IDE0OjQ5OjQxLjUwMjEzNTYwOCArMDAwMAor KysgbmV3c3lzbG9nLmMJMjAxMi0wNy0wNyAxNDo0ODowOS40MjUxMzY5OTggKzAwMDAKQEAgLTE5 NzIsNyArMTk3Miw3IEBACiAJZWxzZQogCQlwZ21fbmFtZSsrOwogCi0JaWYgKHp3b3JrLT56d19z d29yayAhPSBOVUxMICYmIHp3b3JrLT56d19zd29yay0+c3dfcGlkb2sgPD0gMCkgeworCWlmICh6 d29yay0+endfc3dvcmsgIT0gTlVMTCAmJiB6d29yay0+endfc3dvcmstPnN3X3BpZG9rIDw9IDAg JiYgIXp3b3JrLT56d19zd29yay0+cnVuX2NtZCApIHsKIAkJd2FybngoCiAJCSAgICAibG9nICVz IG5vdCBjb21wcmVzc2VkIGJlY2F1c2UgZGFlbW9uKHMpIG5vdCBub3RpZmllZCIsCiAJCSAgICB6 d29yay0+endfZm5hbWUpOwo= ------==--bound.78267.web8f.yandex.ru-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 7 12:25:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8D43106566C; Sat, 7 Jul 2012 12:25:39 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 3E8308FC1B; Sat, 7 Jul 2012 12:25:39 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 13A0911D96F; Sat, 7 Jul 2012 12:25:38 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Sat, 7 Jul 2012 14:25:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Arnaud Lacombe X-Mailer: Apple Mail (2.1278) Cc: FreeBSD Hackers , FreeBSD Current , Warner Losh Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Jul 2012 12:25:39 -0000 Am 06.07.2012 um 17:33 schrieb Arnaud Lacombe: > I assume you are talking about = devclass_get_device()/device_find_child(). >=20 > That's neither correct nor robust in a couple of way: > 1) you have no guarantee a device unit will always give you the same = resource. > 2) there is no reference counting on the returned device. > 3) there is no track record of the reference being given. >=20 > About (1), lower unit devices can fails to attach[0], thus newly > attached bus will now have a negative offset. >=20 > About (2) and (3), referenced device (think KLD) might go away and the > child will not be told. In this situation, I want the child to be > detached prior to its parent. >=20 > As such, looking up other node by name would fit in what I call > "bypassing newbus purpose". I might just as well export a damn > function pointer and make my life easier. I believe there is one more thing that needs to be addressed, which I = ran into while trying to do the arge/mdio attachment: 4) the device attach method may require access to the other device to = complete the attachment, but that other might not be attached yet. Circular dependencies nonwithstanding, it would be highly desirable for = a device driver developer to be able to simply declare all prerequisites = for attachment, and have newbus call attach only after everything is = there. Right now, the drivers attach method is called by the parent bus = as soon as enumeration is completed. A notification mechanism (similar to the devfs notification but with an = exposed KPI) might be an alternative, as mentioned in this thread. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Jul 7 12:27:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93818106564A for ; Sat, 7 Jul 2012 12:27:02 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id E4F508FC12 for ; Sat, 7 Jul 2012 12:27:01 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q67CQxuh001266 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 7 Jul 2012 13:27:00 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FF82B13.8000906@unsane.co.uk> Date: Sat, 07 Jul 2012 13:26:59 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rick Macklem References: <497527423.2441665.1341141539082.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <497527423.2441665.1341141539082.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Jul 2012 12:27:02 -0000 On 01/07/2012 12:18, Rick Macklem wrote: > Vincent Hoffman wrote: >> On 01/07/2012 01:53, Rick Macklem wrote: >>> To modify mountd to use the kernel changes is more work than I have >>> time for, in part because mountd.c is a very ugly old piece of C >>> code, imho. >>> >>> I do have a patch that suspends/resumes execution of the nfsd >>> threads >>> (new, experimental for FreeBSD8.n only) when mountd reloads >>> /etc/exports. >>> This approach has certain disadvantages vs Andrey's transactional >>> load/commit >>> model, but it is simple and might be sufficient for your problem. >>> If you want to try this patch, it is at: >>> http://people.freebsd.org/~rmacklem/atomic-export.patch >>> (The patch affects both the kernel and mountd.c.) >> Happy to try it, to be certain I have understood, this is for the >> newnfs >> server (experimental in 8.x default for 8 >> 9+) > Yes, that is correct. For the old (default on 8.x) it will have no effect. > >> I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm when >> i >> get a minute. > Also, to enable it, you must add a "-S" flag to mountd_flags, after you've > replaced the mountd executable. > > The patch is pretty straightforward, but has not seen much testing. > Hopefully, it might be useful for you, rick Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt x nopatch.txt + atomicpatch.txt +--------------------------------------------------------------------------------------------------+ | * | | * | | x* | | xx* x | | +x** xx | | **** xxx x | | **** xxx +x+ + | | ****+*xx +x+ x + | | ****+*x****++++x + + x | | *************+*xx+ +++x * x x | | ****************x**++*x+***x+ x*+ x ++*+ + x+ +x + + +| |||_______M_M_A__A_______|______| | +--------------------------------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 101 1.25 106.8 14.08 21.892178 22.196005 + 101 1.21 186.93 18.46 27.995842 30.523218 No difference proven at 95.0% confidence (excuse wrapped ascii art) I think I'll have a look at the nfse patch set and see how that performs. Thanks for all your work on NFS on FreeBSD. Vince > >>> Also, you could easily hack mount.c so that it doesn't send a SIGHUP >>> to mountd (which causes the exports to be reloaded) every time a >>> local >>> fs is mounted. >> True and I may have to do that for the production NAS for the time >> being. >> Thanks for looking at this. >> >> Vince >>> rick >>> >>>>> thanks, Vince From owner-freebsd-current@FreeBSD.ORG Sat Jul 7 12:34:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B3EF106566C; Sat, 7 Jul 2012 12:34:43 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id D4E468FC12; Sat, 7 Jul 2012 12:34:42 +0000 (UTC) Received: from mr16.lnh.mail.rcn.net ([207.172.157.36]) by smtp02.lnh.mail.rcn.net with ESMTP; 07 Jul 2012 08:34:42 -0400 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr16.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id BVR65451; Sat, 7 Jul 2012 08:34:41 -0400 Received: from 209-6-86-84.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.86.84]) by smtp04.lnh.mail.rcn.net with ESMTP; 07 Jul 2012 08:34:42 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20472.11489.7749.213672@jerusalem.litteratus.org> Date: Sat, 7 Jul 2012 08:34:41 -0400 To: Doug Barton In-Reply-To: <4FF4B427.1010808@FreeBSD.org> References: <4FF4B427.1010808@FreeBSD.org> X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr16.lnh.mail.rcn.net) Cc: Sayetsky Anton , Baptiste Daroussin , FreeBSD Current , "Hartmann, O." , bug-followup@FreeBSD.org Subject: Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Jul 2012 12:34:43 -0000 Doug Barton writes: > > /me officially gives up with that libreoffice port, open for > > new volunteers > > If you don't have time to work on the port, then don't, that's > not a problem. But throwing a hissy fit here doesn't help at all. Cut tha man some slack. As far as I can tell, he's been point - and often _only_ - person wrangling the herd of 250 pound cats that is LibreOffice (and posibly OpenOffice before that). At this he has done a superior job. However, there has recently been {subtle, tenacious} breakage that a) is not his fault, b) he's gotten a lot of complaints about from people who don't understand what's involved (you're not on that list), even though c) he's been working hard to find and fix the problem. If he wants a moment to vent, and maybe ask "is this worth it?" ... he's earned it. Robert Huff From owner-freebsd-current@FreeBSD.ORG Sat Jul 7 16:02:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B600E1065672 for ; Sat, 7 Jul 2012 16:02:19 +0000 (UTC) (envelope-from imp@bsdimp.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 64A838FC20 for ; Sat, 7 Jul 2012 16:02:19 +0000 (UTC) Received: by yhfs35 with SMTP id s35so4545825yhf.13 for ; Sat, 07 Jul 2012 09:02:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=R9TJmdrqpWp3aCYDP2Jc3EeCP62DFixE8mu0TeykeNA=; b=XEsCdlXYY51db8lV3VyRVeKHa8vPI9gsa7eP7s1xVark4wUsAUcIaPnNx7jHz2JHrK 4AzK6zejYAddOhE7apFfKcufjFxepTDOQquFuAbbcuZ7wVD8ifo+juSYQefqRP0f0XYP DpTPvwLAmXhR6+8cQHO6Bi1HsnM1YNZGD7G6YjH573tBDrDylQTNxD07S/368hoZi6Wb wZVwYguOwuelYyEQEiwDeLRZraoBib4Q46fy0NaxYRTdeQfcsQfRDgxe/EIfBkE8wiLF M3OyxbNJZ/B40FQKz0pcTmrhWziXNwwSmrAYsfZr8EXwVzUXiHtLK711yXwzbONVLu05 zNYA== Received: by 10.50.219.136 with SMTP id po8mr4722277igc.70.1341676938639; Sat, 07 Jul 2012 09:02:18 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id s4sm4953838igb.1.2012.07.07.09.02.17 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Jul 2012 09:02:18 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 7 Jul 2012 10:02:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7AAA45BE-520B-4753-823E-D17D1AB0A5E0@bsdimp.com> References: To: Stefan Bethke X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkYlOWcEZAjsZVaxLxLohhon/2zXixGMxlhoZDdkd019+kE1jpS6GhlTEVRt4Qju3pVUaJN Cc: FreeBSD Hackers , FreeBSD Current , Arnaud Lacombe Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Jul 2012 16:02:19 -0000 On Jul 7, 2012, at 6:25 AM, Stefan Bethke wrote: > Am 06.07.2012 um 17:33 schrieb Arnaud Lacombe: >=20 >> I assume you are talking about = devclass_get_device()/device_find_child(). >>=20 >> That's neither correct nor robust in a couple of way: >> 1) you have no guarantee a device unit will always give you the same = resource. >> 2) there is no reference counting on the returned device. >> 3) there is no track record of the reference being given. >>=20 >> About (1), lower unit devices can fails to attach[0], thus newly >> attached bus will now have a negative offset. >>=20 >> About (2) and (3), referenced device (think KLD) might go away and = the >> child will not be told. In this situation, I want the child to be >> detached prior to its parent. >>=20 >> As such, looking up other node by name would fit in what I call >> "bypassing newbus purpose". I might just as well export a damn >> function pointer and make my life easier. >=20 > I believe there is one more thing that needs to be addressed, which I = ran into while trying to do the arge/mdio attachment: >=20 > 4) the device attach method may require access to the other device to = complete the attachment, but that other might not be attached yet. >=20 > Circular dependencies nonwithstanding, it would be highly desirable = for a device driver developer to be able to simply declare all = prerequisites for attachment, and have newbus call attach only after = everything is there. Right now, the drivers attach method is called by = the parent bus as soon as enumeration is completed. The device should go ahead and attach. When multiple devices need to = communicate with each other, they need to coordinate things. newbus is = a weak coordination mechanism. Stronger coordination mechanisms would = be FDT or ACPI which can tie known devices to a device_t rather than to = just a name. The device_t will be around even if that device is = attached and detached. > A notification mechanism (similar to the devfs notification but with = an exposed KPI) might be an alternative, as mentioned in this thread. This would also work. However, many of proposed uses for this seem = more and more to me to need a non-newbus mechanism to cope with. You'll = absolutely require the notification method since devices can detach at = any time. Circular dependencies are way too easy to create. In the Atmel work I'm doing and have done, there's devices that provide = services to other devices (mostly pin muxing and GPIO). I don't try to = get the GPIO device to attach first, but rather have routines that can = be called to accomplish these things. During the early boot, I have to = use the GPIO device to turn on pins so that I can even talk to things = like the MII bus of the internal NIC. While the GPIO devices have = device_t's to allocate resources and to create dev_t nodes, I don't = marshal everything through newbus. When I want to map a pin as an = interrupt source for the PHY chip, that call is made directly. When I = need to shut off a device's pin and instead drive it via the GPIO logic, = that's just a call. etc. Warner= From owner-freebsd-current@FreeBSD.ORG Sat Jul 7 16:17:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6914B1065670 for ; Sat, 7 Jul 2012 16:17:04 +0000 (UTC) (envelope-from imp@bsdimp.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 1080D8FC16 for ; Sat, 7 Jul 2012 16:17:03 +0000 (UTC) Received: by yenl8 with SMTP id l8so10847736yen.13 for ; Sat, 07 Jul 2012 09:17:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Lc+g/Opi0Ip7hD9PsWczrOW19lpvV+q7hAhwVfaSRmo=; b=PyUi5rtvQ4hZgYPzyZs/3htH6ivGH/pQSdeLIh7x/4I18Aptb4k6EvhaofyGEuHyEa L3llzNrSDxhZ4VqnhgNREdXEKlQ+vBPFDG4p46shPIeOs5xFUObk0Im+/YYLTrxzj+T6 Rdm4JrJmF1Jo8hTq0+2Md7YbexKLSC1V36Qk1/p4nDz+pYVW2ZFZ41NmG/jlStECPOQ6 7dC35w5DZQOezRuYx+1O5keXZl7pYmPvGqS8cYSR371R0T6mRqM97VKK0S6wL/0RYB8b gzW/7+QFAs5v7in3CPhzYYkzWbpfGw8UpYlN3+Q+StSdKBhiKZYC54obeXMOYUQkVzso WSRw== Received: by 10.50.212.66 with SMTP id ni2mr4768026igc.66.1341677823235; Sat, 07 Jul 2012 09:17:03 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id nh1sm4966628igc.11.2012.07.07.09.17.02 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Jul 2012 09:17:02 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1341601751.70246.7.camel@revolution.hippie.lan> Date: Sat, 7 Jul 2012 10:17:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9855720B-9965-4A3B-B106-0A25EF3CA56F@bsdimp.com> References: <1341601751.70246.7.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlISv2QO6MPUn27AQAaizBwSe4keKGwWMDEA6bZo/Futm9K37w/q6famF4FSOY1XzuKZ3MC Cc: FreeBSD Hackers , FreeBSD Current , Arnaud Lacombe Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Jul 2012 16:17:04 -0000 On Jul 6, 2012, at 1:09 PM, Ian Lepore wrote: > Just blue-sky dreaming here on the fly... what we really have is a > resource-management problem. A device comes along that needs a GPIO > resource, how does it find and use that resource? =20 I rather like that idea. The connection between devices is more like = meta-data needed to obtain the resources/services that other devices = provide. You really want to talk in those terms, rather than in newbus = attachments. The platform told me that pin AT91_PIOA_12 is my interrupt line. I'd = like to wire up an ISR to that please. The platform told me that pin AT91_PIOC_33 is the data pin for my two = wire bus. An error happened and to reset it I need to tell the pin = muxing service to take it off line. then I need to tell the GPIO = service I have to force it high, let it flow, and force it low. The platform told me that this NIC is connected to PHY 2 on miibus 3. = I'm the NIC driver and want to connect. I'm the USB subsystem. I'd like to know if one or two usb ports are = connected to the HUB. The hardware can't tell me, so the platform code = has to give me hints. If I allocate the pins for each of those two = ports I'll know. In some configurations, I can get both sets. In = others, I can only get one set. All of those problems could be solved with newbus kobj connections. Or = they could be solved by the platform and/or drivers registering = resources and services and the other drivers in the system using it. = Multipass would help a lot with that, since you could probe/attach all = the service providers first, then everybody else could talk the higher = level interfaces. Warner P.S. multipass could solve the dependency problem, but in kinda a poor = way... From owner-freebsd-current@FreeBSD.ORG Sat Jul 7 18:47:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC65B106564A for ; Sat, 7 Jul 2012 18:47:48 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id CAD088FC0C for ; Sat, 7 Jul 2012 18:47:48 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta03.emeryville.ca.mail.comcast.net with comcast id XWWv1j0080FhH24A3WnoSs; Sat, 07 Jul 2012 18:47:48 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta08.emeryville.ca.mail.comcast.net with comcast id XWnn1j00g4NgCEG8UWnnmC; Sat, 07 Jul 2012 18:47:48 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q67IljpF009886; Sat, 7 Jul 2012 12:47:45 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Arnaud Lacombe In-Reply-To: References: <1341601751.70246.7.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 07 Jul 2012 12:47:45 -0600 Message-ID: <1341686865.70246.22.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Jul 2012 18:47:49 -0000 On Fri, 2012-07-06 at 16:45 -0400, Arnaud Lacombe wrote: > Hi, > > On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore > wrote: > > On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: > >> Hi, > >> > >> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe wrote: > >> > That's neither correct nor robust in a couple of way: > >> > 1) you have no guarantee a device unit will always give you the same resource. > >> this raises the following question: how can a device, today, figure > >> out which parent in a given devclass would give it access to resources > >> it needs. > >> > >> Say, you have gpiobus0 provided by a superio and gpiobus1 provided by > >> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 > >> attachment is conditional to some BIOS setting. How can you tell > >> gpioled(4) to attach on the chipset provided GPIO without hardcoding > >> unit number either way ? > >> > >> AFAIK, you can not. > >> > >> Even hints provided layout description is defeated. Each device in a > >> given devclass need to have a set of unique attribute to allow a child > >> to distinguish it from other potential parent in the same devclass... > >> > >> - Arnaud > > > > Talking about a child being unable to choose the correct parent seems to > > indicate that this whole problem is turned upside-down somehow; children > > don't choose their parents. > > > actually, I think I was wrong, I thought device were attached to a > devclass, but they are truly attached to a given device. My mistake. > > > Just blue-sky dreaming here on the fly... what we really have is a > > resource-management problem. A device comes along that needs a GPIO > > resource, how does it find and use that resource? > > > > Well, we have a resource manager, could that help somehow? Could a > > driver that provides access to GPIO somehow register its availability so > > that another driver can find and access it? The "resource" may be a > > callable interface, it doesn't really matter, I'm just wondering if the > > current rman stuff could be leveraged to help make the connection > > between unrelated devices. I think that implies that there would have > > to be something near the root of the hiearchy willing to be the > > owner/manager of dynamic resources. > > > AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. > The more I think about it, the more FTD is the answer. The open > question now being "how to map a flexible device structure (FTD) to a > less flexible structure (Newbus)" :/ > > - Arnaud Memory- and IO-mapped regions and IRQs are the only current uses of rman (that I know of), but it was designed to be fairly agnostic about the resources it manages. It just works with ranges of values (that it really doesn't know how to interpret at all), leaving lots of room to define new types of things it can manage. The downside is that it's designed to be used hierarchically in the context of newbus, specifically to help parents manage the resources that they are able to provide to their children. Trying to use it in a way that allows devices which are hierarchically unrelated to allocate resources from each other may amount to a square-peg/round-hole situation. But the alternative is writing a new facility to allow registration and allocation of resources using some sort symbolic method of representing the resources such that the new manager doesn't have to know much about what it's managing. I think it would be better to find a way to reuse what we've already got if that's possible. I think we have two semi-related aspects to this problem... How do we symbolically represent the resources that drivers can provide to each other? (FDT may be the answer; I don't know much about it.) How do devices use that symbolic representation to locate the provider of the resource, and how is the sharing of those resources managed? -- Ian From owner-freebsd-current@FreeBSD.ORG Sat Jul 7 19:30:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 598CF106566C; Sat, 7 Jul 2012 19:30:59 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 101328FC16; Sat, 7 Jul 2012 19:30:59 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 327E210D8BF; Sat, 7 Jul 2012 21:30:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id noZiNr3VLF9B; Sat, 7 Jul 2012 21:30:56 +0200 (CEST) Received: from danger-mbp.local (adsl-dyn250.91-127-100.t-com.sk [91.127.100.250]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 1B9EA10D8B1; Sat, 7 Jul 2012 21:30:56 +0200 (CEST) Message-ID: <4FF88E80.9040205@FreeBSD.org> Date: Sat, 07 Jul 2012 21:31:12 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.29pre) Gecko/20120424 Lanikai/3.1.21pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: HEADSUP: Call for FreeBSD Status Reports - 2Q/2012 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Jul 2012 19:30:59 -0000 Dear all, I would like to remind you that the next round of status reports covering the second quarter of 2012 are due on July 15th, 2012. As this initiative is very popular among our users, I would like to ask you to submit your entry as soon as possible, so that we can compile the report in a timely fashion. Do not hesitate and write us a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you may consider interesting is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of how your submission might look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the previous reports are welcome too. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! Thanks. -- Kind regards Daniel Gerzo From owner-freebsd-current@FreeBSD.ORG Sat Jul 7 23:26:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB4D7106564A for ; Sat, 7 Jul 2012 23:26:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-scalar.mail.uoguelph.ca (esa-scalar.mail.uoguelph.ca [66.199.40.18]) by mx1.freebsd.org (Postfix) with ESMTP id 71C558FC18 for ; Sat, 7 Jul 2012 23:26:33 +0000 (UTC) Received: from zcs3.mail.uoguelph.ca (new.mail.uoguelph.ca [131.104.93.37]) by esa-scalar.mail.uoguelph.ca (8.14.1/8.14.1) with ESMTP id q67NQLrP032744; Sat, 7 Jul 2012 19:26:22 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E0AA5B4022; Sat, 7 Jul 2012 19:26:21 -0400 (EDT) Date: Sat, 7 Jul 2012 19:26:21 -0400 (EDT) From: Rick Macklem To: Vincent Hoffman Message-ID: <528064981.93665.1341703581872.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4FF82B13.8000906@unsane.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Jul 2012 23:26:33 -0000 Vincent Hoffman wrote: > On 01/07/2012 12:18, Rick Macklem wrote: > > Vincent Hoffman wrote: > >> On 01/07/2012 01:53, Rick Macklem wrote: > >>> To modify mountd to use the kernel changes is more work than I > >>> have > >>> time for, in part because mountd.c is a very ugly old piece of C > >>> code, imho. > >>> > >>> I do have a patch that suspends/resumes execution of the nfsd > >>> threads > >>> (new, experimental for FreeBSD8.n only) when mountd reloads > >>> /etc/exports. > >>> This approach has certain disadvantages vs Andrey's transactional > >>> load/commit > >>> model, but it is simple and might be sufficient for your problem. > >>> If you want to try this patch, it is at: > >>> http://people.freebsd.org/~rmacklem/atomic-export.patch > >>> (The patch affects both the kernel and mountd.c.) > >> Happy to try it, to be certain I have understood, this is for the > >> newnfs > >> server (experimental in 8.x default for 8 > >> 9+) > > Yes, that is correct. For the old (default on 8.x) it will have no > > effect. > > > >> I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm > >> when > >> i > >> get a minute. > > Also, to enable it, you must add a "-S" flag to mountd_flags, after > > you've > > replaced the mountd executable. > > > > The patch is pretty straightforward, but has not seen much testing. > > Hopefully, it might be useful for you, rick > > Hi Rick, > > I'm afraid this didnt make any real difference for me. > Since I couldnt test it on the live system I tried it on a test vm. > on the vm (nfs server) I set a looping mount/umount > while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; > done > > and on the client I set a loop of tars of large directorys to the nfs > mount running under time to see how well it survived. Then replicated > the test with the patch and without. > Just to confirm, you patched both the kernel and mountd and replaced both on the server? Also, I'm not sure how ZFS handles it's exports. I can't remember if you've tried an exported UFS volume. It might be something ZFS specific? rick > > [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt > x nopatch.txt > + atomicpatch.txt > +--------------------------------------------------------------------------------------------------+ > | > * > | > | > * > | > | > x* > | > | xx* > x > | > | +x** > xx > | > | **** xxx > x > | > | **** xxx +x+ > + > | > | ****+*xx +x+ x > + > | > | ****+*x****++++x + + > x | > | *************+*xx+ +++x * x > x | > | ****************x**++*x+***x+ x*+ x ++*+ + x+ +x + > + +| > |||_______M_M_A__A_______|______| > | > +--------------------------------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 101 1.25 106.8 14.08 21.892178 22.196005 > + 101 1.21 186.93 18.46 27.995842 30.523218 > No difference proven at 95.0% confidence > > > (excuse wrapped ascii art) > > I think I'll have a look at the nfse patch set and see how that > performs. > > Thanks for all your work on NFS on FreeBSD. > > Vince > > > > >>> Also, you could easily hack mount.c so that it doesn't send a > >>> SIGHUP > >>> to mountd (which causes the exports to be reloaded) every time a > >>> local > >>> fs is mounted. > >> True and I may have to do that for the production NAS for the time > >> being. > >> Thanks for looking at this. > >> > >> Vince > >>> rick > >>> > >>>>> thanks, Vince > > > _______________________________________________ > 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"