From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 00:22:47 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A930E7EC; Sun, 18 Jan 2015 00:22:47 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8772CE3A; Sun, 18 Jan 2015 00:22:47 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t0I0MkwS013629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Jan 2015 16:22:46 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t0I0MkSN013628; Sat, 17 Jan 2015 16:22:46 -0800 (PST) (envelope-from sgk) Date: Sat, 17 Jan 2015 16:22:46 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Re: who broke dtrace and buildworld? Message-ID: <20150118002246.GA13599@troutmask.apl.washington.edu> References: <20150117235447.GA13490@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20150117235447.GA13490@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: smh@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 00:22:47 -0000 On Sat, Jan 17, 2015 at 03:54:47PM -0800, Steve Kargl wrote: > % cd /usr/src > % svn update > Updating '.': > At revision 277307. > % make buildworld > .... >=20 > =3D=3D=3D> cddl/usr.sbin/dtrace (all) > cc -O2 -pipe -march=3Dcore2 -I/usr/src/cddl/usr.sbin/dtrace/../../../sy= s/cddl/compat/opensolaris -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/co= mpat/opensolaris/include -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/con= trib/opensolaris/head -I/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contri= b/opensolaris/lib/libdtrace/common -I/usr/src/cddl/usr.sbin/dtrace/../../.= =2E/cddl/contrib/opensolaris/lib/libproc/common -I/usr/src/cddl/usr.sbin/d= trace/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/usr= =2Esbin/dtrace/../../../sys/cddl/contrib/opensolaris/compat -DNEED_SOLARIS_= BOOLEAN -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointe= r-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unuse= d-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parenthes= es-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-swit= ch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -o= dtrace dtrace.o -ldtrace -ly -ll > -lproc -lctf -lelf -lz -lutil -lrtld_db -lpthread > /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_ids= tack_lookup' > /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_ido= ps_probe' > /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idh= ash_nextid' > /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idh= ash_create' > /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_idh= ash_lookup' > /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_ido= ps_type' > /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_ido= ps_thaw' > /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_ido= ps_args >=20 > Please fix. >=20 To fix the build, % svn revert -r 377300:377299 . --=20 Steve From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 00:23:51 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A44B919; Sun, 18 Jan 2015 00:23:51 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D2E7EE4D; Sun, 18 Jan 2015 00:23:50 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t0I0NoNx013645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Jan 2015 16:23:50 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t0I0NoYB013644; Sat, 17 Jan 2015 16:23:50 -0800 (PST) (envelope-from sgk) Date: Sat, 17 Jan 2015 16:23:50 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Re: who broke dtrace and buildworld? Message-ID: <20150118002350.GB13599@troutmask.apl.washington.edu> References: <20150117235447.GA13490@troutmask.apl.washington.edu> <20150118002246.GA13599@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150118002246.GA13599@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: smh@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 00:23:51 -0000 On Sat, Jan 17, 2015 at 04:22:46PM -0800, Steve Kargl wrote: > > To fix the build, > > % svn revert -r 377300:377299 . > s/revert/merge -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 01:10:08 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA258CF7; Sun, 18 Jan 2015 01:10:08 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E7201DB; Sun, 18 Jan 2015 01:10:08 +0000 (UTC) Received: by mail-ig0-f170.google.com with SMTP id l13so8784135iga.1; Sat, 17 Jan 2015 17:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UshXldheje9GOhXkQUCcBIZHiEubr7IbbCFHNmC5gNI=; b=H3XjPn7djxOFFWv03+xrkWgLDptjDC8endIh0PgzPWbGhLQoa//5/D+odQvXs1kOX3 ehk6EsllVoGQAqY7DR/kiiO/s5T98o6oKy/wI2WKQhCmRrnNJny3I1VQ19sESvnsaJQt +AyeqIUj7uXLV+i6XPQ8+BJMwte9gqZK35ozpPjnMGHBJyH/rHObwGE1Qj23TO9cMqMD yruif6QqJ4/IwJvMl8rkJvkf2VLkOYxdtVgAXZ24dzGX0xa3viv8EpUvbV+yA2nb0BqC GuXOJlcWPYXhAkGgGjXWj+TFIkNe7eOaX3FKWMp+9zFwDPXWy1u18tbSvNmnCS+z3Y/6 p5cQ== MIME-Version: 1.0 X-Received: by 10.107.164.16 with SMTP id n16mr25221689ioe.44.1421543404881; Sat, 17 Jan 2015 17:10:04 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.52.19 with HTTP; Sat, 17 Jan 2015 17:10:04 -0800 (PST) In-Reply-To: <54BA8336.4090807@fgznet.ch> References: <20150117151806.GE91189@rancor.immure.com> <54BA8336.4090807@fgznet.ch> Date: Sat, 17 Jan 2015 17:10:04 -0800 X-Google-Sender-Auth: vv2IKt_6Yr1S_j_S7K7cUIENYBU Message-ID: Subject: Re: CURRENT breaks loading of nvidia.so From: Kevin Oberman To: Andreas Tobler Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Ports , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 01:10:09 -0000 On Sat, Jan 17, 2015 at 7:43 AM, Andreas Tobler wrote: > On 17.01.15 16:18, Bob Willcox wrote: > >> Yesterday when I upgraded my current box I encountered this failure when >> attempting to load the nvidia-driver (nvidia.so): >> >> link_elf_obj: symbol _callout_stop_safe undefined >> linker_load_file: Unsupported file type >> >> So, today I updtated my system again today hoping it might be fixed but >> the >> problem persists. >> >> System info: >> >> FreeBSD han.immure.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r277299: Sat >> Jan 17 08:52:41 CST 2015 bob@han.immure.com:/usr/obj/usr/src/sys/HAN >> amd64 >> > > I think you have to rebuild the nvidia-driver against your fresh built > system. At least I had and my T510 s working again with the nvidia.ko. > > David W. really has it right. If you rebuild the kernel, any port installing a kernel module needs to be rebuilt, as well. The use of PORT_MODULES in /etc/src.conf is the best way to make sure it happens. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 01:15:50 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE2CBEAC for ; Sun, 18 Jan 2015 01:15:50 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BB28F29C for ; Sun, 18 Jan 2015 01:15:50 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t0I1Fo8J013852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Jan 2015 17:15:50 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t0I1Fndb013851; Sat, 17 Jan 2015 17:15:49 -0800 (PST) (envelope-from sgk) Date: Sat, 17 Jan 2015 17:15:49 -0800 From: Steve Kargl To: Steven Hartland Subject: Re: who broke dtrace and buildworld? Message-ID: <20150118011549.GA13789@troutmask.apl.washington.edu> References: <20150117235447.GA13490@troutmask.apl.washington.edu> <20150118002246.GA13599@troutmask.apl.washington.edu> <20150118002350.GB13599@troutmask.apl.washington.edu> <54BB0753.3030202@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BB0753.3030202@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 01:15:51 -0000 On Sun, Jan 18, 2015 at 01:07:31AM +0000, Steven Hartland wrote: > > On 18/01/2015 00:23, Steve Kargl wrote: > > On Sat, Jan 17, 2015 at 04:22:46PM -0800, Steve Kargl wrote: > >> To fix the build, > >> > >> % svn revert -r 377300:377299 . > >> > > s/revert/merge > > > Full buildworld completes here even did a tinderbox on that one, do you > have anything strange in your env? Not that I know about. I have very little in /etc/make.conf and /etc/src.conf. % cat /etc/make.conf KERNCONF=MOBILE CPUTYPE?=core2 WITH_PKGNG=yes FFLAGS+= -O2 -pipe -march=native -mtune=native -funroll-loops -ftree-vectorize MAKE_JOBS_UNSAFE="yes" MASTER_SITE_FREEBSD="yes" % cat /etc/src.conf WITHOUT_TESTS = "YES" WITHOUT_CTM = "YES" WITHOUT_NDIS = "YES" WITHOUT_PROFILE = "YES" WITH_LLDB="yes" MALLOC_PRODUCTION = "YES" I also start my build process with cd /usr/obj rm -rf usr cd /usr/src make buildworld Due do space limitations on my laptop prior to this attempt at buildworld, I did symlink /usr/obj to /mnt/obj where /mnt/obj is on an external USB 2.0 hard drive. Reverting your patch allows me to complete a buildworld. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jan 17 21:46:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F8CF348 for ; Sat, 17 Jan 2015 21:46:58 +0000 (UTC) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C9ACFD32 for ; Sat, 17 Jan 2015 21:46:57 +0000 (UTC) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-03v.sys.comcast.net with comcast id h9mu1p0052Bo0NV019mu5m; Sat, 17 Jan 2015 21:46:54 +0000 Received: from jdc.koitsu.org ([69.181.142.213]) by resomta-ch2-05v.sys.comcast.net with comcast id h9mt1p00A4cTVs5019mtP9; Sat, 17 Jan 2015 21:46:54 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 189491AF10E; Sat, 17 Jan 2015 13:46:53 -0800 (PST) Date: Sat, 17 Jan 2015 13:46:53 -0800 From: Jeremy Chadwick To: Matthias Apitz , Eric van Gyzen , freebsd-current@freebsd.org Subject: Re: kernel: MCA: CPU 0 COR (1) internal parity error Message-ID: <20150117214653.GA65337@icarus.home.lan> References: <20150116194539.GA2230@c720-r276659> <54B96EE4.5090702@vangyzen.net> <20150117174326.GA40205@c720-r276659> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150117174326.GA40205@c720-r276659> User-Agent: Mutt/1.5.23 (2014-03-12) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1421531214; bh=NFH9lI6eFqKOTa0GqHImXpEXKZa+KjH96/0d2F+1dpI=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=JsUJLpxcOquaMn+0aYbsBtujJgyZInV4SAlNqhDUzUNBgf1ZHe5XTFiI3Ve8eCbVk hPWZ8K/KDlhvbN1JJVxpjiuT5MAy5w5OXIEG2B5eLEg55amU2EUOQVpbmTnvuPW1gN iA8aoHAQKmdv3RuA13gaRuqxT+vrtpIsLDS0/GVgm/tPnEGR6OHG9rg3EUnti4jsrf ecr2/04SBfDh2tDZBHr6Df53bQu9Rioiay5UCJ6PcLmspvl/fdVfHlx4CsleVF1SLQ oyYHEVWFthODn39O8v0LUqfBJwnPXJNm/MiTXAsFFzKwoudI4YJlSUpY4HjqPB643n 7FO2VpAItliGw== X-Mailman-Approved-At: Sun, 18 Jan 2015 01:21:07 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 17 Jan 2015 21:46:58 -0000 On Sat, Jan 17, 2015 at 06:43:26PM +0100, Matthias Apitz wrote: > El día Friday, January 16, 2015 a las 03:04:52PM -0500, Eric van Gyzen escribió: > > > On 01/16/2015 14:45, Matthias Apitz wrote: > > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Bank 0, Status 0x90000040000f0005 > > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000 > > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Vendor "GenuineIntel", ID 0x40651, APIC ID 0 > > > Jan 16 12:04:24 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error > > > > Try ports/sysutils/mcelog. > > I have installed that port and launched it as > > # mcelog > mcelog.txt > ... > mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors > mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors > mcelog: Unsupported new Family 6 Model 45 CPU: only decoding architectural errors > ... > > (the messages are STDERR); > > in 'mcelog.txt' it has for the last event from /var/log/messages: > > Jan 17 18:23:54 c720-r276659 kernel: MCA: Bank 0, Status 0x90000040000f0005 > Jan 17 18:23:54 c720-r276659 kernel: MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000 > Jan 17 18:23:54 c720-r276659 kernel: MCA: Vendor "GenuineIntel", ID 0x40651, APIC ID 0 > Jan 17 18:23:54 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error > > the following lines (the uptime matches): > > ... > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > MCE 32 > CPU 0 BANK 0 TSC 36eec80fd688 [at 1397 Mhz 0 days 12:0:41 uptime (unreliable)] > MCG status: > MCi status: > Error enabled > MCA: Unknown Error 5 > STATUS 90000040000f0005 MCGSTATUS 0 > MCGCAP c07 APICID 0 SOCKETID 0 > CPUID Vendor Intel Family 6 Model 69 > > Questions: > a) Is the output of mcelog valid (regardless of the msg on STDERR of > 'unsupported model')? It may or may not be reliable. For MCE decoding to work accurately, the software (read: kernel) needs to have full support for the processor model and revision in question. mcelog simply tries to decode the output that the kernel spits out and provide a more "user-friendly" explanation. That isn't as simple as just modifying some table of supported CPUs; it involves reading Intel documentation and implementing what can be figured out through that. VMware has a small KB about this, to give you some insight into the complexity: http://kb.vmware.com/kb/1005184 There are some capabilities of MCA that are "semi-universal" across series of CPUs, so sometimes those can be decoded (mostly) accurately, but other times such isn't the case. Sometimes there are certain MCEs that have be ignored by the kernel (i.e. the kernel MCE support has to be updated to reflect changes in MCEs for that newer model of processor). The version of mcelog available in ports is extremely old, and the amount of work to upgrade it to the latest Linux mcelog (1.08) I imagine would be quite large: http://git.kernel.org/cgit/utils/cpu/mce/mcelog.git The existing FreeBSD port involves a large number of patches written by John Baldwin, and whether or not those can be correctly backported to newer mcelog releases is unknown. I really need to renounce my maintainer flag of that port and let someone else take care of it. > b) Is it worth to contact the dealer or wait until it is broken > completely? To me, the above message indicates that one of the CPU cores is damaged/misbehaving. I cannot determine if it's referring to L1, L2, or L3 cache, but I don't see any clear indicator of that (possibly due to the aforementioned explanation I gave about accuracy). However, I will point you to this thread, which may indicate that the model of CPU in question (or series or models of Intel CPUs) have MCEs that happen which are considered "normal" and are thus not being decoded correctly: https://lists.freebsd.org/pipermail/freebsd-questions/2014-January/255873.html I would suggest providing relevant dmesg lines about your exact processor in this system and possibly ask for help from either John Baldwin or someone on freebsd-hackers@. I myself cannot help with this. The dmesg lines I'm referring to, by the way, look like this (all of them matter, particularly the first two): CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (2833.59-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10677 Family = 0x6 Model = 0x17 Stepping = 7 Features=0xbfebfbff Features2=0x8e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics The OP of that freebsd-questions thread should have provided this but didn't (instead just says "Intel i3-4310" -- this isn't precise enough), so whether or not you two are using the same CPU is unknown. There simply could be "new MCEs" or changes to the MCA that Intel implemented in some newer models of Core iX that aren't being handled correctly by the kernel (i.e. misreporting or mis-decoding). Good luck! -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 01:40:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C538970 for ; Sun, 18 Jan 2015 01:40:23 +0000 (UTC) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6B2E699 for ; Sun, 18 Jan 2015 01:40:22 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w61so26003692wes.1 for ; Sat, 17 Jan 2015 17:40:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U4xZPN28eaku3u5azRv3k9XlzLfb9B5WsmFQtU/XYgw=; b=DZMrkUSEwKzwJO2+vLNR9O+bWVR4dgStVtpFYOaAiwyKEmI3S2yoNaYMHCTuHa+qcM N09cTv7lYXr1klkwvyvr+Kb8e0qKYtoyrRv3sKMuOB4ocVOy7ZR7cGcPNFOtPXxBfFnf rYp7editWwS24wcuGfjSNr7AujXZ0R55I1KYyUCCwJNetWYjibX9bdbOjP9X/y/xVa34 LJ1hxigeu5a8M465rHZvaI069YhrFIc8YUPC3mgHvbGfGkuCVY6ntr7FHGMzYAqKUSYD vOvD8Tpa3fxFvfh4t2onT2KVjZq5ISNZ9Tp6lpgrfoKIL9u3/haiqW/BUEbuI493HzRg 7hww== X-Gm-Message-State: ALoCoQm8lODqq8Yo1/hwVAvKX/G1X3J5sjMTe5EOgazt+k65LRHRgVLMgDZmMkbb4vSW2fLBZJi6 X-Received: by 10.180.72.178 with SMTP id e18mr20300535wiv.23.1421545215049; Sat, 17 Jan 2015 17:40:15 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id dp8sm8546093wib.20.2015.01.17.17.40.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Jan 2015 17:40:14 -0800 (PST) Message-ID: <54BB0EF9.3060705@multiplay.co.uk> Date: Sun, 18 Jan 2015 01:40:09 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Steve Kargl , freebsd-current@freebsd.org Subject: Re: who broke dtrace and buildworld? References: <20150117235447.GA13490@troutmask.apl.washington.edu> <20150118002246.GA13599@troutmask.apl.washington.edu> In-Reply-To: <20150118002246.GA13599@troutmask.apl.washington.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 01:40:23 -0000 On 18/01/2015 00:22, Steve Kargl wrote: > On Sat, Jan 17, 2015 at 03:54:47PM -0800, Steve Kargl wrote: >> % cd /usr/src >> % svn update >> Updating '.': >> At revision 277307. >> % make buildworld >> .... >> >> =3D=3D=3D> cddl/usr.sbin/dtrace (all) >> cc -O2 -pipe -march=3Dcore2 -I/usr/src/cddl/usr.sbin/dtrace/../../..= /sys/cddl/compat/opensolaris -I/usr/src/cddl/usr.sbin/dtrace/../../../cd= dl/compat/opensolaris/include -I/usr/src/cddl/usr.sbin/dtrace/../../../c= ddl/contrib/opensolaris/head -I/usr/src/cddl/usr.sbin/dtrace/../../../cd= dl/contrib/opensolaris/lib/libdtrace/common -I/usr/src/cddl/usr.sbin/dtr= ace/../../../cddl/contrib/opensolaris/lib/libproc/common -I/usr/src/cddl= /usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr= /src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/compat -D= NEED_SOLARIS_BOOLEAN -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wer= ror -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-pl= us-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-v= alue -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses= -Qunused-arguments -o dtrace dtrace.o -ldtrace -ly -ll >> -lproc -lctf -lelf -lz -lutil -lrtld_db -lpthread >> /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_= idstack_lookup' >> /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_= idops_probe' >> /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_= idhash_nextid' >> /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_= idhash_create' >> /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_= idhash_lookup' >> /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_= idops_type' >> /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_= idops_thaw' >> /usr/obj/usr/src/tmp/usr/lib/libdtrace.so: undefined reference to `dt_= idops_args >> >> Please fix. >> > To fix the build, > > % svn revert -r 377300:377299 . Just double checked and I can building r277307 without issue, build box=20 is running 10.1-RELEASE. My head box is quite a bit slower and is still running, but it did=20 complete a full buildworld on what is r277300 before it was committed so = no reason to think it wont complete. =2E.. --- ldd32 --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem=20 /usr/obj/usr/home/smh/freebsd/base/head/lib32/usr/include/=20 -L/usr/obj/usr/home/smh/freebsd/base/head/lib32/usr/lib32=20 -B/usr/obj/usr/home/smh/freebsd/base/head/lib32/usr/lib32 -O2 -pipe=20 -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall=20 -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes=20 -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual=20 -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align=20 -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls=20 -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations = -Wthread-safety -Wno-empty-body -Wno-string-plus-int=20 -Wno-unused-const-variable -Qunused-arguments -o ldd32 ldd.o sods.o --- buildworld_epilogue --- -------------------------------------------------------------- >>> World build completed on Sun Jan 18 01:31:27 UTC 2015 -------------------------------------------------------------- svn info |grep Revision Revision: 277307 Is anyone else seeing this issue? Regards Steve From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 01:44:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97429A88 for ; Sun, 18 Jan 2015 01:44:57 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 74FCE79A for ; Sun, 18 Jan 2015 01:44:57 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t0I1iuZw014011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Jan 2015 17:44:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t0I1iu6r014010; Sat, 17 Jan 2015 17:44:56 -0800 (PST) (envelope-from sgk) Date: Sat, 17 Jan 2015 17:44:56 -0800 From: Steve Kargl To: Steven Hartland Subject: Re: who broke dtrace and buildworld? Message-ID: <20150118014456.GA13973@troutmask.apl.washington.edu> References: <20150117235447.GA13490@troutmask.apl.washington.edu> <20150118002246.GA13599@troutmask.apl.washington.edu> <54BB0EF9.3060705@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BB0EF9.3060705@multiplay.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 01:44:57 -0000 On Sun, Jan 18, 2015 at 01:40:09AM +0000, Steven Hartland wrote: > > > > > % svn revert -r 377300:377299 . > Just double checked and I can building r277307 without issue, build box > is running 10.1-RELEASE. > > My head box is quite a bit slower and is still running, but it did > complete a full buildworld on what is r277300 before it was committed so > no reason to think it wont complete. My laptop is running % uname -a (with some editing) FreeBSD 11.0-CURRENT r275646: Tue Dec 9 12:23:30 PST 2014 and I understand the "a bit slower" statement as it takes 5+ hours to buildworld on my laptop. Note sure if it matters, but I'm building i386 not amd64. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 02:16:19 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B47ADF14 for ; Sun, 18 Jan 2015 02:16:19 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FA19E3 for ; Sun, 18 Jan 2015 02:16:18 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hi2so10320649wib.2 for ; Sat, 17 Jan 2015 18:16:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Dp1bmjc7QVsESuI/48lwNn5oj9FzAN+eLg7G1MzAi8E=; b=fyFqkCDwt07a6ml8t3YSi6CczjnsOS1FAkAliVAJNtZ/eZuzNofH3n3By3dJijaHJT KI1cReBStGWKgjCP2RTIbFD+Ex2tUlRCzHTz5MveDAltuN39KfMSJuS51haChVLXP2kD V6iQ7RoVZQkylr/lK2ClCZ03jweRRChMJWUU4uPExOvxP6TwZ6f4HxMfXMWByqqdVm4T rsF+iVWQ9+cF6e/rV5uTT8ofLEobCrk9YD6J+mQ77yTvTomexG7lM85/UkoTUWs0FL01 Atd1StOd6DHfd2/0nMwRpTGsTNLnQ02MWjfoDtNrRr+Z3mBlcnQr3Yw35KO7LXxXlSRi AsAw== X-Gm-Message-State: ALoCoQnZO63EsZ8vH6FIPDm7Ypt/+jOJaATwrEY8Z0vXaBGpirhkwtOLiQClLvxabJ3mz6cVd+91 X-Received: by 10.180.107.228 with SMTP id hf4mr21056613wib.47.1421547024498; Sat, 17 Jan 2015 18:10:24 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id hz9sm11710876wjb.17.2015.01.17.18.10.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Jan 2015 18:10:23 -0800 (PST) Message-ID: <54BB160B.1070106@multiplay.co.uk> Date: Sun, 18 Jan 2015 02:10:19 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Steve Kargl Subject: Re: who broke dtrace and buildworld? References: <20150117235447.GA13490@troutmask.apl.washington.edu> <20150118002246.GA13599@troutmask.apl.washington.edu> <54BB0EF9.3060705@multiplay.co.uk> <20150118014456.GA13973@troutmask.apl.washington.edu> In-Reply-To: <20150118014456.GA13973@troutmask.apl.washington.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 02:16:19 -0000 On 18/01/2015 01:44, Steve Kargl wrote: > On Sun, Jan 18, 2015 at 01:40:09AM +0000, Steven Hartland wrote: >>> % svn revert -r 377300:377299 . >> Just double checked and I can building r277307 without issue, build box >> is running 10.1-RELEASE. >> >> My head box is quite a bit slower and is still running, but it did >> complete a full buildworld on what is r277300 before it was committed so >> no reason to think it wont complete. > My laptop is running > > % uname -a (with some editing) > FreeBSD 11.0-CURRENT r275646: Tue Dec 9 12:23:30 PST 2014 > > and I understand the "a bit slower" statement as it takes 5+ hours > to buildworld on my laptop. > > Note sure if it matters, but I'm building i386 not amd64. I just replaced my make.conf and src.conf with the ones you posted and am retested and again the build completes. tinderbox being based off universe just with error reporting so tested buildworld and buildkernel for all arch's so I can't see i386 being an issue either, but I'm testing now with TARGET=i386 just be be sure. Could you verify you don't have something stale or a bad checkout? From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 02:36:01 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BA32E2 for ; Sun, 18 Jan 2015 02:36:01 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 291C8B41 for ; Sun, 18 Jan 2015 02:36:01 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t0I2ZxAY014204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Jan 2015 18:35:59 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t0I2Zxb0014203; Sat, 17 Jan 2015 18:35:59 -0800 (PST) (envelope-from sgk) Date: Sat, 17 Jan 2015 18:35:59 -0800 From: Steve Kargl To: Steven Hartland Subject: Re: who broke dtrace and buildworld? Message-ID: <20150118023559.GA14178@troutmask.apl.washington.edu> References: <20150117235447.GA13490@troutmask.apl.washington.edu> <20150118002246.GA13599@troutmask.apl.washington.edu> <54BB0EF9.3060705@multiplay.co.uk> <20150118014456.GA13973@troutmask.apl.washington.edu> <54BB160B.1070106@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BB160B.1070106@multiplay.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 02:36:01 -0000 On Sun, Jan 18, 2015 at 02:10:19AM +0000, Steven Hartland wrote: > > On 18/01/2015 01:44, Steve Kargl wrote: > > On Sun, Jan 18, 2015 at 01:40:09AM +0000, Steven Hartland wrote: > >>> % svn revert -r 377300:377299 . > >> Just double checked and I can building r277307 without issue, build box > >> is running 10.1-RELEASE. > >> > >> My head box is quite a bit slower and is still running, but it did > >> complete a full buildworld on what is r277300 before it was committed so > >> no reason to think it wont complete. > > My laptop is running > > > > % uname -a (with some editing) > > FreeBSD 11.0-CURRENT r275646: Tue Dec 9 12:23:30 PST 2014 > > > > and I understand the "a bit slower" statement as it takes 5+ hours > > to buildworld on my laptop. > > > > Note sure if it matters, but I'm building i386 not amd64. > I just replaced my make.conf and src.conf with the ones you posted and > am retested and again the build completes. > > tinderbox being based off universe just with error reporting so tested > buildworld and buildkernel for all arch's so I can't see i386 being an > issue either, but I'm testing now with TARGET=i386 just be be sure. > > Could you verify you don't have something stale or a bad checkout? I did all of the checking before I sent the first email (including multiple 'svn update' and 'svn status'). The tree before reverting your patch was an up-to-date head without any other patches. I use neither ccache nor -DNOCLEAN and use 'rm -rf /usr/obj/*' to clean out OBJDIR. Without your patch installed everything completed as I expected (well, I did hit the MCA_system issue), and updated my system. I'm now trying to again rebuild buildworld from scratch. This is going to take awhile. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 03:32:32 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA466930 for ; Sun, 18 Jan 2015 03:32:32 +0000 (UTC) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EE05124 for ; Sun, 18 Jan 2015 03:32:31 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id l2so4407183wgh.11 for ; Sat, 17 Jan 2015 19:32:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Saa+oDkV30lNQqnZHF/8M7fnIyUDOJHbsqqCABMMdnQ=; b=OswWA9zYoOQyTboCMseJvSTYR2kiqyD03vIy/RoFRcSx5WzCHXrhcyt7aEpoCFO1Mo MMddtzp9ws4loYJkwEmpsX1qbJ08jVJd0L95jbIN1SPCfu1c/AK1d8f4Z739z1lMmOLr 6aI/PM9QrjWRgmZu/XbHtJdYEF6zAqKk5+2QkPp+K32ydK2tNKFmbP0+WekApToY3czl ml74NUvOsVYlZSQTzusqspkbXq0IPpBYbICksepea2gvR7atXqUs8BU+neeJlbGooGXm jtWzNyHRsEVrTK2bT6EjXpZh1Q6ZjqNwy9Fvbj2SNuYov+nv9K6HcjclEqfCt3S6rUhB vSEw== X-Gm-Message-State: ALoCoQk5OmFCRF14hppvmbuqcLdE+8K0cCtfiX/3POgM0T86L7DZ6BWMFBPT3UAL8kP+IKac0KJK X-Received: by 10.180.109.79 with SMTP id hq15mr19634500wib.47.1421551943763; Sat, 17 Jan 2015 19:32:23 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id l6sm11860072wjx.33.2015.01.17.19.32.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Jan 2015 19:32:22 -0800 (PST) Message-ID: <54BB2942.2040400@multiplay.co.uk> Date: Sun, 18 Jan 2015 03:32:18 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Steve Kargl Subject: Re: who broke dtrace and buildworld? References: <20150117235447.GA13490@troutmask.apl.washington.edu> <20150118002246.GA13599@troutmask.apl.washington.edu> <54BB0EF9.3060705@multiplay.co.uk> <20150118014456.GA13973@troutmask.apl.washington.edu> <54BB160B.1070106@multiplay.co.uk> <20150118023559.GA14178@troutmask.apl.washington.edu> In-Reply-To: <20150118023559.GA14178@troutmask.apl.washington.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 03:32:33 -0000 On 18/01/2015 02:35, Steve Kargl wrote: > On Sun, Jan 18, 2015 at 02:10:19AM +0000, Steven Hartland wrote: >> On 18/01/2015 01:44, Steve Kargl wrote: >>> On Sun, Jan 18, 2015 at 01:40:09AM +0000, Steven Hartland wrote: >>>>> % svn revert -r 377300:377299 . >>>> Just double checked and I can building r277307 without issue, build box >>>> is running 10.1-RELEASE. >>>> >>>> My head box is quite a bit slower and is still running, but it did >>>> complete a full buildworld on what is r277300 before it was committed so >>>> no reason to think it wont complete. >>> My laptop is running >>> >>> % uname -a (with some editing) >>> FreeBSD 11.0-CURRENT r275646: Tue Dec 9 12:23:30 PST 2014 >>> >>> and I understand the "a bit slower" statement as it takes 5+ hours >>> to buildworld on my laptop. >>> >>> Note sure if it matters, but I'm building i386 not amd64. >> I just replaced my make.conf and src.conf with the ones you posted and >> am retested and again the build completes. >> >> tinderbox being based off universe just with error reporting so tested >> buildworld and buildkernel for all arch's so I can't see i386 being an >> issue either, but I'm testing now with TARGET=i386 just be be sure. >> >> Could you verify you don't have something stale or a bad checkout? > I did all of the checking before I sent the first email (including > multiple 'svn update' and 'svn status'). The tree before reverting > your patch was an up-to-date head without any other patches. I > use neither ccache nor -DNOCLEAN and use 'rm -rf /usr/obj/*' to > clean out OBJDIR. Without your patch installed everything completed > as I expected (well, I did hit the MCA_system issue), and updated > my system. I'm now trying to again rebuild buildworld from scratch. > This is going to take awhile. buildworld with TARGET=i386 worked fine as did standard amd64 on head ...lsqlite3 -lz -lcrypto -lssl -lpthread --- buildworld_epilogue --- -------------------------------------------------------------- >>> World build completed on Sun Jan 18 02:23:24 UTC 2015 -------------------------------------------------------------- ...uments -o ldd32 ldd.o sods.o --- buildworld_epilogue --- -------------------------------------------------------------- >>> World build completed on Sun Jan 18 02:40:26 UTC 2015 -------------------------------------------------------------- Both from Revision: 277307 From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 04:34:31 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AB606B; Sun, 18 Jan 2015 04:34:31 +0000 (UTC) Received: from maul.immure.com (104-49-19-137.lightspeed.austtx.sbcglobal.net [104.49.19.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6CEE7FB; Sun, 18 Jan 2015 04:34:29 +0000 (UTC) Received: from rancor.immure.com ([10.1.132.9]) by maul.immure.com with esmtp (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YChZD-00088L-35; Sat, 17 Jan 2015 22:34:27 -0600 Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.14.9/8.14.9) with ESMTP id t0I4YQY6004330; Sat, 17 Jan 2015 22:34:26 -0600 (CST) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.14.9/8.14.9/Submit) id t0I4YQHF004329; Sat, 17 Jan 2015 22:34:26 -0600 (CST) (envelope-from bob) Date: Sat, 17 Jan 2015 22:34:26 -0600 From: Bob Willcox To: current@freebsd.org, FreeBSD Ports , FreeBSD CURRENT Message-ID: <20150118043426.GF91189@rancor.immure.com> Reply-To: Bob Willcox References: <20150117151806.GE91189@rancor.immure.com> <54BA8380.4060108@selasky.org> <20150117154837.GL1151@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150117154837.GL1151@albert.catwhisker.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 10.1.132.9 X-SA-Exim-Mail-From: bob@immure.com X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on maul.immure.com X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 Subject: Re: CURRENT breaks loading of nvidia.so X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on maul.immure.com) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 04:34:31 -0000 On Sat, Jan 17, 2015 at 07:48:37AM -0800, David Wolfskill wrote: > On Sat, Jan 17, 2015 at 04:45:04PM +0100, Hans Petter Selasky wrote: > > > > Hi, > > > > The nvidia-driver package needs to be recompiled with the latest > > FreeBSD-current sources, because of changes in the callout subsystem. > > > > If this is not possible, we can temporarily add the "_callout_stop_safe" > > symbol to the kernel for some transition time. > > ... > > While I'm running i386 (vs. amd64), I have not encountered the cited > issue. > > Given the above, I suspect that the fact that I have the line: > > PORTS_MODULES=x11/nvidia-driver > > > in /etc/src.conf has a fair amount of (positive) influence on that. > > (I track stable/10 & head -- on different slices -- daily on my laptop.) > > Peace, > david Thanks ALL! Adding the PORTS_MODULES=x11/nvidia-driver line to my /etc/src.conf file and rebuilding the kernel fixed it! Learn something new every day! :) Bob -- Bob Willcox | The Ancient Doctrine of Mind Over Matter: bob@immure.com | I don't mind... and you don't matter. Austin, TX | -- As revealed to reporter G. Rivera by Swami Havabanana From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 05:22:07 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 179EC434; Sun, 18 Jan 2015 05:22:07 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CFD06B91; Sun, 18 Jan 2015 05:22:06 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id hn15so8853487igb.3; Sat, 17 Jan 2015 21:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nPIk38LmHdu9Vz5N4QD4uu3TZzXs8RyxhdLWJazm9w0=; b=eUVSQSJMi/5hYClJ+VMk2N2TMzu8Sz32UvM8nm+DCI/KuUXaJUEtQyVZMAdSFjMNXM UkzeET8OM2ge8l0sUNDzLWaVSciSV368u8VP7//LHFqoX5Jd1y08x/Y44xg5p8e3J0x3 ynNO73I5dC1K/xhko3GVOsxv/pEbxFSdGqo20IbOtuvpSgLHnhhYX2RqUok8M0W1pdQd oLPqwBbgyLzlYy3cu0bm4LkBzwsVSvf62V+K/pJYkoFtSWpYVMxRZ6B6vArSLIED9wno c1L5QqC+bvuPNWPf0bM/mgFe48EYX7bHo515FQGVHn65ZmTmOmkznrOo3ABq2Y5voo63 XcZw== MIME-Version: 1.0 X-Received: by 10.107.168.88 with SMTP id r85mr11797393ioe.76.1421558526095; Sat, 17 Jan 2015 21:22:06 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.52.19 with HTTP; Sat, 17 Jan 2015 21:22:06 -0800 (PST) In-Reply-To: <20150118043426.GF91189@rancor.immure.com> References: <20150117151806.GE91189@rancor.immure.com> <54BA8380.4060108@selasky.org> <20150117154837.GL1151@albert.catwhisker.org> <20150118043426.GF91189@rancor.immure.com> Date: Sat, 17 Jan 2015 21:22:06 -0800 X-Google-Sender-Auth: Z3nbJVsZ7Zzcq4J0qbXwhQ5sUN8 Message-ID: Subject: Re: CURRENT breaks loading of nvidia.so From: Kevin Oberman To: Bob Willcox Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD CURRENT , "current@freebsd.org" , FreeBSD Ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 05:22:07 -0000 On Sat, Jan 17, 2015 at 8:34 PM, Bob Willcox wrote: > On Sat, Jan 17, 2015 at 07:48:37AM -0800, David Wolfskill wrote: > > On Sat, Jan 17, 2015 at 04:45:04PM +0100, Hans Petter Selasky wrote: > > > > > > Hi, > > > > > > The nvidia-driver package needs to be recompiled with the latest > > > FreeBSD-current sources, because of changes in the callout subsystem. > > > > > > If this is not possible, we can temporarily add the > "_callout_stop_safe" > > > symbol to the kernel for some transition time. > > > ... > > > > While I'm running i386 (vs. amd64), I have not encountered the cited > > issue. > > > > Given the above, I suspect that the fact that I have the line: > > > > PORTS_MODULES=x11/nvidia-driver > > > > > > in /etc/src.conf has a fair amount of (positive) influence on that. > > > > (I track stable/10 & head -- on different slices -- daily on my laptop.) > > > > Peace, > > david > > Thanks ALL! Adding the PORTS_MODULES=x11/nvidia-driver line to my > /etc/src.conf > file and rebuilding the kernel fixed it! > > Learn something new every day! :) > Can anyone tell me where PORTS_MODULES is documented? I don't find it in the Handbook. It's not in src.conf(5). I've known of it since Doug B. (I thing) wrote it. This is a very beneficial tool. It really needs to be well documented. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 05:28:48 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D707B5F1; Sun, 18 Jan 2015 05:28:48 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C3DCBBC; Sun, 18 Jan 2015 05:28:47 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t0I5SfkE067334; Sat, 17 Jan 2015 21:28:41 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t0I5Sem1067333; Sat, 17 Jan 2015 21:28:40 -0800 (PST) (envelope-from david) Date: Sat, 17 Jan 2015 21:28:40 -0800 From: David Wolfskill To: Kevin Oberman Subject: Re: CURRENT breaks loading of nvidia.so Message-ID: <20150118052840.GB52267@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Kevin Oberman , FreeBSD CURRENT , FreeBSD Ports References: <20150117151806.GE91189@rancor.immure.com> <54BA8380.4060108@selasky.org> <20150117154837.GL1151@albert.catwhisker.org> <20150118043426.GF91189@rancor.immure.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD CURRENT , FreeBSD Ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 05:28:48 -0000 --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 17, 2015 at 09:22:06PM -0800, Kevin Oberman wrote: > ... > Can anyone tell me where PORTS_MODULES is documented? I don't find it in > the Handbook. It's not in src.conf(5). I've known of it since Doug B. (I > thing) wrote it. This is a very beneficial tool. It really needs to be we= ll > documented. > ... build(7) has it. (I confess that I didn't recall this, nor it it just "magically occur" to me. Rather, brute force works again: grep -Zwr PORTS_MODULES /usr/share/man/man* Ugly, perhaps, but effective. :-}) Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --St7VIuEGZ6dlpu13 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUu0SIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7cmwQAJ+O44vNJNtpHe2bVTdxnwCn rsJqZs2svuK76BN57NNFVCPibEFekt/mG4FAo0IF1wzqs99cmfpU4JhTwrOvzJB3 8jLnLTao16uN1FWeXyZR5c5zKAPb8KnwKysLaT5w3MbCg/YwLfbatbWrX6QsssBC ZFZkdfNg0yUMHfFrcG2lOHm34q3D4VJ62O1aR2d0adgZL+fFzRQydPYcC/AsN8pP p2Xflcn83P/zrnh1fRn8BO3xpQzuHYwdr0co3cSBDjoZYcUEbhO/dbI2lgrQgmCe +HCDirdcaN6IHISRcO+5+GNeVpb6ECXzCtkprUVCUB/JbLJqUBi7gYIDyVMhn1k2 1pE9GcQiGBeJfC5QNjVzZuJQx4907s+ijm3O42ZtF5pdQJyfUIAbzdKJXDWaJ6ea ZE0CU2xR2paD5hJjcFTWZ4yHkvBMGnDjx7KoQOhref9ROVd26IXzD0GZEr9+xJ1j FWpiDxaS5G/i4nT80ZlqJfr2+FCYCq1JMb2z+efwHYxSEsqstp4kO3vaUmsYTwXG d+V+H6nwFz+E/nfUGNWNP2ZQlPj8fbj/fegpu2Zb9H3iEcB7jOm648xFMn9Bxilz Gm/J5Lu+J/dSyCmm5xl2+rWUp+Yv7OMeySjPgPzbhYUGcBO0rthSAwiKJ74QW7nn nuJA1fw8ue+vkFf6QCfO =9O8r -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 05:40:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 989488CE for ; Sun, 18 Jan 2015 05:40:20 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8A194C7C for ; Sun, 18 Jan 2015 05:40:20 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5D265733 for ; Sun, 18 Jan 2015 05:40:20 +0000 (UTC) Date: Sun, 18 Jan 2015 05:40:20 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1396719640.16.1421559620259.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD-tests2 #577 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 05:40:20 -0000 See From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 05:48:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65E71AA3; Sun, 18 Jan 2015 05:48:23 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 29501D3D; Sun, 18 Jan 2015 05:48:23 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id tr6so26596866ieb.3; Sat, 17 Jan 2015 21:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=eK4VcgHd9Vl3i9OnvElPNinBvCH5rO6Txopvh/orhXg=; b=EErYIpj2cGBW9BmCFhMNtcoPaizNBLyOybVl+0jYS9op9gsWqvO7AI705kR/dgllUi 5Eh3WIyjSf5dTJ2S/WUnykoBtA2eB6cGQlTQ/NmNAz2T3O/PC+Vjisrh1Zjr7aO8v7zs a8Vk0cNfDFsmWbch8Z7dVuLk1VIVfrFpjtPF4ckMQCJ+aAA9oq/aG6mB6VNp2kr6q1ff LZMJFQR2IWJ1sVBO4w83BZUF4Mr7rRpwic8x1YZZInmqer6kdWvwsddKlAyMCuVugyjf n/zxzjthJ2AdQ2h65Qb2gmUHgj+i7MlHxaAhgkUiMnkFB2JLNPxB+O03VHzrOVowUvun Zwpg== MIME-Version: 1.0 X-Received: by 10.51.17.11 with SMTP id ga11mr12429138igd.0.1421560102532; Sat, 17 Jan 2015 21:48:22 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.52.19 with HTTP; Sat, 17 Jan 2015 21:48:22 -0800 (PST) In-Reply-To: <20150118052840.GB52267@albert.catwhisker.org> References: <20150117151806.GE91189@rancor.immure.com> <54BA8380.4060108@selasky.org> <20150117154837.GL1151@albert.catwhisker.org> <20150118043426.GF91189@rancor.immure.com> <20150118052840.GB52267@albert.catwhisker.org> Date: Sat, 17 Jan 2015 21:48:22 -0800 X-Google-Sender-Auth: ybE34v0SGPt13mtiuBt3MkMqIkI Message-ID: Subject: Re: CURRENT breaks loading of nvidia.so From: Kevin Oberman To: David Wolfskill , Kevin Oberman , FreeBSD CURRENT , FreeBSD Ports Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 05:48:23 -0000 Any hope to get a bit of text on this into the Handbook? Maybe with the example in Doug B.'s e-mail announcing it. (It's in the ports archive and DuckDuckGo can find it easily.) The example in build(7) is for a single module while Doug's message show that they should be space delimited. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com On Sat, Jan 17, 2015 at 9:28 PM, David Wolfskill wrote: > On Sat, Jan 17, 2015 at 09:22:06PM -0800, Kevin Oberman wrote: > > ... > > Can anyone tell me where PORTS_MODULES is documented? I don't find it in > > the Handbook. It's not in src.conf(5). I've known of it since Doug B. (I > > thing) wrote it. This is a very beneficial tool. It really needs to be > well > > documented. > > ... > > build(7) has it. > > (I confess that I didn't recall this, nor it it just "magically occur" > to me. Rather, brute force works again: > > grep -Zwr PORTS_MODULES /usr/share/man/man* > > Ugly, perhaps, but effective. :-}) > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Those who murder in the name of God or prophet are blasphemous cowards. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 07:02:07 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85CAF221 for ; Sun, 18 Jan 2015 07:02:07 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 61623394 for ; Sun, 18 Jan 2015 07:02:07 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t0I7256w015003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Jan 2015 23:02:05 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t0I725ir015002; Sat, 17 Jan 2015 23:02:05 -0800 (PST) (envelope-from sgk) Date: Sat, 17 Jan 2015 23:02:05 -0800 From: Steve Kargl To: Steven Hartland Subject: Re: who broke dtrace and buildworld? Message-ID: <20150118070205.GA14993@troutmask.apl.washington.edu> References: <20150117235447.GA13490@troutmask.apl.washington.edu> <20150118002246.GA13599@troutmask.apl.washington.edu> <54BB0EF9.3060705@multiplay.co.uk> <20150118014456.GA13973@troutmask.apl.washington.edu> <54BB160B.1070106@multiplay.co.uk> <20150118023559.GA14178@troutmask.apl.washington.edu> <54BB2942.2040400@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BB2942.2040400@multiplay.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 07:02:07 -0000 > > I did all of the checking before I sent the first email (including > > multiple 'svn update' and 'svn status'). The tree before reverting > > your patch was an up-to-date head without any other patches. I > > use neither ccache nor -DNOCLEAN and use 'rm -rf /usr/obj/*' to > > clean out OBJDIR. Without your patch installed everything completed > > as I expected (well, I did hit the MCA_system issue), and updated > > my system. I'm now trying to again rebuild buildworld from scratch. > > This is going to take awhile. > buildworld with TARGET=i386 worked fine as did standard amd64 on head > > ...lsqlite3 -lz -lcrypto -lssl -lpthread > --- buildworld_epilogue --- > -------------------------------------------------------------- > >>> World build completed on Sun Jan 18 02:23:24 UTC 2015 > -------------------------------------------------------------- > > ...uments -o ldd32 ldd.o sods.o > --- buildworld_epilogue --- > -------------------------------------------------------------- > >>> World build completed on Sun Jan 18 02:40:26 UTC 2015 > -------------------------------------------------------------- > > Both from Revision: 277307 Must be a problem with updating from a circa early December 2014 world to 277300. My newest attempt completed as expected. Have no idea what caused th build failure, but it appears "fixed". -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 14:17:15 2015 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B09D1CD4 for ; Sun, 18 Jan 2015 14:17:15 +0000 (UTC) Received: from oslo.ath.cx (oslo.ath.cx [IPv6:2a01:4f8:200:42e4::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oslo.ath.cx", Issuer "oslo.ath.cx" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2034423C for ; Sun, 18 Jan 2015 14:17:14 +0000 (UTC) Received: by oslo.ath.cx (OpenSMTPD) with ESMTP id 308f407b; for ; Sun, 18 Jan 2015 15:17:12 +0100 (CET) Date: Sun, 18 Jan 2015 15:17:12 +0100 From: "Herbert J. Skuhra" To: current@FreeBSD.org Subject: Re: svn commit: r272568 - head/sys/net Message-ID: <20150118141712.GA14056@oslo.ath.cx> References: <201410051943.s95JhbCp073535@svn.freebsd.org> <20150117151015.GA63617@oslo.ath.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150117151015.GA63617@oslo.ath.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 14:17:15 -0000 On Sat, Jan 17, 2015 at 04:10:15PM +0100, Herbert J. Skuhra wrote: > On Sun, Oct 05, 2014 at 07:43:37PM +0000, Hiroki Sato wrote: > > Author: hrs > > Date: Sun Oct 5 19:43:37 2014 > > New Revision: 272568 > > URL: https://svnweb.freebsd.org/changeset/base/272568 > > > > Log: > > Virtualize if_bridge(4) cloner. > > Hi, > > after this commit I always get a kernel panic when I stop my > vnet jails. With a recent kernel this only happens when if_bridge is loaded > as a module. > > savecore: writing core to /var/crash/vmcore.4 > savecore: reboot after panic: mtx_lock() of destroyed mutex @ > /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:1814 Sorry, there is already a bug report for this (195859). -- Herbert From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 15:33:14 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8038C37; Sun, 18 Jan 2015 15:33:14 +0000 (UTC) Received: from maul.immure.com (104-49-19-137.lightspeed.austtx.sbcglobal.net [104.49.19.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30892B82; Sun, 18 Jan 2015 15:33:13 +0000 (UTC) Received: from rancor.immure.com ([10.1.132.9]) by maul.immure.com with esmtp (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YCrqa-000BPg-Nx; Sun, 18 Jan 2015 09:33:05 -0600 Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.14.9/8.14.9) with ESMTP id t0IFX40Y006421; Sun, 18 Jan 2015 09:33:04 -0600 (CST) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.14.9/8.14.9/Submit) id t0IFX4Tx006420; Sun, 18 Jan 2015 09:33:04 -0600 (CST) (envelope-from bob) Date: Sun, 18 Jan 2015 09:33:04 -0600 From: Bob Willcox To: Kevin Oberman Message-ID: <20150118153303.GG91189@rancor.immure.com> Reply-To: Bob Willcox References: <20150117151806.GE91189@rancor.immure.com> <54BA8380.4060108@selasky.org> <20150117154837.GL1151@albert.catwhisker.org> <20150118043426.GF91189@rancor.immure.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 10.1.132.9 X-SA-Exim-Mail-From: bob@immure.com X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on maul.immure.com X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 Subject: Re: CURRENT breaks loading of nvidia.so X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on maul.immure.com) Cc: FreeBSD CURRENT , "current@freebsd.org" , FreeBSD Ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 15:33:15 -0000 On Sat, Jan 17, 2015 at 09:22:06PM -0800, Kevin Oberman wrote: > > Can anyone tell me where PORTS_MODULES is documented? I don't find it in > the Handbook. It's not in src.conf(5). I've known of it since Doug B. (I > thing) wrote it. This is a very beneficial tool. It really needs to be well > documented. > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com I found it in the make.conf(5) man page. I will say, however, that the description is fairly skimpy and I wouldn't have really known how to use it to solve my nvidia driver problem w/o the help of folks here. A more complete description, preferably with a few examples, would really help to understand how it is actually used. Bob -- Bob Willcox | The Ancient Doctrine of Mind Over Matter: bob@immure.com | I don't mind... and you don't matter. Austin, TX | -- As revealed to reporter G. Rivera by Swami Havabanana From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 17:43:35 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42D7D49D for ; Sun, 18 Jan 2015 17:43:35 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DED3193A for ; Sun, 18 Jan 2015 17:43:33 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t0IHhWQ6001431; Sun, 18 Jan 2015 09:43:32 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t0IHhVKU001430; Sun, 18 Jan 2015 09:43:31 -0800 (PST) (envelope-from david) Date: Sun, 18 Jan 2015 09:43:31 -0800 From: David Wolfskill To: Steve Kargl Subject: Re: who broke dtrace and buildworld? Message-ID: <20150118174331.GC1059@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Steve Kargl , Steven Hartland , freebsd-current@freebsd.org References: <20150117235447.GA13490@troutmask.apl.washington.edu> <20150118002246.GA13599@troutmask.apl.washington.edu> <54BB0EF9.3060705@multiplay.co.uk> <20150118014456.GA13973@troutmask.apl.washington.edu> <54BB160B.1070106@multiplay.co.uk> <20150118023559.GA14178@troutmask.apl.washington.edu> <54BB2942.2040400@multiplay.co.uk> <20150118070205.GA14993@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ABTtc+pdwF7KHXCz" Content-Disposition: inline In-Reply-To: <20150118070205.GA14993@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org, Steven Hartland X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 18 Jan 2015 17:43:35 -0000 --ABTtc+pdwF7KHXCz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 17, 2015 at 11:02:05PM -0800, Steve Kargl wrote: > ... > Must be a problem with updating from a circa early December 2014 > world to 277300. My newest attempt completed as expected. Have > no idea what caused th build failure, but it appears "fixed". > .... Given my experience, I believe that plausible: I didn't see an issue; a history of (recent) sanpshots of head/i386 I've built successfully on my laptop may be found at . Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ABTtc+pdwF7KHXCz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUu/DDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7mYMP/1X/dfDXaBEzTSljKKRS5qWr Hk9pHFAbeX3zEy1DDsyjRRxTEWhtN+TCb07QeuJjs7rjx80Y5DztBUL/KnFmw122 G5M/OzHKKDPv6WInwwFD6eMsYt/CauIwOF7PNdmpv8xCNpcUzMxoaT0q4acJYWWq 4vXPH/lKFPf4mJMN28iShJ+o4DM3GHMwHBJymUDhiNf5rKbwiwBAkXGIn6WnicZk 9zr6KiLmBgtB95QjNoymNHdmeAnmxmLGlIRWAfMhcTYkR/8OkXSydJgELDoCgwf2 2gsPSMt4YuU4a4y5yNKK78N2HhgV0CHSJnU3+PxhZbXp0WkWDt2CFIyn1HiYNMFM tVtQLmrCgFKDXY19rXCqv3GImBuWJgw6hjys0L4hp8Jdp3jTIsJTYfDWOQCJYh9c tNfjspL2kFOnpWTBYh6n5IuV+UWn9bNSPFM8cprGl5q1pjpaYyTv6RULYtkKpkSP ED6WUq0fuDHXNy1jBbK5UDKUrJGVP1d10aF9Mosl4P6+zn4I9AdTtzGIoGV7L+0T nixfaRVP8Ac1p+Vf9EYhiVK6WqvOTkbhsV4aXgA4rwSZYKQv6f3/tlV+Px07urqr YnYqylKTAxpbMiess5b1kCFuB6684HSWol+YDjSVAARmgt9dQ0fOZwO3DowQ15rg Uhim7eLf8PeMsOGuX+Gb =J9gj -----END PGP SIGNATURE----- --ABTtc+pdwF7KHXCz-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 06:21:44 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 636A0754; Mon, 19 Jan 2015 06:21:44 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 51F75A15; Mon, 19 Jan 2015 06:21:44 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5FEC52EF; Mon, 19 Jan 2015 06:21:33 +0000 (UTC) Date: Mon, 19 Jan 2015 06:21:29 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, pfg@FreeBSD.org, marcel@FreeBSD.org Message-ID: <1931708268.17.1421648490340.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2241 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Jan 2015 06:21:44 -0000 See Changes: [pfg] ext2: Garbage-collect some unused variables Reported by:=09clang static analysis MFC after:=092 weeks [marcel] Upgrade libxo to 0.2.0. Obtained from:=09https://github.com/Juniper/libxo Requested by: Phil Shafer Revisions 276253 & 276273 were incorporated into 0.2.0. Revision 276260 has been merged-in. ------------------------------------------ [...truncated 267589 lines...] awk -f exca.ko.debug export_syms | xargs -J% objcopy % exca.ko.debug --- exca.ko.symbols --- objcopy --only-keep-debug exca.ko.debug exca.ko.symbols --- exca.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dexca.ko.symbols exca.ko.debug e= xca.ko --- all_subdir_drm --- --- sis_mm.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- exsystem.o --- ctfconvert -L VERSION -g exsystem.o --- exutils.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -Wall -Wredundant-decls -Wnested-= externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-inclu= de-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautolo= gical-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-e= rror-unused-function -Wno-error-pointer-sign -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mc= model=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchron= ous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -Wno-error-tau= tological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -W= no-error-unused-function -Wno-error-pointer-sign -Wall -Wredundant-decls -= Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error= -tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equalit= y -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -= std=3Diso9899:1999 -Werror --- modules-all --- --- sis_ds.o --- ctfconvert -L VERSION -g sis_ds.o --- all_subdir_ext2fs --- --- all_subdir_drm2 --- --- intel_bios.o --- ctfconvert -L VERSION -g intel_bios.o --- all_subdir_ext2fs --- =3D=3D=3D> ext2fs (all) --- ext2_alloc.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm2 --- --- intel_crt.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- exutils.o --- ctfconvert -L VERSION -g exutils.o --- modules-all --- --- all_subdir_ext2fs --- --- ext2_balloc.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm --- --- sis_mm.o --- ctfconvert -L VERSION -g sis_mm.o --- sis.ko.debug --- ld -d -warn-common -r -d -o sis.ko.debug sis_drv.o sis_ds.o sis_mm.o ctfmerge -L VERSION -g -o sis.ko.debug sis_drv.o sis_ds.o sis_mm.o :> export_syms awk -f sis.ko.debug export_syms | xargs -J% objcopy % sis.ko.debug --- sis.ko.symbols --- objcopy --only-keep-debug sis.ko.debug sis.ko.symbols --- sis.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dsis.ko.symbols sis.ko.debug sis= .ko =3D=3D=3D> drm/tdfx (all) --- tdfx_drv.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_ext2fs --- ctfconvert -L VERSION -g ext2_balloc.o --- hwacpi.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -Wall -Wredundant-decls -Wnested-= externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-inclu= de-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautolo= gical-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-e= rror-unused-function -Wno-error-pointer-sign -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mc= model=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchron= ous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -Wno-error-tau= tological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -W= no-error-unused-function -Wno-error-pointer-sign -Wall -Wredundant-decls -= Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error= -tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equalit= y -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -= std=3Diso9899:1999 -Werror --- modules-all --- --- all_subdir_drm2 --- ctfconvert -L VERSION -g intel_crt.o --- all_subdir_ext2fs --- --- ext2_alloc.o --- ctfconvert -L VERSION -g ext2_alloc.o --- hwacpi.o --- ctfconvert -L VERSION -g hwacpi.o --- modules-all --- --- all_subdir_fatm --- =3D=3D=3D> fatm (all) --- all_subdir_drm2 --- --- intel_display.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_fatm --- --- if_fatm.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_ext2fs --- --- ext2_bmap.o --- --- all_subdir_drm --- ctfconvert -L VERSION -g tdfx_drv.o --- all_subdir_ext2fs --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm --- --- tdfx.ko.debug --- ld -d -warn-common -r -d -o tdfx.ko.debug tdfx_drv.o ctfmerge -L VERSION -g -o tdfx.ko.debug tdfx_drv.o :> export_syms awk -f tdfx.ko.debug export_syms | xargs -J% objcopy % tdfx.ko.debug --- tdfx.ko.symbols --- objcopy --only-keep-debug tdfx.ko.debug tdfx.ko.symbols --- tdfx.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dtdfx.ko.symbols tdfx.ko.debug t= dfx.ko =3D=3D=3D> drm/via (all) --- via_dma.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -Wno-unused-value -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_ext2fs --- ctfconvert -L VERSION -g ext2_bmap.o --- ext2_extents.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm2 --- :6547:12: warning: comparison of addr= ess of 'obj->base' equal to a null pointer is always false [-Wtautological-= pointer-compare] if (&obj->base =3D=3D NULL) ~~~~~^~~~ ~~~~ --- all_subdir_ext2fs --- ctfconvert -L VERSION -g ext2_extents.o --- all_subdir_drm2 --- :8053:12: warning: comparison of addr= ess of 'obj->base' equal to a null pointer is always false [-Wtautological-= pointer-compare] if (&obj->base =3D=3D NULL) ~~~~~^~~~ ~~~~ --- all_subdir_ext2fs --- --- ext2_hash.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm --- ctfconvert -L VERSION -g via_dma.o --- via_dmablit.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -Wno-unused-value -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_ext2fs --- ctfconvert -L VERSION -g ext2_hash.o --- ext2_htree.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm --- ctfconvert -L VERSION -g via_dmablit.o --- via_drv.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_ext2fs --- ctfconvert -L VERSION -g ext2_htree.o --- ext2_inode.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_fatm --- ctfconvert -L VERSION -g if_fatm.o --- all_subdir_drm --- ctfconvert -L VERSION -g via_drv.o --- all_subdir_fatm --- --- if_fatm.ko.debug --- ld -d -warn-common -r -d -o if_fatm.ko.debug if_fatm.o --- all_subdir_drm --- --- via_irq.o --- --- all_subdir_fatm --- ctfmerge -L VERSION -g -o if_fatm.ko.debug if_fatm.o --- all_subdir_drm --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_fatm --- :> export_syms awk -f if_fatm.ko.debug export_syms | xargs -J% objcopy % if_fatm.ko.debug --- if_fatm.ko.symbols --- objcopy --only-keep-debug if_fatm.ko.debug if_fatm.ko.symbols --- if_fatm.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dif_fatm.ko.symbols if_fatm.ko.d= ebug if_fatm.ko --- hwesleep.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -Wall -Wredundant-decls -Wnested-= externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-inclu= de-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautolo= gical-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-e= rror-unused-function -Wno-error-pointer-sign -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mc= model=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchron= ous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -Wno-error-tau= tological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -W= no-error-unused-function -Wno-error-pointer-sign -Wall -Wredundant-decls -= Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error= -tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equalit= y -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -= std=3Diso9899:1999 -Werror ctfconvert -L VERSION -g hwesleep.o --- modules-all --- --- all_subdir_drm2 --- --- intel_dp.o --- --- all_subdir_ext2fs --- :337:10: error: use of undeclared identifier 'bo' BO_LOCK(bo); ^ :118:43: = note: expanded from macro 'BO_LOCK' #define BO_LOCK(bo) rw_wlock(BO_LOCKPTR((bo))) ^ :117:28: = note: expanded from macro 'BO_LOCKPTR' #define BO_LOCKPTR(bo) (&(bo)->bo_lock) ^ :194:34: = note: expanded from macro 'rw_wlock' #define rw_wlock(rw) _rw_wlock((rw), LOCK_FILE, LOCK_LINE) ^ :161:21: = note: expanded from macro '_rw_wlock' _rw_wlock_cookie(&(rw)->rw_lock, f, l) ^ :338:22: error: use of undeclared identifier 'bo' if (length =3D=3D 0 && (bo->bo_dirty.bv_cnt !=3D 0 || ^ --- all_subdir_drm2 --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_ext2fs --- :339:6: error: use of undeclared identifier 'bo' bo->bo_clean.bv_cnt !=3D 0)) ^ :341:12: error: use of undeclared identifier 'bo' BO_UNLOCK(bo); ^ :119:47: = note: expanded from macro 'BO_UNLOCK' #define BO_UNLOCK(bo) rw_wunlock(BO_LOCKPTR((bo))) ^ :117:28: = note: expanded from macro 'BO_LOCKPTR' #define BO_LOCKPTR(bo) (&(bo)->bo_lock) ^ :195:38: = note: expanded from macro 'rw_wunlock' #define rw_wunlock(rw) _rw_wunlock((rw), LOCK_FILE, LOCK_LINE) ^ :165:23: = note: expanded from macro '_rw_wunlock' _rw_wunlock_cookie(&(rw)->rw_lock, f, l) ^ 4 errors generated. *** [ext2_inode.o] Error code 1 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_ext2fs] Error code 2 make[3]: stopped in --- all_subdir_drm --- ctfconvert -L VERSION -g via_irq.o A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_drm] Error code 2 make[3]: stopped in --- all_subdir_drm2 --- ctfconvert -L VERSION -g intel_dp.o --- intel_display.o --- 2 warnings generated. ctfconvert -L VERSION -g intel_display.o A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_drm2] Error code 2 make[3]: stopped in 3 errors make[3]: stopped in *** [modules-all] Error code 2 make[2]: stopped in /usr/obj 1 error make[2]: stopped in /usr/obj *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 07:58:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1C917BF; Mon, 19 Jan 2015 07:58:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 9D60A341; Mon, 19 Jan 2015 07:58:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5E434657; Mon, 19 Jan 2015 07:58:57 +0000 (UTC) Date: Mon, 19 Jan 2015 07:58:55 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, ian@FreeBSD.org, pfg@FreeBSD.org, nwhitehorn@FreeBSD.org, ngie@FreeBSD.org, marcel@FreeBSD.org Message-ID: <1006369496.18.1421654337355.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1931708268.17.1421648490340.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1931708268.17.1421648490340.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2242 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Jan 2015 07:58:58 -0000 See Changes: [ngie] Integrate contrib/netbsd-tests/bin/expr into the build/kyua as bin/e= xpr/tests MFC after: 1 week Sponsored by: EMC / Isilon Storage Division [ngie] Expect :overflow to fail with FreeBSD's expr as it doesn't have stri= ngent overflow checks like NetBSD's expr does MFC after: 3 days PR: 196867 [nwhitehorn] Provide a tunable (machdep.moea64_bpvo_pool_size) to set the b= ootstrap PVO pool size. The default errs on the exceedingly large side, so absent any intelligent automatic tuning, at least let the user set it to save RAM on memory-constrained systems. MFC after:=092 weeks [ian] For armv6 builds, add -mfloat-abi=3Dsoftfp. This tells the compiler = it can use floating point hardware instructions (because all armv6/7 systems we support have fp hardware), but it passes args using a soft-float compatible ABI. This should give noticible performance improvement (but not as much as using the armv6hf arch). ------------------------------------------ [...truncated 265683 lines...] ctfconvert -L VERSION -g intel_display.o --- all_subdir_drm --- --- via_mm.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm2 --- --- intel_hdmi.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_exca --- ctfconvert -L VERSION -g exca.o --- exca.ko.debug --- ld -d -warn-common -r -d -o exca.ko.debug exca.o ctfmerge -L VERSION -g -o exca.ko.debug exca.o :> export_syms awk -f exca.ko.debug export_syms | xargs -J% objcopy % exca.ko.debug --- exca.ko.symbols --- objcopy --only-keep-debug exca.ko.debug exca.ko.symbols --- exca.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dexca.ko.symbols exca.ko.debug e= xca.ko --- exstoren.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -Wall -Wredundant-decls -Wnested-= externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-inclu= de-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautolo= gical-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-e= rror-unused-function -Wno-error-pointer-sign -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mc= model=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchron= ous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -Wno-error-tau= tological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -W= no-error-unused-function -Wno-error-pointer-sign -Wall -Wredundant-decls -= Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error= -tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equalit= y -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -= std=3Diso9899:1999 -Werror --- modules-all --- --- all_subdir_drm --- ctfconvert -L VERSION -g via_mm.o --- via_verifier.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- exstoren.o --- ctfconvert -L VERSION -g exstoren.o --- modules-all --- --- all_subdir_ext2fs --- =3D=3D=3D> ext2fs (all) --- ext2_alloc.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm2 --- ctfconvert -L VERSION -g intel_hdmi.o --- intel_lvds.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -Wno-unused -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_et --- ctfconvert -L VERSION -g if_et.o --- if_et.ko.debug --- ld -d -warn-common -r -d -o if_et.ko.debug if_et.o ctfmerge -L VERSION -g -o if_et.ko.debug if_et.o :> export_syms awk -f if_et.ko.debug export_syms | xargs -J% objcopy % if_et.ko.debug --- if_et.ko.symbols --- objcopy --only-keep-debug if_et.ko.debug if_et.ko.symbols --- if_et.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dif_et.ko.symbols if_et.ko.debug= if_et.ko --- all_subdir_fatm --- =3D=3D=3D> fatm (all) --- if_fatm.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm --- ctfconvert -L VERSION -g via_verifier.o --- via_video.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_ext2fs --- ctfconvert -L VERSION -g ext2_alloc.o --- ext2_balloc.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm2 --- ctfconvert -L VERSION -g intel_lvds.o --- intel_modes.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm --- ctfconvert -L VERSION -g via_video.o --- via.ko.debug --- ld -d -warn-common -r -d -o via.ko.debug via_dma.o via_dmablit.o via_drv.o = via_irq.o via_map.o via_mm.o via_verifier.o via_video.o ctfmerge -L VERSION -g -o via.ko.debug via_dma.o via_dmablit.o via_drv.o vi= a_irq.o via_map.o via_mm.o via_verifier.o via_video.o :> export_syms awk -f via.ko.debug export_syms | xargs -J% objcopy % via.ko.debug --- via.ko.symbols --- objcopy --only-keep-debug via.ko.debug via.ko.symbols --- via.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dvia.ko.symbols via.ko.debug via= .ko --- exstorob.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -Wall -Wredundant-decls -Wnested-= externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-inclu= de-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautolo= gical-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-e= rror-unused-function -Wno-error-pointer-sign -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mc= model=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchron= ous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -Wno-error-tau= tological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -W= no-error-unused-function -Wno-error-pointer-sign -Wall -Wredundant-decls -= Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error= -tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equalit= y -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -= std=3Diso9899:1999 -Werror --- modules-all --- --- all_subdir_ext2fs --- ctfconvert -L VERSION -g ext2_balloc.o --- ext2_bmap.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- exstorob.o --- ctfconvert -L VERSION -g exstorob.o --- modules-all --- --- ext2_extents.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm2 --- ctfconvert -L VERSION -g intel_modes.o --- intel_overlay.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_ext2fs --- --- ext2_bmap.o --- ctfconvert -L VERSION -g ext2_bmap.o --- all_subdir_fdc --- =3D=3D=3D> fdc (all) --- all_subdir_ext2fs --- --- ext2_extents.o --- ctfconvert -L VERSION -g ext2_extents.o --- all_subdir_fdc --- --- fdc.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_ext2fs --- --- ext2_hash.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm2 --- :1147:15: warning: comparison of addr= ess of 'new_bo->base' equal to a null pointer is always false [-Wtautologic= al-pointer-compare] if (&new_bo->base =3D=3D NULL) { ~~~~~~~~^~~~ ~~~~ --- all_subdir_ext2fs --- ctfconvert -L VERSION -g ext2_hash.o --- ext2_htree.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_fatm --- ctfconvert -L VERSION -g if_fatm.o --- if_fatm.ko.debug --- ld -d -warn-common -r -d -o if_fatm.ko.debug if_fatm.o ctfmerge -L VERSION -g -o if_fatm.ko.debug if_fatm.o :> export_syms awk -f if_fatm.ko.debug export_syms | xargs -J% objcopy % if_fatm.ko.debug --- if_fatm.ko.symbols --- objcopy --only-keep-debug if_fatm.ko.debug if_fatm.ko.symbols --- if_fatm.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dif_fatm.ko.symbols if_fatm.ko.d= ebug if_fatm.ko --- exsystem.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -Wall -Wredundant-decls -Wnested-= externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-inclu= de-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautolo= gical-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-e= rror-unused-function -Wno-error-pointer-sign -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mc= model=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchron= ous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -Wno-error-tau= tological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -W= no-error-unused-function -Wno-error-pointer-sign -Wall -Wredundant-decls -= Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error= -tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equalit= y -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -= std=3Diso9899:1999 -Werror --- modules-all --- --- all_subdir_drm2 --- 1 warning generated. ctfconvert -L VERSION -g intel_overlay.o --- intel_panel.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- exsystem.o --- ctfconvert -L VERSION -g exsystem.o --- modules-all --- --- all_subdir_fdc --- --- fdc_isa.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_ext2fs --- ctfconvert -L VERSION -g ext2_htree.o --- ext2_inode.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_fdc --- --- fdc.o --- ctfconvert -L VERSION -g fdc.o --- all_subdir_ext2fs --- --- ext2_inode_cnv.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_fdc --- --- fdc_isa.o --- ctfconvert -L VERSION -g fdc_isa.o --- fdc_pccard.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -I/usr/obj -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msof= t-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -= gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-= parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-proto= types -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -ffor= mat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn= own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-er= ror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sig= n -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_ext2fs --- --- ext2_inode.o --- :337:10: error: use of undeclared identifier 'bo' BO_LOCK(bo); ^ :118:43: = note: expanded from macro 'BO_LOCK' #define BO_LOCK(bo) rw_wlock(BO_LOCKPTR((bo))) ^ :117:28: = note: expanded from macro 'BO_LOCKPTR' #define BO_LOCKPTR(bo) (&(bo)->bo_lock) ^ :194:34: = note: expanded from macro 'rw_wlock' #define rw_wlock(rw) _rw_wlock((rw), LOCK_FILE, LOCK_LINE) ^ :161:21: = note: expanded from macro '_rw_wlock' _rw_wlock_cookie(&(rw)->rw_lock, f, l) ^ :338:22: error: use of undeclared identifier 'bo' if (length =3D=3D 0 && (bo->bo_dirty.bv_cnt !=3D 0 || ^ :339:6: error: use of undeclared identifier 'bo' bo->bo_clean.bv_cnt !=3D 0)) ^ :341:12: error: use of undeclared identifier 'bo' BO_UNLOCK(bo); ^ :119:47: = note: expanded from macro 'BO_UNLOCK' #define BO_UNLOCK(bo) rw_wunlock(BO_LOCKPTR((bo))) ^ :117:28: = note: expanded from macro 'BO_LOCKPTR' #define BO_LOCKPTR(bo) (&(bo)->bo_lock) ^ :195:38: = note: expanded from macro 'rw_wunlock' #define rw_wunlock(rw) _rw_wunlock((rw), LOCK_FILE, LOCK_LINE) ^ :165:23: = note: expanded from macro '_rw_wunlock' _rw_wunlock_cookie(&(rw)->rw_lock, f, l) ^ 4 errors generated. *** [ext2_inode.o] Error code 1 make[4]: stopped in --- ext2_inode_cnv.o --- ctfconvert -L VERSION -g ext2_inode_cnv.o 1 error make[4]: stopped in *** [all_subdir_ext2fs] Error code 2 make[3]: stopped in --- all_subdir_drm2 --- ctfconvert -L VERSION -g intel_panel.o --- all_subdir_fdc --- ctfconvert -L VERSION -g fdc_pccard.o --- all_subdir_drm2 --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- all_subdir_fdc --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_fdc] Error code 2 make[3]: stopped in --- all_subdir_drm2 --- *** [all_subdir_drm2] Error code 2 make[3]: stopped in 3 errors make[3]: stopped in *** [modules-all] Error code 2 make[2]: stopped in /usr/obj 1 error make[2]: stopped in /usr/obj *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 08:40:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B5B424D for ; Mon, 19 Jan 2015 08:40:53 +0000 (UTC) Received: from eu1sys200aog126.obsmtp.com (eu1sys200aog126.obsmtp.com [207.126.144.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E5AA96F for ; Mon, 19 Jan 2015 08:40:51 +0000 (UTC) Received: from mail-wg0-f51.google.com ([74.125.82.51]) (using TLSv1) by eu1sys200aob126.postini.com ([207.126.147.11]) with SMTP ID DSNKVLzC9/pdJ7F0X6qRXzIEFNsS41mZMx4a@postini.com; Mon, 19 Jan 2015 08:40:52 UTC Received: by mail-wg0-f51.google.com with SMTP id l18so8319225wgh.10 for ; Mon, 19 Jan 2015 00:40:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=56rXmqLQIBlaJjBaRG5lMxo3SF28KIY0cQfDiUYMfVs=; b=Mu+hp1eDYRhpPI7ax8RHcMT831OwoaDzbv3KokZmEj0jJekLkhp1vacPjJuyMRDuY6 z+4jJwB8HqiCq6HR0YSSbGJrhqRK2/X+GfMqAnrA1WuHZ++QOZWOPQ25RZSVD3Wsiwjk Xbtpw0V4KJbx6bmkLXfX+VpcKqQTHYh3Gdvz1HWU4bQSF/nXH3R4UbKz5i8esvn5XfGj Y4JyL9Df9YDNoLAGD5zhPqMuOUjgwJpx+wIzYIIUhf5KZSevFT8zSUxmy9nOX8C0pg2Z H5ntrwMP17dUj+/hxozHxjJJvyxL16yQOwOel4bUuXRoazgWhsLigFj72a4De0P81+xs PeGA== X-Gm-Message-State: ALoCoQn8GD0IpEmaW6RwrFjD6vxLo4W6Uc5GiDUMKgYVvO2EFFkyM7BS/gAsR3n7TDaFfYgVs77Nxr7s5b3UXLl3MoQ0q1qI8heDgdIlLexsDfSOT285oo/2y5Om2+JAmC0F7ypl6fUAJwi2XvhKquuLkXCZZFH2nQ== X-Received: by 10.194.175.102 with SMTP id bz6mr55605097wjc.120.1421656823871; Mon, 19 Jan 2015 00:40:23 -0800 (PST) X-Received: by 10.194.175.102 with SMTP id bz6mr55605084wjc.120.1421656823770; Mon, 19 Jan 2015 00:40:23 -0800 (PST) Received: from mech-as221.men.bris.ac.uk (mech-as221.men.bris.ac.uk. [137.222.187.221]) by mx.google.com with ESMTPSA id hz9sm16377532wjb.17.2015.01.19.00.40.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 00:40:23 -0800 (PST) Date: Mon, 19 Jan 2015 00:40:23 -0800 (PST) X-Google-Original-Date: Mon, 19 Jan 2015 08:40:21 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t0J8eLKN046378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Jan 2015 08:40:22 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t0J8eLtW046377; Mon, 19 Jan 2015 08:40:21 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201501190840.t0J8eLtW046377@mech-as221.men.bris.ac.uk> To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: old bug: mount_nfs path/name is limited to 88 chars Reply-To: mexas@bris.ac.uk X-Mailman-Approved-At: Mon, 19 Jan 2015 12:07:13 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Jan 2015 08:40:53 -0000 This bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 is a show stopper for me. The path/name length is beyond my control, so I cannot make it shorter. This discussion seems inconclusive: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html Is there no easy solution to this PR? Or is there no interest in fixing the issue? Thanks Anton From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 12:46:19 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4650F3F6; Mon, 19 Jan 2015 12:46:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3346E7A3; Mon, 19 Jan 2015 12:46:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 89FC4D47; Mon, 19 Jan 2015 12:46:19 +0000 (UTC) Date: Mon, 19 Jan 2015 12:46:14 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, ian@FreeBSD.org, neel@FreeBSD.org, pfg@FreeBSD.org, nwhitehorn@FreeBSD.org, ngie@FreeBSD.org, hselasky@FreeBSD.org, marcel@FreeBSD.org Message-ID: <331371279.20.1421671578905.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1006369496.18.1421654337355.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1006369496.18.1421654337355.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #2243 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Jan 2015 12:46:19 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 15:33:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C7D3CB0; Mon, 19 Jan 2015 15:33:54 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B66B3D16; Mon, 19 Jan 2015 15:33:53 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAIgivVSDaFve/2dsb2JhbABbDoNKXIMCwzYMhSVKAoFlAQEBAQF9hAwBAQEDAQEBASArIAsFFhgCAg0ZAikBCSYOBwQBGgIEiAMIDbsClAMBAQEBAQEEAQEBAQEBAQEagSGOAAcBARs0BxaCUoFBBYl1iCuDMoNoiFCIECKDMVsgMQEGfAkXIn4BAQE X-IronPort-AV: E=Sophos;i="5.09,427,1418101200"; d="scan'208";a="184802784" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 19 Jan 2015 10:32:45 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B573F3CE1D; Mon, 19 Jan 2015 10:32:44 -0500 (EST) Date: Mon, 19 Jan 2015 10:32:44 -0500 (EST) From: Rick Macklem To: mexas@bris.ac.uk Message-ID: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> In-Reply-To: <201501190840.t0J8eLtW046377@mech-as221.men.bris.ac.uk> Subject: Re: old bug: mount_nfs path/name is limited to 88 chars MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Jan 2015 15:33:54 -0000 Anton Shterenlikht wrote: > This bug: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 > > is a show stopper for me. The path/name length is > beyond my control, so I cannot make it shorter. > > This discussion seems inconclusive: > http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html > > Is there no easy solution to this PR? > Or is there no interest in fixing the issue? > Well, the "easy" solution is to just increase the value of NNAMELEN and rebuild everything from sources to use the modified sys/mount.h. (If you can run a modified system built entirely from sources, I think you can do this.) However, this can't be done in -current because it breaks the statfs(2) syscall API, etc. There is a patch in projects/ino64 to try and change ino_t to 64bits and I think it also included changes for this. - It would need a new statfs(2) syscall and versioned library routines for everything that uses statfs(2) in libc, etc. So, for -current the answer is "it is not easy". There was a patch floating around that truncated the path to 64bits, so that the mounts are allowed but not reported correctly via statfs(2). You can probably find that patch and use it, if a broken statfs(2) isn't a problem for you. rick > Thanks > > Anton > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 15:44:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAC5B14F for ; Mon, 19 Jan 2015 15:44:56 +0000 (UTC) Received: from eu1sys200aog107.obsmtp.com (eu1sys200aog107.obsmtp.com [207.126.144.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37A7BE53 for ; Mon, 19 Jan 2015 15:44:55 +0000 (UTC) Received: from mail-wg0-f41.google.com ([74.125.82.41]) (using TLSv1) by eu1sys200aob107.postini.com ([207.126.147.11]) with SMTP ID DSNKVL0mWxRfbeWzDUaFv3BDJDE0cOXm56r4@postini.com; Mon, 19 Jan 2015 15:44:56 UTC Received: by mail-wg0-f41.google.com with SMTP id a1so10406527wgh.0 for ; Mon, 19 Jan 2015 07:44:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=uLxEH5gZKkQiG0ubkpNIPNitqdX30K3K77ARhESEA1k=; b=aIEJz0d1daeXPysLf4GHu9inPUyREm/3UNV6opQKJFLl0WoOB4yvKDSJq+nm3LXFnR 6gRrq3NHy2Si5Tp4fUUtvcDAFFGsr4Ly+QTsh1tlDTLGDqL4rc376llA8UykdQwGarNg r/R++tn0XtIStWmk2RiizpigYPgGlQktkmYJIhmNuB3Apj1g80XQTgYm5h+AP5lsb4BB Ulj+Uy81y+9fIKr11OLNNt66qVBlrMlIVU5/RRNJtxDAslsnvEiKh7KYCrBkxLTMZCwS 4cdfQkrTBdNMpCcIPQTA8RB1B46hDNGaOM+O7G801ppHpcAqyVyj5mLLwPorIsvPStxp /0Ww== X-Gm-Message-State: ALoCoQkg/TL/2FPh4vOxW2ifIPAi8WgsJeQa/6KmEVPHnvLu+pKMSQ1kK5D/v/1i7vR4duuM7Sos/X+qhjf+Qqb4G1R8ID8bp/MBg1TcF7vnePpVhnFs8xPerRKFsQ/t3yEKuUNvdpkWyshtIdk+iRupMSAduU8rLQ== X-Received: by 10.194.93.194 with SMTP id cw2mr61372677wjb.21.1421682267739; Mon, 19 Jan 2015 07:44:27 -0800 (PST) X-Received: by 10.194.93.194 with SMTP id cw2mr61372659wjb.21.1421682267598; Mon, 19 Jan 2015 07:44:27 -0800 (PST) Received: from mech-as221.men.bris.ac.uk (mech-as221.men.bris.ac.uk. [137.222.187.221]) by mx.google.com with ESMTPSA id gl11sm17714192wjc.40.2015.01.19.07.44.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 07:44:26 -0800 (PST) Date: Mon, 19 Jan 2015 07:44:26 -0800 (PST) X-Google-Original-Date: Mon, 19 Jan 2015 15:44:25 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t0JFiP9r027957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Jan 2015 15:44:25 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t0JFiP7O027952; Mon, 19 Jan 2015 15:44:25 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> To: mexas@bris.ac.uk, rmacklem@uoguelph.ca Subject: Re: old bug: mount_nfs path/name is limited to 88 chars Reply-To: mexas@bris.ac.uk In-Reply-To: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Jan 2015 15:44:57 -0000 >From rmacklem@uoguelph.ca Mon Jan 19 15:37:25 2015 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 >> >> is a show stopper for me. The path/name length is >> beyond my control, so I cannot make it shorter. >> >> This discussion seems inconclusive: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html >> >> Is there no easy solution to this PR? >> Or is there no interest in fixing the issue? >> >Well, the "easy" solution is to just increase the value >of NNAMELEN and rebuild everything from sources to use >the modified sys/mount.h. (If you can run a modified >system built entirely from sources, I think you can do >this.) I can do this on several 10.1-stable systems, but I understood from the email trail that there is no guarantee that nothing will be broken by such change. I know there is never a guarantee, but.. >However, this can't be done in -current because it breaks >the statfs(2) syscall API, etc. Even on 10.1-stable I see in statfs(2): #define MNAMELEN 88 /* size of on/from name bufs */ So perhaps changing MNAMELEN will break statfs(2) on -stable too? Anton From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 16:47:01 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9434205; Mon, 19 Jan 2015 16:47:01 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B2117E0; Mon, 19 Jan 2015 16:47:01 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id x12so4354429wgg.7; Mon, 19 Jan 2015 08:46:58 -0800 (PST) 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=1TXqEoqHQ9LNf1/uPnum6o0Ph51eOFeal0xweSWxa44=; b=c7JjShL4ul3WGPL9t/sehuJ/FV6zgyf4Pay4lqMni7GdZ5V6+3NCbIsdyw76wDW3k8 BMXrymOX+x7ukhRv+TyMi3quuThjwWu92cJsCYZn4RQn2KcmaQ6iE7dvUMQ9uNn1j+Ov LM4Jdyilptmhi79O4scb/lMOsbu8kxwzLgb5F/e7e1TCOPQzaJN7465p+pqXkmAHW59o PNGkFO8ztPRPG4GtJhFwY13A96/Ynm0ba3fAkvuFUyc+4kykqF8YzWj5p3jCjtyRH9Jd /P2eNqzlyOYqHM65+8PpgKr6SF5M5ZeXD2Fw2tVBBaggRapUVejkyEwboJwvNkU5YLij 3ung== MIME-Version: 1.0 X-Received: by 10.180.83.5 with SMTP id m5mr1497361wiy.74.1421686017235; Mon, 19 Jan 2015 08:46:57 -0800 (PST) Received: by 10.216.69.193 with HTTP; Mon, 19 Jan 2015 08:46:57 -0800 (PST) In-Reply-To: <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> Date: Mon, 19 Jan 2015 11:46:57 -0500 Message-ID: Subject: Re: old bug: mount_nfs path/name is limited to 88 chars From: Brandon Allbery To: mexas@bris.ac.uk X-Mailman-Approved-At: Mon, 19 Jan 2015 17:20:16 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: rmacklem@uoguelph.ca, freebsd-stable , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Jan 2015 16:47:01 -0000 On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht wrote: > So perhaps changing MNAMELEN will break statfs(2) on > -stable too? > I believe the context there is not so much "-current is special", as "changing it for everyone is bad news" (and this would necessarily need to originate in -current). -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 19:40:16 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A109F575; Mon, 19 Jan 2015 19:40:16 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 66875D1A; Mon, 19 Jan 2015 19:40:16 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id D2044129; Mon, 19 Jan 2015 14:40:13 -0500 (EST) Message-ID: <54BD5D99.8000200@protected-networks.net> Date: Mon, 19 Jan 2015 14:40:09 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: zi@freebsd.org Subject: SVN r377448 breaks net-snmp on -current OpenPGP: id=0442D492 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i6Pfdt79CmVOJaLaInAMeuKVk6vKVqEq2" Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Jan 2015 19:40:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i6Pfdt79CmVOJaLaInAMeuKVk6vKVqEq2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Apparently, there was some 'magic' to accessing these sysctls: libtool: link: cc -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -O2 -pipe -march=3Dpentium4 -I/usr/local/include -I/include -D_WANT_IFADDR -fstack-protector -fno-strict-aliasing -Ufreebsd11 -Dfreebsd11=3Dfreebsd1= 1 -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/usr/local/lib/perl5/5.18/mach/CORE -o .libs/snmpd .libs/snmpd.o -Wl,-R/usr/local/lib/perl5/5.18/mach/CORE -L/usr/lib -L/lib =2E/.libs/libnetsnmpagent.so -L/usr/local/lib -L/usr/local/lib/perl5/5.18/mach/CORE ./.libs/libnetsnmpmibs.so /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/agent/.libs/libnetsnmpag= ent.so /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/snmplib/.libs/libnetsnmp= =2Eso =2E./snmplib/.libs/libnetsnmp.so -lpkg -lwrap -lperl -lcrypt -lutil -lelf= -lssp_nonshared -lm -lkvm -ldevstat -lcrypto -pthread -Wl,-rpath -Wl,/usr/local/lib =2E/.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp_sta= t' =2E/.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp6_st= at' =2E/.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp6_msg_stat' =2E/.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp_msg_stat' cc: error: linker command failed with exit code 1 (use -v to see invocati= on) *** Error code 1 imb --i6Pfdt79CmVOJaLaInAMeuKVk6vKVqEq2 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 iEYEARECAAYFAlS9XZwACgkQQv9rrgRC1JJfRwCcDI8PhoHYznXI4b7tXIncbkEO 4SYAoI/SkONR8GYIhCUpiHWo5JliVNMr =zHS2 -----END PGP SIGNATURE----- --i6Pfdt79CmVOJaLaInAMeuKVk6vKVqEq2-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 19:56:50 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB958ED5; Mon, 19 Jan 2015 19:56:50 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D963EF0; Mon, 19 Jan 2015 19:56:50 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1YDINx-002iu6-Er>; Mon, 19 Jan 2015 20:53:17 +0100 Received: from g225050067.adsl.alicedsl.de ([92.225.50.67] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1YDINx-000dS6-AS>; Mon, 19 Jan 2015 20:53:17 +0100 Date: Mon, 19 Jan 2015 20:53:16 +0100 From: "O. Hartmann" To: Michael Butler Subject: Re: SVN r377448 breaks net-snmp on -current Message-ID: <20150119205316.2f5880d6.ohartman@zedat.fu-berlin.de> In-Reply-To: <54BD5D99.8000200@protected-networks.net> References: <54BD5D99.8000200@protected-networks.net> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/=PSqsp6bzoRQEzlJL5V7Cn/"; protocol="application/pgp-signature" X-Originating-IP: 92.225.50.67 X-ZEDAT-Hint: A Cc: zi@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Jan 2015 19:56:50 -0000 --Sig_/=PSqsp6bzoRQEzlJL5V7Cn/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 19 Jan 2015 14:40:09 -0500 Michael Butler schrieb: > Apparently, there was some 'magic' to accessing these sysctls: >=20 > libtool: link: cc -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -O2 -pipe > -march=3Dpentium4 -I/usr/local/include -I/include -D_WANT_IFADDR > -fstack-protector -fno-strict-aliasing -Ufreebsd11 -Dfreebsd11=3Dfreebsd11 > -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe > -fstack-protector -I/usr/local/include > -I/usr/local/lib/perl5/5.18/mach/CORE -o .libs/snmpd .libs/snmpd.o > -Wl,-R/usr/local/lib/perl5/5.18/mach/CORE -L/usr/lib -L/lib > ./.libs/libnetsnmpagent.so -L/usr/local/lib > -L/usr/local/lib/perl5/5.18/mach/CORE ./.libs/libnetsnmpmibs.so > /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/agent/.libs/libnetsnmpag= ent.so > /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/snmplib/.libs/libnetsnmp= .so > ../snmplib/.libs/libnetsnmp.so -lpkg -lwrap -lperl -lcrypt -lutil -lelf > -lssp_nonshared -lm -lkvm -ldevstat -lcrypto -pthread -Wl,-rpath > -Wl,/usr/local/lib > ./.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp_stat' > ./.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp6_stat' > ./.libs/libnetsnmpmibs.so: undefined reference to > `sysctl_read_icmp6_msg_stat' > ./.libs/libnetsnmpmibs.so: undefined reference to > `sysctl_read_icmp_msg_stat' > cc: error: linker command failed with exit code 1 (use -v to see invocati= on) > *** Error code 1 >=20 > imb >=20 Me, too here. I just filed a PR: Bug 196904 - net-mgmt/net-snmp: undefined = reference to `sysctl_read_XXXXXX=20 oh --Sig_/=PSqsp6bzoRQEzlJL5V7Cn/ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUvWCsAAoJEOgBcD7A/5N8rs8H/2quzSqkyLsaVhudrIgmZuBS aKWrDLc7mNOJG94KouP2hhufGC9dy+Bz70go/H16/MyUQTOV89+ln3Y7S6oWRni3 84QxkXeCJ69lk+ZuN577SoGERuwJsbsZ7eaoEqGxk3ca6mXpjBAgzIvF5554NE2k pnKun5uQY0UGTx1pg/oszWtIXE8dxe6y4uym0+2HdoLwsRRSbbwqaedW8/b0g978 InTVIHl85jsQ8e5NRzeu9WQAY+eJGhStYRJ6utxaUs6J4E7lq1KBjylJGUOWlZIf WfSZ1XkVaLH+CckA7tVwOla/6EX0PjYe6Yst6S4P6OA0h2cxAkOKz1LxkJYOxMs= =LwZ0 -----END PGP SIGNATURE----- --Sig_/=PSqsp6bzoRQEzlJL5V7Cn/-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 21:20:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB51C1CB; Mon, 19 Jan 2015 21:20:41 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B095BAA0; Mon, 19 Jan 2015 21:20:41 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id ft15so9464277pdb.11; Mon, 19 Jan 2015 13:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IeUYPoeiGvVMNUppWcIStopwEqYZ9NJQOR4rqOAhuQI=; b=BrgSQ6ZditGzG5B6/w6DB7tJjKgfykAQ3TrYwsHPgYdN0XgK0M5t2EgCRNOo7EyuTy +QPhlJL02eYfQrPSXa8hRzMfCVofcyy7Yjxq8bk7p/nXjEGdpzrMQOAvpRvVcBzLUs5+ WZhTHwtgJLdpRGDTzE6wio3Z5BEvraW+SN2e+M7mNFnit3dMVo2S1/Akv53x723sbaVP OxSvcXs3Hp/LHaYzuU0FUQ3x4elt1gkeWNY53T5FWaaekoEB/vL1WQuw+vvJcFgyaBhe FEB6ka20uNTONb5aKjGjXMVJkSpX/Xa/FU3oFcTjvzoAhzgVQ824Grpon0ovLAhNm12y VrUA== X-Received: by 10.66.118.109 with SMTP id kl13mr21694274pab.19.1421702441264; Mon, 19 Jan 2015 13:20:41 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:4d37:1619:da3a:156a? ([2601:8:ab80:7d6:4d37:1619:da3a:156a]) by mx.google.com with ESMTPSA id ig1sm951742pbc.41.2015.01.19.13.20.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Jan 2015 13:20:40 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C506EFA9-23ED-4FB7-9DC2-4588573C3CF9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: old bug: mount_nfs path/name is limited to 88 chars From: Garrett Cooper In-Reply-To: Date: Mon, 19 Jan 2015 13:20:39 -0800 Message-Id: <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> To: Brandon Allbery X-Mailer: Apple Mail (2.1878.6) Cc: mexas@bris.ac.uk, rmacklem@uoguelph.ca, freebsd-stable , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Jan 2015 21:20:42 -0000 --Apple-Mail=_C506EFA9-23ED-4FB7-9DC2-4588573C3CF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 19, 2015, at 8:46, Brandon Allbery wrote: > On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht = > wrote: >=20 >> So perhaps changing MNAMELEN will break statfs(2) on >> -stable too? >>=20 >=20 > I believe the context there is not so much "-current is special", as > "changing it for everyone is bad news" (and this would necessarily = need to > originate in -current). A compat layer needs to be created for all of the affected syscalls, and = the change needs to be made. That=92s it in a nutshell. Doing it in 11 makes sense since there is a compat layer for 10 now=85 = if I knew all of the steps I would happily do them as annoys me from = time to time as well with the path length issue. Thanks! --Apple-Mail=_C506EFA9-23ED-4FB7-9DC2-4588573C3CF9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUvXUnAAoJEMZr5QU6S73esE0H/02cg9lmsG+DMq4JDMDkydly H8uD7AHgOQ7HxaY59BEGGnsqVHRznlu3j/dYm3qX9ifCRUAMA2bkXy/8JeVlcRLv 4kcsL+8B1w7EeLnwwW1PXwe2NR5NN+4+flRGWdu3ICJfS3uLFdqObz9s7q88tSv9 OcGIr8aHS++UEAeiDIU9OP6KviXyN6ULpL+YOCOMPOU5XjJI9FXsqrwr96/xeLPp 4LP0inacr6ASl+79pFq5lYU7tnuYCWcqzlzdl0lFEvDFKKK46NtGovWUCA6ZDvYp 8a4QgKdEF5XqxsHI3a+pNP0hjz8jMUi7vTuZHCa0ZRczIZj1xzbWS0eMmozuPzM= =jxOM -----END PGP SIGNATURE----- --Apple-Mail=_C506EFA9-23ED-4FB7-9DC2-4588573C3CF9-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 23:12:27 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1FD7FBD for ; Mon, 19 Jan 2015 23:12:27 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54B198F9 for ; Mon, 19 Jan 2015 23:12:27 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id ms9so9158045lab.1 for ; Mon, 19 Jan 2015 15:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=MELkzZp6s7sP/8SZd0zX8HxWCSzRhYJhsGyzUJqA41c=; b=a4CoR5bc0Ox94Ufq/HKI8SWHFq/GU8K5RMhPiscKZrEpCgi5xWvgi/eOeQSYZinUJn i+AqjHg+2krs6wQP04p+f5EXQVfSEee1bf3tPXnMGW06n9ALNKOeTm/FiTRI59MxkAso rJ7/uVjvACTai3/UKxR4kSPor3zOxL5GXvfN2aTQuAoU4hDm27ZCWzK+TJpnA2vhMz7q s9+IAdZq6GXTUUxZZV/P2U+5yImOJ3GnraTJW0ssyLOonhl3E/zw6mmaFvXMkI++vmI8 665V1X3VU2/CijeI46sZfOrveGtJ3h8ZXfnLUYsMOdiA+gSNi3gmEekMo6za/GVk56vy aVAg== MIME-Version: 1.0 X-Received: by 10.152.207.37 with SMTP id lt5mr34655940lac.66.1421709145225; Mon, 19 Jan 2015 15:12:25 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.25.155.4 with HTTP; Mon, 19 Jan 2015 15:12:25 -0800 (PST) Date: Mon, 19 Jan 2015 15:12:25 -0800 X-Google-Sender-Auth: tT5QggOUL-53m_Pc_p50GU-1-yo Message-ID: Subject: [PATCH] nmbclusters should be always positive From: Davide Italiano To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 19 Jan 2015 23:12:27 -0000 Currently, the following is allowed in FreeBSD: root@rabbit1:/home/davide/udp-clt # sysctl kern.ipc.nmbclusters=2147483647 kern.ipc.nmbclusters: 2036598 -> -2147483648 The following is an attempt of fixing. I also think nmbcluster should actually be u_int and not it, but this is a discussion for another day, maybe. diff --git a/sys/kern/kern_mbuf.c b/sys/kern/kern_mbuf.c index 7ab6509..15b38a9 100644 --- a/sys/kern/kern_mbuf.c +++ b/sys/kern/kern_mbuf.c @@ -162,7 +162,7 @@ sysctl_nmbclusters(SYSCTL_HANDLER_ARGS) newnmbclusters = nmbclusters; error = sysctl_handle_int(oidp, &newnmbclusters, 0, req); if (error == 0 && req->newptr && newnmbclusters != nmbclusters) { - if (newnmbclusters > nmbclusters && + if (newnmbclusters > 0 && newnmbclusters > nmbclusters && nmbufs >= nmbclusters + nmbjumbop + nmbjumbo9 + nmbjumbo16) { nmbclusters = newnmbclusters; nmbclusters = uma_zone_set_max(zone_clust, nmbclusters); -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 00:19:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46C42D8C; Tue, 20 Jan 2015 00:19:54 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01237F10; Tue, 20 Jan 2015 00:19:53 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 5887E16A409; Tue, 20 Jan 2015 01:19:49 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHT-oeDDwK5Y; Tue, 20 Jan 2015 01:14:48 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id D7F0F16A408; Tue, 20 Jan 2015 01:14:48 +0100 (CET) Message-ID: <54BD9DF6.8060402@digiware.nl> Date: Tue, 20 Jan 2015 01:14:46 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Garrett Cooper , Brandon Allbery Subject: Re: old bug: mount_nfs path/name is limited to 88 chars References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> In-Reply-To: <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: mexas@bris.ac.uk, rmacklem@uoguelph.ca, freebsd-stable , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 00:19:54 -0000 On 19-1-2015 22:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery > wrote: > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on -stable >>> too? >>> >> >> I believe the context there is not so much "-current is special", >> as "changing it for everyone is bad news" (and this would >> necessarily need to originate in -current). > > A compat layer needs to be created for all of the affected syscalls, > and the change needs to be made. That’s it in a nutshell. > > Doing it in 11 makes sense since there is a compat layer for 10 now… > if I knew all of the steps I would happily do them as annoys me from > time to time as well with the path length issue. Well after this the next problem you'll be running into is: #define PATH_MAX 1024 /* max bytes in pathname */ Which I already did inf find(1) because the paths in backups of big filesystems already bit in like 2011. Talked about it with Jilles, and got more or less the same answer: You can up the value, but expect things to break. Which it did when I only fixed the size in find. It would break in the program that got the path fed. Never dared to just up the value, compile kernel/world, install and reboot. And then see what comes of it. So IMHO if possible this would need to be extended as well... --WjW From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 00:23:15 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0501BFBF for ; Tue, 20 Jan 2015 00:23:15 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id CFE2AFCF for ; Tue, 20 Jan 2015 00:23:14 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 7253C8DD8F for ; Tue, 20 Jan 2015 00:23:07 +0000 (UTC) Message-ID: <54BD9FF1.5090202@freebsd.org> Date: Mon, 19 Jan 2015 19:23:13 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: old bug: mount_nfs path/name is limited to 88 chars References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> In-Reply-To: <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JgxPqPOsG5diGVGNOj2utUWSQfnD0OTQj" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 00:23:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JgxPqPOsG5diGVGNOj2utUWSQfnD0OTQj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-01-19 16:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery wrote: >=20 >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on >>> -stable too? >>> >> >> I believe the context there is not so much "-current is special", as >> "changing it for everyone is bad news" (and this would necessarily nee= d to >> originate in -current). >=20 > A compat layer needs to be created for all of the affected syscalls, an= d the change needs to be made. That=92s it in a nutshell. >=20 > Doing it in 11 makes sense since there is a compat layer for 10 now=85 = if I knew all of the steps I would happily do them as annoys me from time= to time as well with the path length issue. >=20 > Thanks! >=20 Especially with ZFS, I find I have a lot more mounts now, under longer and longer path names, and then I have =2Ezfs/snapshots/snapshotnamehere/path/to/file etc. Definitely a +1 for "this is something we need for 11" --=20 Allan Jude --JgxPqPOsG5diGVGNOj2utUWSQfnD0OTQj 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.22 (MingW32) iQIcBAEBAgAGBQJUvZ/zAAoJEJrBFpNRJZKf7LQP/ix7WdEbA6idiy68IV8BAlr2 RA3zwm7D1xMy0aIQ8aa18QaYESqM0Hn8sRYgXV2ATfwcMjsF1c3KNz6CaCIeF3oQ +kDN5CPQZ/Azbx+Kr60IieEBDvP9IcKN8HkqDsc6UMEsUhzYJbYT901qawn+Aisx SsFdpo86T7wXGvbgTulLZmgrlGgipC7EbO0BMj2kcZe6EzqWi3F1AI4JDzjhPp7v qE+Z78VTyxc96kdd98T1DcNJ3jNt2TetJzja9Iesaga9uSvAyoga2cVhwKMDR2dO nyhfRomLuQmlwmc9lQdBkuPZKeIq6kgXBXYbh768+mA+weGgkFbFoxO2+VhNpJEo MpW93/bxjTv+jqj9da4FpJiWdoBLc22WyPvZmB30Qk8efPr0p3O5vPhP/usztXvm kt4O2Qx5xS0V+4Rcmgsh4QRF9DxI1qmEIKwUcZddQIr4zM1/vLBe61Z5rGWnxlr0 5XIhYu00EumSu9YYWoaQ9Ty70HC8qBBmIgXHojFtO9sTnO71IoivjYBmmEiAOaSo XMz3/BTJcul+8BsRn5FD+MDabRhG9d1TW70nN9Xj8wFq//fTaPP9c7E2LAUknCjR 5cCKD8/lnfNDsM20WvOIH6mFt3C3dQ2y6Fuse8YWvysFROuqkxQPcH5aAI9pp1CT AJUrSa35dc6Hw8ihDwGA =fOof -----END PGP SIGNATURE----- --JgxPqPOsG5diGVGNOj2utUWSQfnD0OTQj-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 01:05:35 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06A126CB; Tue, 20 Jan 2015 01:05:35 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DA389617; Tue, 20 Jan 2015 01:05:34 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id B182A266C; Mon, 19 Jan 2015 17:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1421715933; x=1421730333; bh=BuhBwC5RnOIR/gfHROfzE1pBsc1aK+DL8X1kEpzOJb0=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=t9j0ru/YoUgeeDDWopbvfGW/xaWTPWYNHLhZT6chBYsfwm8Ofgv3b6D/z/aJwTrdF +vYTwxCh+s5dtihibpA4SYD4s6dpMlWdBcbspSusN3aHU34F1Jpk2SEZRds0IfOh2L EoBBNiCWqa1HW/9pB25+dOCHb+JrGzb+ndUVB2Z4= Message-ID: <54BDA9DD.5040608@delphij.net> Date: Mon, 19 Jan 2015 17:05:33 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Garrett Cooper , Brandon Allbery Subject: Re: old bug: mount_nfs path/name is limited to 88 chars References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> In-Reply-To: <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: mexas@bris.ac.uk, rmacklem@uoguelph.ca, freebsd-stable , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 01:05:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/19/15 13:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery > wrote: > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on -stable >>> too? >>> >> >> I believe the context there is not so much "-current is special", >> as "changing it for everyone is bad news" (and this would >> necessarily need to originate in -current). > > A compat layer needs to be created for all of the affected > syscalls, and the change needs to be made. That’s it in a > nutshell. > > Doing it in 11 makes sense since there is a compat layer for 10 > now… if I knew all of the steps I would happily do them as annoys > me from time to time as well with the path length issue. Compat layer may break applications in other funny ways and we probably have to return e.g. ENAMETOOLONG for legacy applications if the names are too long to fit into the buffer, but I don't see any easy solution either: I wish we have bumped it in 2003 when the struct receives its first big revamp by bumping all statistic fields to 64-bit. I personally think we probably better create a new API and keep the existing one for (limited) compatibility. For instance, it may be sensible to make f_mntfromname and f_mntonname fields variable length and have the caller pass a pointer and their length. If we set an arbitrary limit, no matter it's 88, 256 or 4096, one will hit it some time. BTW. If someone wants to change statfs(2), please make sure to create reverse-compatibility shims at the same time (see lib/libc/sys/fcntl.c for an example). The statfs(2) API is used in a lot of places, especially fts(3), and breaking it either way (running new world with old kernel, or running old world with new kernel) would be a big pain to recover from. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.1 (FreeBSD) iQIcBAEBCgAGBQJUvanaAAoJEJW2GBstM+nsgoQP/0+Ulfmmmj9n9cWA0h1NxD3O a59aZXxbFtRu2SkIZprzFOL4TLnmyKEthFGmUgRSm7SH3GuaWVPBsgHTjSddYA/f vD3fBei780akT/higazmSENKR0eWqL0zENG8HJndQ0XLLcv8eeHZEFFhbUlYA4JU 4ArzoKEwsxiQ4jKB+KSFRU4QR4Raarljx6m4gQyXO6QAPEcyO035YH+bJlMSPjYg wcJZiZXmsRYsjZMhKDGeO5tIiD8R/UwOcMKsaQ/O+bwCgWtHFe5gLDKxGjMlLc9c NuhXE2/xlyBdAf3OHTlgr61dPmArQl0pyLXDUfd8K0s05FQ22bGHaSCT0FyNNG0J 55rnr30iDczVjQV1rTk9AwvsTJzACyaRrCV3zXGpxr86XwGFRta4ebMYZNuRXhdZ sLsTZWpIc3gnvOH4CiZHPmr1mbHoAY1RN9G23T5ENu2zYNJVozXhJ4NkoZkKzxUj b19qox4aKtG9QT7h5HU7R7Q64Sz2dYty8VD4OZ/azQrLGjVdI+2KUq6M3SAIRBro IAmGY62OQyz8aDVhr/Ap/N7GnV4suCZf08kgg3+oREU0a8QAxEHCDnNH4MJ9xz6v +2GpYWp0AuCFJ77XQC7IB6va1hK+PZnuOZ9yNVKTTadEwSk4GK2fQv6YwLjiyYKM PiOk31dmRfQB+3mqZ+Oj =a3fA -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 01:53:30 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ED9BDB5; Tue, 20 Jan 2015 01:53:30 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D5AEFA8E; Tue, 20 Jan 2015 01:53:29 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAMSzvVSDaFve/2dsb2JhbABcg1hYBIMCwzcGhXUCgWEBAQEBAX2EDAEBAQMBI1YFFhgCAg0ZAiM2GRoBh30DCQi5fo9zDYQcAQEBAQEBBAEBAQEBAQEXBIEhjC6BUgEJGgEzB4ItOxGBMAWJdYw3gliCfIYKgh+FcSKCAR2BbiAxgQMBHyJ+AQEB X-IronPort-AV: E=Sophos;i="5.09,431,1418101200"; d="scan'208";a="186795194" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 19 Jan 2015 20:53:22 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EAAF03CE1D; Mon, 19 Jan 2015 20:53:21 -0500 (EST) Date: Mon, 19 Jan 2015 20:53:21 -0500 (EST) From: Rick Macklem To: d@delphij.net Message-ID: <1162721475.16794258.1421718801948.JavaMail.root@uoguelph.ca> In-Reply-To: <54BDA9DD.5040608@delphij.net> Subject: Re: old bug: mount_nfs path/name is limited to 88 chars MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: mexas@bris.ac.uk, freebsd current , freebsd-stable , Brandon Allbery , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 01:53:30 -0000 Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 01/19/15 13:20, Garrett Cooper wrote: > > On Jan 19, 2015, at 8:46, Brandon Allbery > > wrote: > >=20 > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht > >> wrote: > >>=20 > >>> So perhaps changing MNAMELEN will break statfs(2) on -stable > >>> too? > >>>=20 > >>=20 > >> I believe the context there is not so much "-current is special", > >> as "changing it for everyone is bad news" (and this would > >> necessarily need to originate in -current). > >=20 > > A compat layer needs to be created for all of the affected > > syscalls, and the change needs to be made. That=E2=80=99s it in a > > nutshell. > >=20 > > Doing it in 11 makes sense since there is a compat layer for 10 > > now=E2=80=A6 if I knew all of the steps I would happily do them as anno= ys > > me from time to time as well with the path length issue. >=20 > Compat layer may break applications in other funny ways and we > probably have to return e.g. ENAMETOOLONG for legacy applications if > the names are too long to fit into the buffer, but I don't see any > easy solution either: I wish we have bumped it in 2003 when the > struct > receives its first big revamp by bumping all statistic fields to > 64-bit. >=20 > I personally think we probably better create a new API and keep the > existing one for (limited) compatibility. For instance, it may be > sensible to make f_mntfromname and f_mntonname fields variable length > and have the caller pass a pointer and their length. If we set an > arbitrary limit, no matter it's 88, 256 or 4096, one will hit it some > time. >=20 > BTW. If someone wants to change statfs(2), please make sure to create > reverse-compatibility shims at the same time (see > lib/libc/sys/fcntl.c > for an example). The statfs(2) API is used in a lot of places, > especially fts(3), and breaking it either way (running new world with > old kernel, or running old world with new kernel) would be a big pain > to recover from. >=20 Solaris has statvfs(), which might be a starting point for a new API. statfs(2) would have to be retained for compatibility with older binaries a= nd I think there would still be some breakage for cases where the mount path does exceed MNAMELEN. All I can think of is that the mount path would have to be truncated for the compatibility code. (I don't know what kind of truncation would be preferred? Just chop it at 88 or do something like /sub1/.../mnt or 0 length?) I think a lot of things will bump up against PATH_MAX, so making the length that might be ok, although I like the new API having the buffer and its length being passed in as arguments, so at least the syscall API doesn't need to change again. Some variant of doing all this is in projects/ino64 I think, since it ends up changing assorted syscalls like stat(2) as well, along with versioning the libc functions affected by the syscall changes. (I'd guess fts(3) is one of them, but haven't looked.) I doubt these changes could be MFC'd (others mention doing this for FreeBSD11). What could be done and maybe MFC'd is to simply allow mounts with paths greater than 88, but truncate it to 88 for statfs(2). { I think this truncation will end up happening for the compatibility syscall code anyhow, even if a new statfs(2) is added, so maybe just let it happen, even if no new syscall is available. } There was a patch floating around for this and doing this would only impact mounts with paths > MNAMELEN. (mount_nfs could print a warning for paths > MNAMELEN instead of failing the mount.) Does this sound reasonable as a stop gap (and could it be MFC'd?)? rick > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.1.1 (FreeBSD) >=20 > iQIcBAEBCgAGBQJUvanaAAoJEJW2GBstM+nsgoQP/0+Ulfmmmj9n9cWA0h1NxD3O > a59aZXxbFtRu2SkIZprzFOL4TLnmyKEthFGmUgRSm7SH3GuaWVPBsgHTjSddYA/f > vD3fBei780akT/higazmSENKR0eWqL0zENG8HJndQ0XLLcv8eeHZEFFhbUlYA4JU > 4ArzoKEwsxiQ4jKB+KSFRU4QR4Raarljx6m4gQyXO6QAPEcyO035YH+bJlMSPjYg > wcJZiZXmsRYsjZMhKDGeO5tIiD8R/UwOcMKsaQ/O+bwCgWtHFe5gLDKxGjMlLc9c > NuhXE2/xlyBdAf3OHTlgr61dPmArQl0pyLXDUfd8K0s05FQ22bGHaSCT0FyNNG0J > 55rnr30iDczVjQV1rTk9AwvsTJzACyaRrCV3zXGpxr86XwGFRta4ebMYZNuRXhdZ > sLsTZWpIc3gnvOH4CiZHPmr1mbHoAY1RN9G23T5ENu2zYNJVozXhJ4NkoZkKzxUj > b19qox4aKtG9QT7h5HU7R7Q64Sz2dYty8VD4OZ/azQrLGjVdI+2KUq6M3SAIRBro > IAmGY62OQyz8aDVhr/Ap/N7GnV4suCZf08kgg3+oREU0a8QAxEHCDnNH4MJ9xz6v > +2GpYWp0AuCFJ77XQC7IB6va1hK+PZnuOZ9yNVKTTadEwSk4GK2fQv6YwLjiyYKM > PiOk31dmRfQB+3mqZ+Oj > =3Da3fA > -----END PGP SIGNATURE----- >=20 From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 04:49:01 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95200AD5; Tue, 20 Jan 2015 04:49:01 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4A0FE65; Tue, 20 Jan 2015 04:49:00 +0000 (UTC) X-AuditID: 1209190e-f799e6d000000cfe-39-54bddd07fdda Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 5B.DA.03326.70DDDB45; Mon, 19 Jan 2015 23:43:52 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t0K4hoOU015991; Mon, 19 Jan 2015 23:43:51 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t0K4hmMV022483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jan 2015 23:43:50 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t0K4hl9V014970; Mon, 19 Jan 2015 23:43:47 -0500 (EST) Date: Mon, 19 Jan 2015 23:43:47 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org Subject: FreeBSD Quarterly Status Report - Fourth Quarter 2014 Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUixG6nrstxd2+IwUN/i13XTrNbzHnzgcli ++Z/jBaHm4UcWDxmfJrPEsAYxWWTkpqTWZZapG+XwJXxbOVz9oJLR1kq5n/aydTA+OUocxcj J4eEgInEjUefWCFsMYkL99azdTFycQgJLGaSuHFtDzuEs5FRYv3zbiaQKiGBQ0wS0x5nQCQa GCWurpgP1MLBwSKgLfF+fzlIDZuAmsTjvc1QUxUlNp+axAxSIiIgL7HgvD1ImFnAWmLuuvVg JcICdhKTv75jB7F5BRwlelYsAjtOVEBHYvX+KSwQcUGJkzOfsED0Bkr0rJvDNIFRYBaS1Cwk KQhbR2LKxBWMELa2xP2bbWwLGFlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrr5WaW6KWmlG5i BAUypyTfDsavB5UOMQpwMCrx8L5YtTdEiDWxrLgy9xCjJAeTkihvzU2gEF9SfkplRmJxRnxR aU5q8SFGCQ5mJRHeo5eAcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxK ErxnbwM1ChalpqdWpGXmlCCkmTg4QYbzAA3fAlLDW1yQmFucmQ6RP8VoyfHk5O6ZTBz7LoLI vo0HZzIJseTl56VKiUM0CIA0ZJTmwc2EJaZXjOJALwrzBt8BquIBJjW4qa+AFjIBLRTbtQdk YUkiQkqqgXGpnZt9mPysVZ1zRUNeCNsIKbtkH/15cjuThuCxmkmvN18X1/v7geGjED9PxgW5 ZTnGrqa2Z3b0vFy+s/2za2nYIebdr+UmXGd+ZLSxJF5afFFHyu8ZJ03Wz65g2Hg/v0330XLm hKc+tWnHD/wziYw75fhL7QJTnpHBhccXdzvtWv/trFe30w8lluKMREMt5qLiRACMR5P1JwMA AA== Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 04:49:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report: October - December 2014 This report covers FreeBSD-related projects between October and December 2014. This is the last of four reports planned for 2014. The fourth quarter of 2014 included a number of significant improvements to the FreeBSD system. In particular, compatibility with other systems was enhanced. This included significant improvements to the Linux compatibility layer, used to run Linux binaries on FreeBSD, and the port of WINE, used to run Windows applications. Hypervisor support improved, with FreeBSD gaining the ability to run as domain 0 on Xen's new high-performance PVH mode, bhyve gaining AMD support, and new tools for creating FreeBSD VM images arriving. This quarter was also an active time for the toolchain, with numerous improvements to the compiler, debugger, and other components, including initial support for C++14, which should be complete by FreeBSD 10.2. Thanks to all the reporters for the excellent work! The deadline for submissions covering the period from January to March 2015 is April 7th, 2015. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team Projects * bhyve * Clang, llvm, and lldb Updated to 3.5.0 * External Toolchain * FreeBSD on Google Cloud * FreeBSD on the Acer C720 Chromebook * Git Integration * Jenkins Continuous Integration for FreeBSD * Migration to ELF Tool Chain Tools * pkg(8) Kernel * FreeBSD Xen * Linux Emulation Layer, the Linuxulator * PCI SR-IOV Infrastructure * Process Management * Secure Boot * Timer Function Support for Linuxulator * Updating OpenCrypto Architectures * FreeBSD on POWER8 * FreeBSD/arm64 Userland Programs * libxo: Generate Text, XML, JSON, and HTML Output * mandoc(1) Support Ports * GNOME on FreeBSD * KDE on FreeBSD * Linux Emulation Ports * The Graphics Stack on FreeBSD * Wine/FreeBSD * Xfce Documentation * More Michael Lucas Books * New Translators Mailing List Miscellaneous * Creating Vagrant Images with Packer * FreeBSD Forum Software Migration * The FreeBSD Foundation __________________________________________________________________ FreeBSD Release Engineering Team URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The FreeBSD 10.1-RELEASE cycle completed on November 14th, marking the second official release point from the stable/10 branch, just short of three weeks later than the original schedule anticipated. Work to produce virtual machine images for platforms not currently supported has continued, with focus aimed primarily at Amazon EC2, Google Compute Engine, and Openstack. With huge thanks to Ian Lepore and Warner Losh, new ports exist for FreeBSD/arm where u-boot is required. Work has been in progress since late December to migrate the existing FreeBSD/arm release build tools to utilize the new ports. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-po= rts/ URL: http://portsmon.freebsd.org/index.html URL: http://portscout.freebsd.org/ URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: Port Management Team As of the end of Q4 the ports tree holds more than 24,000 ports, and the PR count is just over 1,400. As during the previous quarter the tree saw a sustained activity with almost 6,000 commits and more than 1,600 ports PRs closed! In Q4, five new developers were granted a ports commit bit (gordon@, jmg@, jmmv@, bofh@, truckman@) and six were taken in for safekeeping (sylvio@, pclin@, flz@, jsa@, anders@, motoyuki@). On the management side, miwi@ decided to step down from his portmgr duties in November. No other changes were made to the team during Q4. This quarter also saw the release of the fourth quarterly branch, namely 2014Q4. On the QA side, 39 exp-runs were performed to validate sensitive updates or cleanups. Open tasks: 1. A tremendous work was done on the PR front in Q4 and we would be very pleased to see committers dedicate themselves to closing as many as possible in 2015 as well! 2. 2014 is the year that saw the highest number of commits in all of our ports tree's history! As for the PR front and to keep our beloved tree in good shape, we would love to see the same commitment from our developers next year! __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. During the fourth quarter of 2014, the FreeBSD Core team saw the culmination of a long-running project to rebuild the FreeBSD Forums. The chosen solution was to license XenForo; core would like to thank the FreeBSD Foundation for paying the licensing costs of this software. Much discussion ensued concerning the "New Support Model" following Core's meeting at EuroBSDCon in September. It was recognised that trying to change the model immediately before 10.1-RELEASE was far too late, and the change will be targeted at 11.0-RELEASE. In order to ensure that 10.1-RELEASE shipped with support for up-to-date X Window Systems and KDE4, core approved the switch to 'new Xorg' as the default in time for building the packages for that release. Git was officially promoted from beta to an officially supported version control system. Git is available as a read-only resource for downstream consumers and contains an exported copy from SVN, the primary and only read-write repository. The FreeBSD git repositories (exported from the master SVN version control) will shortly be available at https://git.freebsd.org/, and core has been active in ensuring that there is a sufficient body of Git administrators available with access to appropriate documentation in order to maintain a good git service. Core mediated in disputes between a number of committers over some updates to system sources, and fielded complaints about code quality of some other work in critical areas. While such disagreements will occasionally occur, core is promoting the routine use of the Phabricator service in order to review work before committal. Catching problems early is in the project's best interests, and discussion of changes in an open review context should minimize confrontational demands for immediate back-out of changes. Core is working on a charter for a proposed new QA team, to encompass members of the Release Engineering and Security teams, as well as committers with interests in standards compliance. It is envisioned that the QA team will take responsibility for merging code from HEAD into the STABLE branches, run integration testing against those updates and handle merging patches and bug-fixes submitted to the FreeBSD project from third parties. During this quarter, core issued two new commit bits, and also took two commit bits into safe-keeping. __________________________________________________________________ bhyve URL: http://www.bhyve.org Contact: Peter Grehan Contact: Neel Natu Contact: John Baldwin Contact: Tycho Nightingale Contact: Allan Jude bhyve is a hypervisor that runs on the FreeBSD/amd64 platform. At present, it runs FreeBSD (8.x or later), Linux i386/x64, OpenBSD i386/amd64, and NetBSD/amd64 guests. Current development is focused on enabling additional guest operating systems and implementing features found in other hypervisors. Support for AMD processors was committed to -CURRENT in October 2014. This has also been merged to 10-STABLE and will be included in the 10.2 release. A bhyve status update presentation was given at the FreeBSD Vendor Summit in Nov 2014. The slides are available at http://people.freebsd.org/~neel/bhyve/bhyve_update_vendor_summit_2014.pd= f . A number of improvements have been made to bhyve this quarter: * OpenBSD/i386 guests are now able to boot with multiple vcpus. * NetBSD/amd64 guests are now fully supported. * Improvements to the AHCI emulation to be more resilient under heavy load. * Various improvements to PIC emulation to be able to boot legacy guests. * A fully featured RTC device emulation that allows date/time changes by the guest and supports periodic and alarm interrupts. * Consolidate all timer emulations in vmm.ko. This enables the use of a single clocksource for all timer emulations. * Allow tracing of every exception incurred by a guest. This is useful when debugging guest double and triple faults. * Emulate platform-specific MSRs accessed by recent Linux guests. * Various bug fixes to grub-bhyve to boot OpenBSD/i386 and Centos 4.x guests. * grub-bhyve is now able to connect to an nmdm(4) console using the --cons-dev option. Open tasks: 1. Improve documentation. 2. bhyveucl is a script for starting bhyve instances based on a libUCL config file. More information at https://github.com/allanjude/bhyveucl . 3. CSM BIOS boot support for non UEFI-aware guests. 4. Add support for virtio-scsi. 5. Improve virtio-net, add offload features, support multiple queues. 6. Implement Intel 82580 and e1000 NIC emulation. 7. Netmap support. 8. Flexible networking backend: wanproxy, vhost-net. 9. Move to a single process model, instead of bhyveload + bhyve. 10. Support running bhyve as non-root. 11. Add filters for popular VM file formats (VMDK, VHD, QCOW2). 12. Implement an abstraction layer for video (no X11 or SDL in base system). 13. Support for VNC as a video output. 14. Suspend/resume support. 15. Live Migration. 16. Nested VT-x support (bhyve in bhyve). 17. Support for other architectures (ARM, MIPS, PPC). __________________________________________________________________ Clang, llvm, and lldb Updated to 3.5.0 URL: http://llvm.org/releases/3.5.0/docs/ReleaseNotes.html URL: http://llvm.org/releases/3.5.0/tools/clang/docs/ReleaseNotes.html Contact: Dimitry Andric Contact: Ed Maste Contact: Roman Divacky Just before the end of the year, we updated clang, llvm, and lldb in the base system to 3.5.0 release. These all contain numerous improvements. Please see the linked release notes for more detailed information. This is the first release that requires C++11 support to build. At this point, FreeBSD 10.0 and later provide that support, at least on x86. In the near future, more components from llvm.org will be updated in base, with libc++ and libcompiler-rt most likely being the first to be updated. Thanks to Ed Maste, Roman Divacky, Andrew Turner, Justin Hibbits, and Antoine Brodin for their invaluable help with this import. Open tasks: 1. While most ports that were impacted by this update have already been fixed, there are still a few that do not work with the clang 3.5.0 update. In most cases, this is due to relatively simple issues, such as new warnings, or slightly stricter error checking (primarily for C++ programs). Fixing those issues should not take too much work. 2. There are still some open issues with the ARM, PowerPC, and Sparc64 architectures, and any help in this area is very much appreciated. __________________________________________________________________ External Toolchain URL: https://wiki.freebsd.org/ExternalToolchain Contact: Baptiste Daroussin Contact: Warner Losh Contact: Brooks Davis The main goal of the external toolchain project is to be able to build world and kernel with a non-default toolchain. It can be helpful to: * Prepare a migration to a newer version of toolchain components. * Port FreeBSD to a new architecture * Upgrade from a FreeBSD that ships with GCC 4.2 to a version that ships with clang 3.5+ (which needs a more modern toolchain than GCC 4.2 to bootstrap). The initial external toolchain work only supported clang. It has been extended to support recent GCC (4.9.1 has been tested) and recent binutils (2.24 and 2.25). A large number of fixes have been committed to HEAD to support incompatible behaviour changes between ld(1) from binutils 2.17.50 (the version in base) and binutils 2.24+. A large number of warnings have been deactivated when building the kernel to make sure it is possible to build the kernel with recent GCC (first 4.6 and then 4.9.1) The build system has been changed to build libc++ as the C++ standard library implementation when a recent enough GCC (4.6+) is used to build world. To simplify using an external toolchain, the following pre-seeded configurations have been added to the ports tree: * amd64-xtoolchain-gcc * powerpc64-xtoolchain-gcc * sparc64-xtoolchain-gcc Those packages will depend on special versions of GCC (minimalistic cross-built ready GCC) and on binutils. To use them, run: make CROSS_TOOLCHAIN=3Dpowerpc64-gcc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 As a result of this effort, it is possible to successfully build and run a kernel and world built with GCC 4.9.1 and binutils 2.24 on sparc64, amd64 (with minor tweaks), powerpc and powerpc64. Open tasks: 1. Patch GCC 4.9 to support FreeBSD mips, arm and aarch64 and submit the patches to upstream. 2. Adapt and upstream the aarch64 patches for binutils 2.25. 3. Add more pre-seeded configurations. __________________________________________________________________ FreeBSD on Google Cloud URL: https://github.com/swills/FreeBSD-gcloud URL: https://plus.google.com/112202779615695172291/posts/eYajb8JKerY Contact: Steve Wills Google Cloud is a cloud computing platform that allows users to run hosted services and servers in a cloud maintained by Google. The goal of this project is to provide an easy way to create and manage FreeBSD installations running on Google Cloud. The good news: FreeBSD 10.1 runs fine. You can create an image and start it up and login via standard ssh, via the gcloud command or via the web console (ssh in a web browser window). More details on how to do all this can be found in the links. Basically, you should be able to gcutil addimage freebsd-101-release-amd64-20150101032704 gs://swills-test-bucket/FreeBSD-10.1-RELEASE-amd64-20150101032704.tar.gz Then spin up an image using gcloud compute instances create --zone us-central1-b --image freebsd-101-release-amd64-20150101032704 --boot-disk-size 20GB gtest1 These commands are part of the google-cloud-sdk port, which contains all the commands to interact with Google Cloud. There is also a google-daemon port which is used in running instances to create users and set them up and a google-startup-scripts port which handles running startup/shutdown scripts as specified in node metadata. Additionally, the firstboot-growfs port has been brought back so that new instances will grow their root filesystem. (Thanks to Colin Percival for having created that port initially.) There is also a firstboot-freebsd-update port which can be used to update a system on first boot but is currently disabled (see below). Similarly, the firstboot-pkgs port/scripts will install specified packages on first boot. Overall, Google Cloud Compute is quite nice; instances spin up in about 60 seconds and it is very reasonably priced with automatic discounts for longer term usage. There is a $300 credit for first time users that also makes it free to try out. That credit covers quite a lot of time, and the instances are pretty fast, as well, even the ones without SSDs. The bad news: Google does not make sharing non-official images as easy as AWS, so you have to create your own using my public tar file. The tar file was created using the script in the links section. That script can be used to produce customized images, even though there are no official image (nor will there be any time soon). There are some issues running FreeBSD on Google Cloud, listed in the tasks section. Open tasks: 1. The 8 and 16 cpu instances seem to reboot randomly. 2. Repeated UFS panics that Google folks have reported, but I do not think those are particular to Google Cloud. The panic message is "ffs_valloc dup alloc". 3. Running freebsd-update causes the system to become unbootable, so updates do not work. (Reboots work fine otherwise.) 4. There is no gcimagebundle command in the Ports Collection so you cannot easily create an image from a running machine. 5. There are a few minor issue with the startup script that is supposed to regenerate ssh keys (for when you create an image from an existing system). 6. 10.1 works, but 10.0 does not boot; other versions remain untested. 7. The kern.vm_guest sysctl node does not detect that it is in a guest. 8. The vtnet driver needs wq disabled on 16 cpu boxes, but it is just disabled everywhere for now since that is easier. 9. There is work needed for the Google safe_format_and_mount command which formats and mounts newly attached disks, but this is just a nicety really. 10. I need to look into irq affinity for vtnet. 11. We need to support virtualized clocks; bryanv@ is working on this. In fact, all his ongoing work in the virtualization area would probably make things work better. 12. It would be nice if there was the ability to disable the spinner before the loader, which clutters up the console log. The ability to disable it is in HEAD; hopefully it will be MFCd to 10-STABLE before 10.2. __________________________________________________________________ FreeBSD on the Acer C720 Chromebook URL: http://blog.grem.de/pages/c720.html Contact: Michael Gmelin The Acer C720 Chromebook is a powerful but inexpensive laptop designed to run Google's Chrome OS. This project aims to bring FreeBSD to the C720, providing an easy way for people to experience FreeBSD on hardware which is widely available and inexpensive. As of this update, most system features work, including the keyboard, WiFi, sound, VESA graphics, touchpad, and USB. The battery life is a reasonable 5 to 6 hours (compare to the published 8.5 hour lifetime for Chrome OS. Open tasks: 1. Streamline patches and merge them into HEAD. 2. Make suspend/resume work (depends on Haswell support). __________________________________________________________________ Git Integration URL: https://lists.freebsd.org/mailman/listinfo/freebsd-git URL: https://www.kernel.org/pub/software/scm/git/docs/git-svn.html URL: https://github.com/git/git/commit/83c9433e679635f8fbf8961081ea3581c= 93ca778 URL: https://wiki.freebsd.org/GitWorkflow URL: https://github.com/freebsd/freebsd URL: https://bugs.freebsd.org/bugzilla Contact: Git discussion list Several FreeBSD developers have expressed interest in improving the tools and documentation to facilitate the use of the Git source code management (SCM) system when working with FreeBSD code. Some highlights of the work in this area include the following: * At Alfred Perlstein's request, a new mailing list freebsd-git@FreeBSD.org was created for discussion of git use in the FreeBSD project. * Alfred Perlstein submitted a patch to git. This patch allows a developer to work on a source code tree in git and use git-svn to push changes from this tree directly to a Subversion repository and set Subversion properties. Before this patch, git-svn did not properly set Subversion properties. This is important for FreeBSD developers because the FreeBSD Subversion repo will block commits which do not properly set certain Subversion properties. The git project accepted this change in changeset 83c9433. * Alfred Perlstein updated the Git Workflow wiki document to include information for using git-svn to commit to the FreeBSD Subversion repository. * Bartek Rutkowski wrote a script which integrates Github and FreeBSD Bugzilla. When a user files a Github pull request against the FreeBSD source code tree on Github, this script will open a new PR in FreeBSD Bugzilla. This will allow users to contribute code and patches via Github pull requests, and have the request tracked by FreeBSD developers in Bugzilla. Github pull requests cannot currently be directly merged into the FreeBSD source tree on Github, because the main source code repository is currently Subversion. The FreeBSD source code tree on Github is a read-only mirror of the FreeBSD Subversion repository. Craig Rodrigues coordinated with Bartek Rutkowski and bugmeister@FreeBSD.org to move forward on this, and provide Bartek Rutkowski with enough access to Bugzilla to open PR's via a script. Open tasks: 1. The Github integration script is not deployed yet and is not active for all pull requests against the FreeBSD source tree on Github. Bartek Rutkowski and bugmeister@FreeBSD.org need to work out the final details for deploying this script into production. The script must be accessible via HTTP POST requests because it uses the Github REST API. Bartek Rutkowski and bugmeister@FreeBSD.org need to reach agreement on where this script lives, and do a security audit. __________________________________________________________________ Jenkins Continuous Integration for FreeBSD URL: https://jenkins.freebsd.org URL: http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testin= g URL: https://wiki.freebsd.org/201411DevAndVendorSummit?action=3DAttachFi= le&do=3Dview&target=3Dkyua_jenkins.pdf URL: https://issues.jenkins-ci.org/browse/JENKINS-21507 URL: https://issues.jenkins-ci.org/browse/JENKINS-24521 URL: https://github.com/rodrigc/kyua/wiki/Quickstart-Guide URL: http://www.freshports.org/textproc/igor/ URL: https://jenkins.freebsd.org/job/FreeBSD_Doc-igor URL: https://jenkins.freebsd.org/job/FreeBSD_HEAD_sparc64/ URL: https://lists.freebsd.org/pipermail/freebsd-testing/2014-November/0= 00609.html URL: https://lists.freebsd.org/pipermail/freebsd-testing/2014-December/0= 00697.html URL: https://lists.freebsd.org/pipermail/svn-src-all/2014-October/092212= =2Ehtml URL: http://lists.freebsd.org/pipermail/freebsd-testing/2015-January/000= 713. html URL: https://github.com/Homebrew/homebrew/pull/32346 URL: https://github.com/freebsd/freebsd-ci/pull/3 URL: https://lists.freebsd.org/pipermail/freebsd-testing/2015-January/00= 0723.html URL: https://lists.freebsd.org/pipermail/freebsd-testing/2015-January/00= 0722.html Contact: Craig Rodrigues Contact: Jenkins Administrators Contact: FreeBSD Testing Since the last status report, many people have contributed help in various areas to help with Continuous Integration and Testing in FreeBSD. Some of the highlights include: * The Jenkins project mentioned on their blog how FreeBSD is using Jenkins and kyua to run OS-level tests. * Craig Rodrigues submitted patches to upgrade Jenkins to use JNA 4.1.0. The Jenkins project accepted these patches [JENKINS-24521] in the Jenkins 1.586 release. This fixed problems with PAM authentication support in Jenkins on FreeBSD [JENKINS-21507]. * Craig Rodrigues gave a presentation "Kyua and Jenkins Testing Framework" for BSD at the Developer and Vendor summit on November 3, 2014 in San Jose, California. In the presentation, Craig Rodrigues described how, for every commit to the FreeBSD source tree, nearly 3000 tests are run using kyua inside a bhyve virtual machine. The kyua test results are exported to JUnit XML format, which is then used by Jenkins to generate web-based test reports with graphs. * Li-Wen Hsu set up a Jenkins build named FreeBSD_Doc-igor to run the Igor tool written by Warren Block. Igor proofreads FreeBSD documentation and reports various errors. * Craig Rodrigues set up a Jenkins build named FreeBSD_HEAD_sparc64 to build the FreeBSD HEAD branch for the sparc64 architecture * Garrett Cooper imported more tests from NetBSD. After this import, there are now over 3000 tests in the /usr/tests directory. * Susan Stanziano from Xinuous ran kyua tests and provided feedback about test errors, running the tests in a bhyve VM. * Andy Zhang from Microsoft ran kyua tests and provided feedback about test errors running in a Hyper-V 2012R2 VM. * Steve Wills ran the FreeBSD tests in Google Compute Engine and provided the test results. * Craig Rodrigues submitted a formula to create a package for kyua in the Homebrew packaging system on OS X. The Homebrew project accepted this. Now, kyua can easily be installed on OS X via a Homebrew package. Hopefully this will make it easier to share more test infrastructure and scripts with OS X. * Craig Rodrigues submitted to the Debian project a kyua package. Approval for this is still pending. A package will make it much easier to install kyua on Linux distributions which use Debian packages such as Debian, Ubuntu, and Linux Mint. Hopefully this will make it easier to share more test infrastructure and scripts with Linux. * Brian Gardner submitted scripts to run the Regression Test Harness for OpenJDK (jtreg). The test results are in JUnit XML format, which can be natively imported into Jenkins. * Ahmed Kamal, an experienced devops expert and past contributor to the Ubuntu project, offered to help Craig Rodrigues with improving the automation and deployment of Jenkins nodes in the FreeBSD cluster using the Saltstack automation framework. Ahmed is interested in helping the FreeBSD project. * Craig Rodrigues worked with Adrian Chadd to set up Jenkins builds of MIPS targets. The next step will be to get kyua tests running inside a QEMU MIPS VM. Open tasks: 1. Set up more builds based on different architectures. 2. Improve the maintenance of nodes in the Jenkins cluster using devops frameworks such as Saltstack. 3. Get feedback for improving the Kyua Quickstart Guide. 4. People interested in helping out should join the freebsd-testing@FreeBSD.org list. __________________________________________________________________ Migration to ELF Tool Chain Tools URL: http://elftoolchain.sourceforge.net Contact: Ed Maste The ELF Tool Chain project provides BSD-licensed implementations of compilation tools and libraries for building and analyzing ELF objects. It started as part of FreeBSD but has moved to a standalone project to encourage wider participation from others in the open-source developer community. FreeBSD's libelf and libdwarf are now imported from upstream sources in contrib/elftoolchain. ELF Tool Chain provides a set of tools equivalent to the GNU Binutils suite. This project's goal is to import these tools into the FreeBSD base system so that we have a set of up-to-date and maintained tools that also provide support for new CPU architectures of interest, such as arm64. The following tools have now been imported and are available by setting the src.conf knob WITH_ELFTOOLCHAIN_TOOLS=3Dyes: * addr2line * nm * size * strings * strip (elfcopy) A ports exp-run uncovered some bugs in these tools. The bugs are being fixed in the FreeBSD source tree and are in the process of being committed to the upstream project. ELF Tool Chain's readelf will be enabled as well once some missing functionality in ELF note parsing is added. ELF Tool Chain's elfcopy provides equivalent functionality to Binutils' objcopy, and accepts the same command-line arguments. For it to be a viable replacement for all uses of objcopy in the base system, it must gain support for writing portable exectuable (PE) format binaries, which are used by UEFI boot code. The ELF Tool Chain project does not currently provide replacements for as, ld, and objdump. For FreeBSD these tools will likely be obtained from the LLVM project. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Import readelf. 2. Add missing functionality to readelf. 3. Add missing functionality to elfcopy and migrate the base system build. 4. Fix issues found by fuzzing inputs to the tools. 5. Switch the default to WITH_ELFTOOLCHAIN_TOOLS. __________________________________________________________________ pkg(8) URL: https://github.com/freebsd/pkg Contact: The pkg team The package development team has released pkg(8) 1.4. This release fixes lots of bugs and adds some new features: * Stricter checking of paths passed via the plist * Change the ABI string to be closer to MACHINE_ARCH * Add three-way merge functionality * Add conservative upgrade support for multi repository configurations * Multirepository priority An important part of the development direction for the 1.4 release was stabilizing the existing features and improving the pkg(8) experience on small/embedded machines (reducing memory usage and speeding up operations). pkg(8) is not only the FreeBSD Package Manager, but also the Package Manager for DragonflyBSD. Support has been added to build pkg(8) on OS X and Linux. This work will allow other Operating Systems the option of adopting pkg(8) to manage their packages and bring new developers into the project. Open tasks: 1. Add more regression tests. 2. Package the FreeBSD base system. 3. Allow using mtree as a plist when creating a package. 4. Implement flexible dependencies. 5. Test the development branch. 6. More developers are needed, check the Issues on Github. __________________________________________________________________ FreeBSD Xen URL: http://wiki.xen.org/wiki/FreeBSD_PVH URL: http://wiki.xen.org/wiki/FreeBSD_Dom0 Contact: Roger Pau Monn=E9 Contact: Justin T. Gibbs During this quarter almost all pending Xen changes have been committed, enabling FreeBSD to be used as Dom0 under the new PVH mode. The set of features supported by FreeBSD is still limited, but it should allow for basic usage of FreeBSD as Dom0. Support for booting Xen from the FreeBSD boot loader will be committed very soon to HEAD. Apart from testing on a variety of hardware, work has now shifted to improve PVH support in Xen itself in order to have feature parity with a traditional PV Dom0 and to declare the PVH ABI as stable. Regarding guest improvements (running FreeBSD as a DomU), there is also ongoing work to add unmapped IO support to Xen blkfront, which is blocked pending some modifications to the generic bounce buffer code. This project is sponsored by Citrix Systems R&D, and Spectra Logic Corporation. Open tasks: 1. Test on different hardware. 2. Improve the performance of the netback and blkback backends. 3. Work with upstream Xen to improve PVH and make it stable. 4. Improve generic bounce buffer code for unmapped bios in order to support blkfront alignment requirements. __________________________________________________________________ Linux Emulation Layer, the Linuxulator URL: https://svnweb.freebsd.org/base/user/dchagin/lemul/ URL: https://reviews.freebsd.org/differential/query/i9Ua2XMYQtNX/ Contact: Dmitry Chagin The main goal of the Linux emulation layer project is the execution on FreeBSD of multithreaded Linux applications that require the glibc library version 2.20 or later to be available. Glibc 2.20 requires a Linux kernel (or emulation thereof) of version 2.6.32 or later. The main obstacle preventing this is that the current Linuxulator uses native FreeBSD processes for emulating Linux threads. This leads to several problems, including problems with process reparenting and dethreading, wait() and signal handling. It would be much better to reuse the FreeBSD kernel code for thread management than to create a completely new codebase for pseudothread management in the Linuxulator. At present, the linux emulation layer project has implemented all of the necessary system calls for supporting glibc 2.20, and more, bringing the emulated Linux kernel version to 2.6.32: * Using native threads for emulating Linux threads * Implemented VDSO support, including DWARF for signal trampolines, which are needed for stack unwinding in pthread_cancel() * Implemented the "vsyscall hack", used by some Linux-based distributions, including CentOS 6 * Implemented the epoll() system call emulation * Added support for x86_64 * Many bugs were fixed The project's code is located in the FreeBSD Project's Subversion repository at base/user/dchagin/lemul (a little bit old). To facilitate merging the improvements back to head, several patches have been placed on reviews.FreeBSD.org with the tag #lemul. Nearly half of the patches have already been approved by Ed Maste and Edward Tomasz Napierala. Open tasks: 1. Review and merge the lemul branch to head within the next month or two. 2. Implement native and Linuxulator inotify() system calls. 3. Implement the ptrace() system call for the x86_64 Linuxulator. 4. Implement the signalfd() and timerfd() system calls for the Linuxulator. 5. Implement Priority Inheritance Futexes for the Linuxulator. 6. Extend xucred support, required for many Linux applications. __________________________________________________________________ PCI SR-IOV Infrastructure URL: https://github.com/rysto32/freebsd/commits/iov_ixl Contact: Ryan Stone PCI Single Root I/O Virtualization (SR-IOV) is an optional part of the PCIe standard that provides hardware acceleration for the virtualization of PCIe devices. When SR-IOV is in use, a function in a PCI device (known as a Physical Function, or PF) will present multiple Virtual PCI Functions (VF) on the PCI bus. These VFs are fully independent PCI devices that have access to the resources of the PF. For example, on a network interface card, VFs could transmit and receive packets independently of the PF. The most obvious use case for SR-IOV is virtualization. A hypervisor like bhyve could instantiate a VF for every VM and use PCI passthrough to assign the VFs to the VMs. This would allow multiple VMs to share access to the PCI device without having to do any expensive communication with the hypervisor, greatly increasing the performance of I/O within a VM. Work on the core PCI infrastructure is complete and undergoing review. Currently it is planned to commit the PCI infrastructure to head by the end of January. In addition to the PCI infrastructure, individual PCI drivers must be extended to implement SR-IOV. An SR-IOV implementation is in progress for the ixl(4) driver, which supports the Intel XL710 family of 40G and 10G NICs. Currently it is planned to have this in review by the end of January. An implementation for ixgbe(4) is also in progress, but there is no timeline for completion. This project is sponsored by Sandvine Inc.. __________________________________________________________________ Process Management Contact: Konstantin Belousov Contact: Peter Holm There were several improvements made to FreeBSD's process management last quarter. The Reaper facility was added, allowing a process to reliably track the running and exiting state of the whole subtree of its processes. It is intended to improve tools like timeout(1) or poudriere, by making it impossible for a runaway grandchild to escape the controlling process. The feature was designed based on similar facilities in DragonFlyBSD and Linux, with some references to Solaris contracts. Committed to HEAD in r275800. The FreeBSD suspension code does not ensure that the system, both software and hardware, is in a steady and consistent state. One aspect is usermode process activity, which is not yet stopped, continuing to making requests to the hardware. It is not realistic to expect drivers to be able to correctly handle the calls after SUSPEND_CHILD. We developed a facility to stop usermode threads at safe points, where they are known to not own and to not wait for kernel resources, in particular, not waiting for device requests finishing. It is based on the existing single-threading code, but extending it to allow external thread to put some processes into stopped state. Also, a facility to sync filesystems before suspend was added, to ensure that consistent metadata and as much as possible of the cached user data are on stable storage, to minimize the damage that could be caused by a failed resume. The code stressed some parts of the system and has led to discovery of a number of bugs in different areas, including process management, buffer cache, and syscall handlers. The bugs were fixed, and the fixes and features commmitted by a series culminating in r275745. During the work described above, it was noted that process spinlock duties are significantly overloaded (the same is true for the process lock). The spinlock was split into per-feature locks in r275121. As a result, it was also possible to eliminate recursion on it in r275372. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Secure Boot URL: https://wiki.freebsd.org/SecureBoot Contact: Edward Tomasz Napiera=B3a UEFI Secure Boot is a mechanism that requires boot drivers and operating system loaders to be cryptographically signed by an authorized key. It will refuse to execute any software that is not correctly signed, and is intended to secure boot drivers and operating system loaders from malicious tampering or replacement. This project will deliver the initial phase of secure boot support for FreeBSD and consists of: * creating ports/packages of the gnu-efi toolchain, Matthew Garrett's shim loader, and sbsigntools * extending the shim to provide an API for boot1.efi to load and verify binaries signed by keys known to the shim * writing uefisign(8), a BSD-licensed utility to sign EFI binaries using Authenticode, as mandated by the UEFI specification. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Ensure that the signature format properly matches UEFI spec requirements. 2. Verify that correctly signed, incorrectly signed, and unsigned loader components are handled properly. 3. Investigate signed kernel ELF objects (including modules). __________________________________________________________________ Timer Function Support for Linuxulator Contact: Bjoern A. Zeeb Since 2006, initial support for Linux timer function compatibility support was present but untested. This update corrects the initial implementation and makes it available to the 32-bit Linuxulator on amd64, not just on i386. Starting with FreeBSD 10.1, this enables users to run another FPGA high-level synthesis toolchain and emulation platform on a FreeBSD system. This project is sponsored by DARPA, and AFRL. __________________________________________________________________ Updating OpenCrypto URL: https://svnweb.freebsd.org/changeset/base/r275732 URL: http://freebsdfoundation.blogspot.com/2014/08/freebsd-foundation-an= nounces-ipsec.html Contact: John-Mark Gurney The project adds support for AES-GCM and AES-CTR modes to the OpenCrypto framework. Both software and AES-NI accelerated versions are functional, working and committed. Ermal Lu=E7i (eri@) is working on adding support for the additional modes to IPsec. This project is sponsored by The FreeBSD Foundation, and Netgate. Open tasks: 1. Commit the port that provides the NIST KAT vectors so that the tests committed can run. __________________________________________________________________ FreeBSD on POWER8 URL: https://wiki.freebsd.org/POWER8 URL: http://www.tyan.com/campaign/openpower/ Contact: Nathan Whitehorn Contact: Justin Hibbits Contact: Adrian Chadd IBM and the OpenPOWER Foundation are pushing for a wider software and hardware ecosystem for POWER8-based systems. Beginning January 3, we have been doing bringup work on a Tyan GN70-BP010 POWER8 server, a quad-core 3 GHz system with 32 hardware threads. The main target for the port is the PowerKVM hypervisor provided on OpenPOWER hardware. This uses the same software interfaces as the PowerVM hypervisor already supported on earlier POWER hardware. The target is to have this operation mode fully supported by FreeBSD 10.2. FreeBSD currently runs under the hypervisor when using a mass storage driver other than the built-in virtualized SCSI; the issues with the SCSI driver should be solved shortly. The longer-term goal is to also operate on the bare system. This requires interaction with the OPAL system firmware and the development of device drivers for the on-board PCI, console, and interrupt controller hardware. As of January 4, the FreeBSD kernel had printed initial messages to the console. This project is sponsored by FreeBSD Foundation . Open tasks: 1. Fix virtualized SCSI driver in PowerKVM. 2. Write OPAL drivers. 3. Integrate loader(8) with petitboot bootloader. __________________________________________________________________ FreeBSD/arm64 URL: https://wiki.freebsd.org/arm64 URL: https://github.com/FreeBSDFoundation/freebsd/tree/arm64-dev Contact: Andrew Turner Contact: Ed Maste Contact: Zbigniew Bodek There is growing interest in ARM's 64-bit architecture. Officially named AArch64, it is also known as ARMv8 and arm64. Andrew Turner started initial work on the FreeBSD/arm64 port at the end of 2012. The FreeBSD Foundation is now collaborating with ARM, Cavium, the Semihalf team, and Andrew Turner to port FreeBSD to arm64, and significant progress was made on the port over the last quarter of 2014. As of the end of the year, FreeBSD boots to single-user mode on arm64, executing both static and dynamic applications. Patches in review allow FreeBSD to boot to multi-user mode, and these are expected to be merged soon. This includes implementing many stub functions in userland and the kernel. With this, FreeBSD has booted to multi-user mode on both the ARM Foundation Model and the QEMU full system emulation. Cavium has supplied a software simulator of their Thunder X hardware. Bringup of FreeBSD has started on this including writing new drivers for the ARM Generic Interrupt Controller v3 (GICv3) and a preliminary driver for the PCIe root complex. With these, FreeBSD is able to boot on this simulator in preparation for testing on hardware. Further work is progressing to add full PCIe bringup and to add support for the GICv3 Interrupt Translation Services (ITS) for MSI-X. Further improvements have been made to the loader to allow it to take the Flattened Device Tree data from UEFI and pass it to the kernel. In the kernel, busdma, CPU identification, and improvements to interrupt handling have been made, along with preliminary KDB support. Hardware for testing the port will be installed in the FreeBSD Test Cluster hosted by Sentex Communications. The first reference platform, Cavium's ThunderX, is expected to arrive in the cluster in mid-January. This project is sponsored by The FreeBSD Foundation, ARM, and Cavium. Open tasks: 1. Bring up and test kernel support on real hardware. 2. Implement the remaining userland libraries and binaries. 3. Produce installable images. __________________________________________________________________ libxo: Generate Text, XML, JSON, and HTML Output URL: http://juniper.github.io/libxo/libxo-manual.html Contact: Marcel Moolenaar Many FreeBSD utilities provide insight into the operational state of a running FreeBSD system and as such are used regularly to monitor the system. These utilities provide their output in a human readable form and sometimes even optimized for the limited width of traditional terminals. Often times these utilities are used by other programs that want to present the output in different ways or as part of other user interfaces. For such use cases, it is infinitely better to work with machine-readable output instead of human-readable output. Juniper Networks has created a library called libxo, which makes it easy for utilities to emit output in various formats. By default, text output is emitted, but with the introduction of the --libxo option this can be changed to XML, JSON, and HTML. The FreeBSD project has imported this library into the base system and is in the process of rewriting utilities to use libxo. Related to this, FreeBSD now also has the xo utility that allows scripts to grow the same capabilities. Instead of using echo or printf in scripts, output can be done using the xo utility. The df, w, and wc utilities have been converted to use libxo. The netstat utility is in the process of being converted and others are planned. Open tasks: 1. FreeBSD contains a lot of utilities that could benefit from having the ability to emit various output formats, too many for a few people to convert in time for FreeBSD 11.0-RELEASE. If you or your company would like to see a particular utility converted, consider learning about libxo and trying to perform the conversion of said utility to help out. __________________________________________________________________ mandoc(1) Support URL: http://mdocml.bsd.lv Contact: Baptiste Daroussin Contact: Ulrich Spoerlein Contact: The Documentation Team mandoc(1) has been made the default manual page formatter on HEAD -- man(1) will use mandoc(1) to format manual pages by default, then fall back to groff(1) if it fails. This change also fixes an issue with the FreeBSD man(1) command not being able to properly deal with ".so" in gzipped manual pages. The documentation team has spent a lot of time fixing issues reported by mandoc(1) in the FreeBSD manual pages. This greatly improves the quality of our manual pages. Most manual pages with remaining issues are from contrib/, for which changes should be reported and fixed upstream. The "manlint" target has also been switched to use mandoc -Tlint, which results in the target being more useful when working on manual pages. Some groff(1) versus mandoc(1) formatting differences have been spotted and reported to mandoc's upstream developers. Open tasks: 1. Switch makewhatis(1) to the version shipped with mandoc(1). 2. Figure out a way to detect mandoc(1)-unfriendly manpages in ports and create catpages with groff(1) for them. 3. Remove groff(1) from the base system. __________________________________________________________________ GNOME on FreeBSD URL: http://www.freebsd.org/gnome URL: https://github.com/freebsd/freebsd-ports-gnome URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD Contact: FreeBSD GNOME Team The FreeBSD GNOME Team maintains the GNOME, MATE, and CINNAMON desktop environments and graphical user interfaces for FreeBSD. GNOME 3 is part of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON is a desktop environment using GNOME 3 technologies but with a GNOME 2 look and feel. This quarter was an exciting time for the GNOME Team. We imported GNOME 3.14.0 and CINNAMON 2.2.16 into the ports tree. At the same time, we removed the old GNOME 2.32 desktop. And two weeks later we updated GNOME to 3.14.2 and CINNAMON to 2.4.2, which was collected while the preparation for the initial GNOME 3.14.0 import was under way. We moved our development repo to GitHub. The repo is structured as follows: the master branch is vanilla FreeBSD Ports, and we have theme branches for topics such as the porting of MATE 1.9 (the mate-1.10 branch) and GNOME 3.15 (the gnome-3.16 branch). The GNOME 3.14 branch (gnome-3.14) is not used or updated any more because the content has been committed to ports, but is kept around for the history. Open tasks: 1. The GNOME website is stale. Work is starting on updating the development section. We could use some help here. 2. MATE 1.10 porting is under way; the latest 1.9 releases are available in the mate-1.10 branch. 3. GNOME 3.16 porting is under way, and is available in the gnome-3.16 branch. __________________________________________________________________ KDE on FreeBSD URL: https://freebsd.kde.org/ URL: https://freebsd.kde.org/area51.php URL: https://wiki.freebsd.org/KDE URL: https://mail.kde.org/mailman/listinfo/kde-freebsd URL: http://portscout.freebsd.org/kde@freebsd.org.html Contact: KDE on FreeBSD team The KDE on FreeBSD team focuses on packaging and making sure that the experience of KDE and Qt on FreeBSD is as good as possible. As mentioned last quarter, Alonso Schaich (alonso@) became a committer and since then has made good progress helping his mentors Raphael Kubo da Costa (rakuco@) and Max Brazhnikov (makc@) maintain all Qt and KDE-related ports. This quarter, Qt 5.3 was finally committed to the ports tree. Extensive work was required, including cleaning up and/or changing a lot of the Qt5 ports infrastructure to make it both easier to maintain the Qt ports as well as finally make it possible to build newer versions when older ones are already installed on the system. We have also updated KDE in our experimental area51 repository and committed several updates to other ports such as KDevelop and KDE Telepathy. Overall, we have worked on the following releases: * CMake 3.1.0 (in area51, exp-run in progress for it to be committed to the ports tree) * Calligra 2.8.6 (in area51) * KDE 4.14.2 (committed to ports), 4.14.3 (in area51) * KDE Telepathy 0.8.0 (committed to ports) * KDevelop 4.7.0 (committed to ports) * Qt 5.3.2 (committed to ports) Tobias Berner has contributed patches to update QtCreator to 3.3.0 as well as KDE Frameworks 5 ports which are under review for inclusion in our experimental area51 repository. Open tasks: 1. Update Qt5 to 5.4.0. 2. Try to contribute to the work on getting rid of HAL on FreeBSD, which seems to be gaining more traction recently. 3. Add KDE Frameworks 5 ports to our experimental repository. __________________________________________________________________ Linux Emulation Ports URL: https://github.com/allanjude/linux-ports URL: https://github.com/vassilisl/freebsd-linux_base-f20 URL: https://svnweb.freebsd.org/base/user/dchagin/lemul/ Contact: Johannes Meixner Contact: Allan Jude Contact: Vassilis Laganakos The Linux emulation stack in the ports collection was upgraded to include CentOS 6.6 on November 11. After smoothing out several bugs that had been introduced, we were able to bump the default version of the Linux userland from Fedora 10 to CentOS 6.6 on December 9th. Providing a more modern Linux userland and support libraries allows a large number of Linux applications to be run on FreeBSD. The goal behind providing an updated Fedora-based userland is to support more desktop-oriented applications, which require newer libraries than are provided by CentOS 6. Providing 64-bit versions of the CentOS userland will allow applications that are only available in 64-bit form, such as a number of scientific and math related applications, to be run on FreeBSD. Support for 64-bit binaries also requires the 64-bit Linux kernel emulation layer from the lemul branch, which requires more testing and review before being merged into HEAD. This project is sponsored by Perceivon Hosting Inc., and ScaleEngine Inc.. Open tasks: 1. Update Allan Jude's 64-bit Linux ports to CentOS 6.6. 2. Add Fedora 20 base/userland ports to ports/head. 3. Refactor Mk/bsd.linux-*.mk to facilitate the above additions. 4. Promote testing and merging of Dmitry Chagin's lemul branch. (Updated Linux kernel emulation, and 64-bit support) __________________________________________________________________ The Graphics Stack on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: http://blogs.freebsdish.org/graphics/ URL: https://github.com/freebsd/freebsd-ports-graphics Contact: FreeBSD Graphics team Mesa was upgraded to 10.3, then 10.4 for FreeBSD 10.1-RELEASE and 11-CURRENT. We test release candidates and therefore this port is now usually updated shortly after a new release. Mesa 10.x brings huge improvements in terms of OpenGL standards support, performance and stability, especially for Radeon owners. Mesa 9.1 is kept for FreeBSD 9.x, but we have plans to fix this; see below. graphics/gbm and devel/libclc are new ports used by Mesa to implement OpenCL. The next step is to finish the port for Mesa's libOpenCL.so, named Clover. This will permit users to run OpenCL programs on Radeon GPUs for now. xserver was upgraded from 1.12 to 1.14. This is the last version of xserver supporting Mesa 9.1. Changes are described in an article on the blog. The most noticeable one is the switch from the input device detection back-end based on HAL to the one based on devd(8). hald(8) is still required by many desktop environments, but the X.Org server itself is free from it. xserver was the last port supporting the WITH_NEW_XORG knob. The knob is now completely removed. This was the occasion to add WITH_NEW_XORG and WITH_KMS to the list of deprecated knobs to help people clean up their make.conf. At the same time, the new-xorg alternate pkg repository was deprecated. After discussion, two options were enabled by default: * TEXTURE_FLOAT in graphics/dri, which allows Mesa to advertise the support for OpenGL 3.0+; * LCD_FILTERING in print/freetype2, which enables the subpixel rendering engine, improving font anti-aliasing. These two packages now provide a better user experience out-of-the-box. Users who are uncomfortable with the options may unset them and rebuild the ports. There is no need to rebuild anything else. On the kernel side, Tijl Coosemans added AGP support back to the TTM memory manager and therefore to the Radeon driver. His work was merged back to stable/10 and will be available in FreeBSD 10.2-RELEASE. We migrated our Ports development tree to Git and GitHub. Tracking changes in the official Ports tree and preparing patches is much easier. Furthermore, we can accept pull requests. All of the reasons behind this change are detailed on the blog and the workflow is described on the wiki. The XDC 2014 (X Developer's Conference) was a great conference. Reviving the relationship with the developers of the graphics stack was a success! A report is available on the blog. Our next items on the roadmap are: 1. Provide FreeBSD 10.1-RELEASE's i915 driver to FreeBSD 9.x users through a new port. This is a work in progress, but it would allow us to remove Mesa 9.1 and make Mesa 10.4 available everywhere. 2. Once Mesa 9.1 is gone, we can update xserver to 1.16. Open tasks: 1. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Wine/FreeBSD URL: http://wiki.FreeBSD.org/Wine URL: http://wiki.FreeBSD.org/i386-Wine URL: http://www.winehq.org Contact: Gerald Pfeifer Contact: David Naylor Contact: Kris Moore The Wine on FreeBSD project has been steadily forging ahead for the past three quarters and has updated the ports for the following versions: * Stable releases: 1.6.2 (3 port revisions) * Development releases: 1.7.16 through 1.7.33 The ports have packages built for amd64 (available through the ports emulators/i386-wine and i386-wine-devel) for FreeBSD 8.4, 9.1+, 10.0+, and CURRENT. Accomplishments include: * Upstreaming 33 patches to fix Wine on FreeBSD -- many thanks to Gerald for this work. * Migrating to the USES framework. * Building Wine with the X compositing extension. * Adding support for MPG123 and V4L. * Backporting changes made to the -devel ports to the stable ones and fixing minutiae here and there. * Creating a new Wine port for the Compholio patches. * Changing i386-wine(-devel) to set the LD_LIBRARY_PATH_RPATH variable. * Improving library bundling for i386-wine(-devel). * Various improvements to the patch-nvidia.sh script for i386-wine(-devel). * Various smaller changes. We would like to thank all the volunteers who contributed feedback or even patches. We would also like to welcome kmoore@ to the Wine team. He has been extensively involved in bringing wine-compholio to the Ports Collection. Future development on Wine will focus on: * Creating a 64-bit capable port of Wine (aka Wine64). * Creating a WoW64 capable port of Wine (aka Wine + Wine64). * Fixing directory listing on FreeBSD 8 and 9. Maintaining and improving Wine is a major undertaking that directly impacts end-users on FreeBSD, including many gamers. If you are interested in helping, please contact us. We will happily accept patches, suggest areas of focus, or have a chat. Open tasks: 1. Open Tasks and Known Problems (see the Wine wiki page). 2. FreeBSD/amd64 integration (see the i386-Wine wiki page). 3. Porting WoW64 and Wine64. __________________________________________________________________ Xfce URL: https://wiki.freebsd.org/Xfce Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms, such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. During this quarter, the team has kept these applications up-to-date: * misc/xfce4-weather-plugin 0.8.5 * science/xfce4-equake-plugin 1.3.6 * sysutils/xfce4-netload-plugin 1.2.4 * sysutils/xfce4-systemload-plugin 1.1.2 * www/midori 0.5.9 * x11/xfce4-taskmanager 1.1.0 * x11/xfce4-whiskermenu-plugin 1.4.2 * x11-wm/xfce4-desktop 4.10.3 Two new ports have also been added (taken from our repository): * deskutils/xfce4-volumed-pulse * x11/xfce4-dashboard Moreover, we are working on the next stable release, with these ports being updated: * sysutils/xfce4-power-manager 1.4.2 * x11/xfce4-dashboard 0.3.4 * x11-wm/xfce4-session 4.11.1 We sent some patches to upstream. * bug #11104, to keep 'wallpaper settings' in Ristretto with xfdesktop >=3D 4.11 * bug #11249, add 'Hidden' option in desktop item editor (refused) * bug #11413, to use sysctl(3) and acpi_video(4) for backlight support A FAQ is being written D1305. Open tasks: 1. Find a workaround for when acpi_video(4) is not functional (panel crashes); OpenBSD seems to have same problem. 2. Clean up patch in order to add new panel plugin in ports tree. 3. Continue to work on documentation, especially the Porter's Handbook. __________________________________________________________________ More Michael Lucas Books URL: https://www.michaelwlucas.com/nonfiction/freebsd-mastery-storage-es= sentials URL: http://blather.michaelwlucas.com Contact: Michael Lucas The first small FreeBSD Book, "FreeBSD Mastery: Storage Essentials" is available. Lucas is moving on to FreeBSD books on ZFS, Specialty Filesystems, and jails. They will hopefully be available by BSDCan 2015. Get status updates on his blog, or follow @mwlauthor on Twitter. Open tasks: 1. Push BSDCan out to June, so he has more time to write the new books. __________________________________________________________________ New Translators Mailing List Contact: FreeBSD Translators Mailing List A new mailing list has been created for people translating FreeBSD documents and programs from English into other languages. Discussions can include methods, tools, and techniques. Existing translators are encouraged to join so there is a single point of contact. New translators and those who wish to help with translation are welcome. New members are asked to introduce themselves and mention the languages they are interested in translating. Open tasks: 1. Encourage existing translators to join. 2. Welcome and educate new volunteers. 3. Work on implementing newer and easier translation systems and tools. __________________________________________________________________ Creating Vagrant Images with Packer URL: http://blogs.freebsdish.org/brd/2014/12/22/freebsd-packer-vagrant/ URL: https://github.com/so14k/packer-freebsd Contact: Brad Davis We have developed a recipe to use Packer to create FreeBSD Vagrant images to run on VMware and VirtualBox. Packer is a tool for creating identical machine images for multiple platforms from a single source configuration. Vagrant is a tool to create and configure lightweight, reproducible, and portable development environments. To get started, clone the Git repo and follow the directions in the README. More information is available from the Packer and Vagrant websites. __________________________________________________________________ FreeBSD Forum Software Migration Contact: FreeBSD Forums Administration Team With funding from the FreeBSD Foundation, the FreeBSD forums were migrated to XenForo software. The new software is far more capable and easy to use. While the entire forum team contributed, Daniel Gerzo did an excellent job importing existing users and messages and bringing back the often-requested "Thanks" feature. The upgrade was completed in time to be ready for the influx of new users from the release of FreeBSD 10.1, and we have already seen an increase in usage. Developers with an @FreeBSD.org address can contact forum administrators to obtain the highly-desired "@" suffix on their forum user name along with a Developer flag. We want to thank the Foundation for making this possible, and the users for their patience and continued presence on the forums! This project is sponsored by The FreeBSD Foundation . Open tasks: 1. Encourage more developers and users to try the new forums. 2. Continue getting feedback from users for tuning and improvements. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ URL: http://freebsdjournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Most of the funding is used to support FreeBSD development projects, conferences, and developer summits; purchase equipment to grow and improve the FreeBSD infrastructure; and provide legal support for the Project. We ended the year exceeding our fundraising goal, by raising over $2,372,132, from 1670 donors! Thank you to everyone who made a donation in 2014. We produced issues five and six of the FreeBSD Journal, ending the year with over 6300 subscribers, exceeding our first-year goal of 5000 subscribers. We also added the desktop/digital edition, so people can read the magazine from their browsers. We also hosted a meeting with the Journal Editorial Board and worked out the editorial calendar for the next two years. This includes topics and articles for the future issues. We were a gold sponsor of EuroBSDCon 2014, and a sponsor of the preceding Developer Summit. A few of our team members attended, which allowed us to have an informal face-to-face board meeting, with a focus on supporting the European region. Kirk McKusick gave a two-day FreeBSD tutorial and Erwin Lansing helped run the Developer Summit. We sponsored 5 FreeBSD contributors to attend the conference. We were a sponsor of the Grace Hopper Conference. Dru Lavigne gave an "introduction to FreeBSD" presentation, that was well attended. We also sponsored Shteryana Shopova to represent FreeBSD, along with Dru, at our booth. We were a sponsor of MeetBSD. Most of our team members attended this conference. Kirk McKusick gave a talk on BSD history. We also had a booth, and raised over $2,200 in donations. We sponsored one person to attend this conference. George organized and ran the two-day Silicon Valley Vendor and Developer Summit following MeetBSD. A lot of work gets started and accomplished at these summits, for example, Kirk worked with various folks to get the ino64 (64-bit inode numbers) project moving. It started in 2011 as a Summer of Code project and has sputtered since getting pushed into the system. In addition to the above conferences, we helped promote FreeBSD at the following conferences: * All Things Open * Ohio Linux Fest * LISA LISA had a great turnout for Dru Lavigne's FreeBSD BoF talk. We visited a few large FreeBSD users in the Bay Area to discuss their use of FreeBSD, plans, and needs, and help facilitate collaboration between them and the Project. Cheryl Blain joined our board, bringing a strong background in business development and fundraising. We received the largest donation in our history, and our treasurer put together an endowment strategy for us to follow. We increased our FreeBSD marketing efforts to help promote and advocate for FreeBSD, as well as educate people on FreeBSD. Some our FreeBSD marketing highlights include: * Created the FreeBSD 10 brochure * Created the Get Involved brochure for recruiting * Created a testimonial flyer to encourage more companies to write FreeBSD testimonials for us. These flyers are available on the FreeBSD Foundation site for FreeBSD advocates to promote FreeBSD at conferences around the world. We also put ads for the Foundation and FreeBSD in the FreeBSD Journal and USENIX ;login: magazine. We are producing a monthly newsletter to highlight what we did the previous month to support the FreeBSD Project. We also produced our December semi-annual newsletter. We redesigned and launched phase 1 of our website. It should be easier to navigate and find the information you need to get help from or to help the Foundation. Glen Barber visited the Microsoft main campus and worked with Microsoft Hyper-V developers to resolve outstanding issues with providing FreeBSD images for the Microsoft Azure platform. Glen also visited the NYI colocation facility to install and configure new servers purchased by the Foundation. We finished the 10.1-RELEASE cycle. Our project development staff and contractors have been working on various projects to add features to and improve FreeBSD. Some of their reports are included in this overall report. Some projects that were worked on this quarter were adding support for 64-bit ARM architecture to FreeBSD, integration work on the vt(4) updated console and UEFI boot support, Secure Boot, refining the in-kernel iSCSI target and initiator stack, an autofs-based automount daemon, migrating to the ELF Tool Chain, and implementing modern AES modes in FreeBSD's cryptographic framework. To read more about how we helped support the FreeBSD Project and community, read our semi-annual newsletter. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJUvdl5AAoJECjZpvNk63USvm4MIONtg7ZxQXtS6ebzHtKSyYxe fbj0bThjJBQwvgxuM8sqAI2tCmDI/BCKh5KsNGYQLs8kVYtFE+N8AWitLlx+fxT1 iOge5UTL2GK2jZObON20jqojJU5waYZvEDyu+cLZFBl92IA/Q1iBbtyhpMOS02Fc sLsMZv/mNmmw8xQbvVjOFFO98DeK67ulgj0g1in6iSiM+FWBPDm/aGbOVGhUmtFS OjmX4SnZlmOrm6WVpI84TAb7XqGXqJ09BbVKWaPK4nug+BrNH3k9LjAkMZGKtMmF Jls34T6JdxM+cSDik2VqkiAlr+k7nJUjKe8TnFrIBgCjq+5tRfTiq4Laly2/U25L 3GEYeoaAgColqVx3vDSKukbyaBOeDy79dtlqnCPS3Tjv1+Kob2w3zz6W7WfMX3cj Hg5ZfUivTPq2CI5+tVe3SM8eBP+BerxU4GXFWE+a6uWUS+L/Zxyu864z2bk6noNI Rd4aZkihamW2nzxqa/+pJMFq88y5afWgLFvHGwl9T092Pgc=3D =3DVGnI -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 06:00:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93CD04A4; Tue, 20 Jan 2015 06:00:54 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BDAC8D5; Tue, 20 Jan 2015 06:00:54 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id k14so35233940wgh.2; Mon, 19 Jan 2015 22:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uOph65c0okVhtwlcSbcXx2XXgb9jMiCjH5TpKbYlP80=; b=WmVWKhTFNkg7wNKOI49mqPd62/0diHkjjT6ccYWmZQmvnVuof9ajw3d/SzU9fM+Uvo mpQKT6sz8AMii75DX18/0uRjsnhq9UytnoEib8RMo49nawC1roRVXlXQXilu4nEoXVRi kf7tSHLPOuSe8Da452tYC6FAa7znGk+O+VOUtNwgYoI84u1ulVerUVq6kNjBoQyMFv6Z 3eQTjXeOp83EqgyDF+scKXrUwwEE+blzIgKO93LTEGWWr1Jt1G82+NZAyaR3EhS8jUeA yuMles3ek/TYbdqMFiihoG8wqWu2+UbH99maVs89Z7/RO3akowmpnvJXjvhZ5sdHyN3s 4n+A== MIME-Version: 1.0 X-Received: by 10.180.91.193 with SMTP id cg1mr43192607wib.26.1421733652575; Mon, 19 Jan 2015 22:00:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Mon, 19 Jan 2015 22:00:52 -0800 (PST) In-Reply-To: <20141029075603.GC53947@kib.kiev.ua> References: <5433E408.2010601@egr.msu.edu> <20141007164419.GB2153@kib.kiev.ua> <20141007180106.GD2153@kib.kiev.ua> <54344766.1040700@egr.msu.edu> <20141008170525.GH2153@kib.kiev.ua> <54358C88.2080501@egr.msu.edu> <20141022122640.GL1877@kib.kiev.ua> <54480C9B.7070606@egr.msu.edu> <20141023190329.GP1877@kib.kiev.ua> <20141026210211.GA1103@dchagin.static.corbina.net> <20141029075603.GC53947@kib.kiev.ua> Date: Mon, 19 Jan 2015 22:00:52 -0800 X-Google-Sender-Auth: Znxa7ULpT6xiJGMj8PmgC8lPjzg Message-ID: Subject: Re: Ver 2 of the patch [was: Re: i915 driver update testing] From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: Adam McDougall , freebsd-current , Chagin Dmitry X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 06:00:54 -0000 Hi, I finally fired this up on an older Intel to test. this is patch 8 from your website: vgapci0@pci0:0:2:0: class=0x030000 card=0x20e417aa chip=0x2a428086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller' class = display .. works fine for me. Do you need any further information? I have some other pre-sandybridge devices that I'll spin this up on once they've been updated to the latest -HEAD. Thanks! -adrian From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 06:08:02 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7E1B61F; Tue, 20 Jan 2015 06:08:01 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79F5A91A; Tue, 20 Jan 2015 06:08:01 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id l18so9677089wgh.8; Mon, 19 Jan 2015 22:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=OVDJkE6fyqiOsfzC93q4M314w/NXmNaNfaj+sBYfn8w=; b=RrBHOLEDQS+LOfvJQT5+vlPeRvvB2KYZC8zPCQCgEK2YfbWN4VE4A3mcSYT0rse115 e8A+2VAHBr4eB6Cyl/8bXv1yduhDowqHORjNtad9oalQE/9wlI6cwyTyS5w5lpTzANjh jlCN6cYcZb5+O27DWtKmxKc6H30bps3pjifpkuLAP5kROKuUMFRT19N/0C8hBXZ8B8wj +wxruVJSsDj+0/HVOkUDm5LDwIFKnqQb/KkzuQnssNraWdJ5bfTkfIzwbdJ2ygjRweVE YmovccAIDAHUJEptRWnwWpKgxzSL4itAs4vciglv9LVJRoep2YPpSlfuzmNTEBgkRTT+ 7mRA== MIME-Version: 1.0 X-Received: by 10.180.20.177 with SMTP id o17mr29369240wie.20.1421734079761; Mon, 19 Jan 2015 22:07:59 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Mon, 19 Jan 2015 22:07:59 -0800 (PST) In-Reply-To: References: <5433E408.2010601@egr.msu.edu> <20141007164419.GB2153@kib.kiev.ua> <20141007180106.GD2153@kib.kiev.ua> <54344766.1040700@egr.msu.edu> <20141008170525.GH2153@kib.kiev.ua> <54358C88.2080501@egr.msu.edu> <20141022122640.GL1877@kib.kiev.ua> <54480C9B.7070606@egr.msu.edu> <20141023190329.GP1877@kib.kiev.ua> <20141026210211.GA1103@dchagin.static.corbina.net> <20141029075603.GC53947@kib.kiev.ua> Date: Mon, 19 Jan 2015 22:07:59 -0800 X-Google-Sender-Auth: XREkaAK0PSa72buTxYVUNwZMAOk Message-ID: Subject: Re: Ver 2 of the patch [was: Re: i915 driver update testing] From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , freebsd-current , Chagin Dmitry X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 06:08:02 -0000 Nope, spoke too soon: Unread portion of the kernel message buffer: panic: In GPU write domain cpuid =3D 1 KDB: stack backtrace: db_trace_self_wrapper(c09d59ce,0,c09ad9fe,205,f1ce2938,...) at db_trace_self_wrapper+0x2d/frame 0xf1ce2908 kdb_backtrace(c0a10b67,1,c82fb835,f1ce29f8,f1ce2998,...) at kdb_backtrace+0x30/frame 0xf1ce2970 vpanic(c0b1c868,100,c82fb835,f1ce29f8,5d,...) at vpanic+0x120/frame 0xf1ce2= 9b0 kassert_panic(c82fb835,c7bacd00,346,c95a8700,c95a8fa8,...) at kassert_panic+0x14f/frame 0xf1ce29ec i915_gem_pread_ioctl(c7ab1800,f1ce2b40,c7bacd00,c09c7175,86,...) at i915_gem_pread_ioctl+0x667/frame 0xf1ce2a5c drm_ioctl(c7bacc00,8020645c,f1ce2b40,3,c7e0e000,...) at drm_ioctl+0x213/frame 0xf1ce2aa4 devfs_ioctl_f(c7c135b0,8020645c,f1ce2b40,c7b77200,c7e0e000,...) at devfs_ioctl_f+0x11e/frame 0xf1ce2adc kern_ioctl(c7e0e000,a,8020645c,f1ce2b40,c7e0e000,...) at kern_ioctl+0x2e0/frame 0xf1ce2b18 sys_ioctl(c7e0e000,f1ce2c68,f1ce2bf4,16cc32,2710,...) at sys_ioctl+0x11d/frame 0xf1ce2bd8 syscall(f1ce2ca8) at syscall+0x31a/frame 0xf1ce2c9c Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xf1ce2c9c --- syscall (54, FreeBSD ELF32, sys_ioctl), eip =3D 0x28673fff, esp =3D 0xbfbfe90c, ebp =3D 0xbfbfe928 --- (kgdb) #0 doadump (textdump=3D-1061574304) at pcpu.h:233 #1 0xc04fb4cd in db_fncall (dummy1=3D-238147896, dummy2=3D0, dummy3=3D-951= 565744, dummy4=3D0xf1ce26b4 "=EF=BF=BDOR=EF=BF=BD`=EF=BF=BD=EF=BF=BD=EF=BF=BD") at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568 #2 0xc04fb1bb in db_command (cmd_table=3D) at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440 #3 0xc04faee0 in db_command_loop () at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493 #4 0xc04fd97e in db_trap (code=3D) at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251 #5 0xc06d453c in kdb_trap (type=3D3, code=3D, tf=3D) at /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654 #6 0xc094ca90 in trap (frame=3D) at /usr/home/adrian/work/freebsd/head/src/sys/i386/i386/trap.c:693 #7 0xc093705c in calltrap () at /usr/home/adrian/work/freebsd/head/src/sys/i386/i386/exception.s:169 #8 0xc06d3dad in kdb_enter (why=3D0xc09d0b25 "panic", msg=3D) at cpufunc.h:71 #9 0xc0696aa4 in vpanic (fmt=3D, ap=3D) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_shutdown.c:739 #10 0xc069695f in kassert_panic (fmt=3D) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_shutdown.c:634 #11 0xc82b2bd7 in i915_gem_pread_ioctl (dev=3D0xc09d5a19, data=3D0xf1ce2b40= , file=3D) at /usr/home/adrian/work/freebsd/head/src/sys/modules/drm2/i915kms/../.= ./../dev/drm2/i915/i915_gem.c:3010 #12 0xc8323f53 in drm_ioctl (kdev=3D0xc7bacc00, cmd=3D= , data=3D, flags=3D3, p=3D) at /usr/home/adrian/work/freebsd/head/src/sys/modules/drm2/drm2/../../.= ./dev/drm2/drm_drv.c:942 #13 0xc057105e in devfs_ioctl_f (fp=3D, com=3D21496064= 92, data=3D, cred=3D, td=3D0xc7e0= e000) at /usr/home/adrian/work/freebsd/head/src/sys/fs/devfs/devfs_vnops.c:77= 5 #14 0xc06f6050 in kern_ioctl (td=3D0x2, fd=3D, com=3D9= , data=3D) at file.h:318 #15 0xc06f5cfd in sys_ioctl (uap=3D) at /usr/home/adrian/work/freebsd/head/src/sys/kern/sys_generic.c:718 #16 0xc094d79a in syscall (frame=3D) at subr_syscall.c= :133 #17 0xc09370f1 in Xint0x80_syscall () at /usr/home/adrian/work/freebsd/head/src/sys/i386/i386/exception.s:269 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) .. anything else you'd like? -adrian On 19 January 2015 at 22:00, Adrian Chadd wrote: > Hi, > > I finally fired this up on an older Intel to test. this is patch 8 > from your website: > > vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x20e417aa chip=3D0x2a428= 086 > rev=3D0x07 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Mobile 4 Series Chipset Integrated Graphics Controlle= r' > class =3D display > subclass =3D VGA > vgapci1@pci0:0:2:1: class=3D0x038000 card=3D0x20e417aa chip=3D0x2a438= 086 > rev=3D0x07 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Mobile 4 Series Chipset Integrated Graphics Controlle= r' > class =3D display > > .. works fine for me. Do you need any further information? > > I have some other pre-sandybridge devices that I'll spin this up on > once they've been updated to the latest -HEAD. > > Thanks! > > > > -adrian From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 06:50:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9198CB16; Tue, 20 Jan 2015 06:50:52 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E8ADCD3; Tue, 20 Jan 2015 06:50:52 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id n3so142192wiv.1; Mon, 19 Jan 2015 22:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TdcGotfzHogQJ5KPLo+tyZM66zRZxkiTpZT4FdcvI7k=; b=KsFjol3TIJ/60qjlW7bHQVFviG4JsLiwTjZ0IL1Tmjs7HzTVNa65g5bEAlldiC+V0p jepuQ5EQSxT3FdRgweHfGBa2Apg+rhnrmVD8B1+0/ucQ6QZ7FLuWnDVEtuCXlRZd4/xn dds5LTMyijG+mx/1EQPSyUKW1xijpJ/a5DM4n0IDsQsBzzjTLXKGxvg/6oMeUqtpW/ue cycl53QU9S6BopcSpH0YxUy5WpOMyeqYhQjPC9OiCh8atHrepnFhlkT4TV7zE/x21lH+ dkbKuPRiAFOJS/odZeirqzQpZzpkuqzar8QzE+ZeIc2jU0HftJ12+5jU49vhBz89uHk/ y44A== MIME-Version: 1.0 X-Received: by 10.194.108.9 with SMTP id hg9mr67355764wjb.68.1421736650572; Mon, 19 Jan 2015 22:50:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Mon, 19 Jan 2015 22:50:50 -0800 (PST) In-Reply-To: <20150107182314.GO42409@kib.kiev.ua> References: <54ACCBB3.1080906@freebsd.org> <20150107182314.GO42409@kib.kiev.ua> Date: Mon, 19 Jan 2015 22:50:50 -0800 X-Google-Sender-Auth: EIXUIZulO7n6-MW2Or6YQXEYpJw Message-ID: Subject: Re: i915 crash From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: "grembo@freebsd.org >> Michael Gmelin" , Konstantin Belousov , Allan Jude , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 06:50:52 -0000 I'm running with this patch right now; I was seeing "panic: in GPU write domain" and with this patch I'm not. -a On 7 January 2015 at 10:23, Konstantin Belousov wrote: > On Wed, Jan 07, 2015 at 01:01:23AM -0500, Allan Jude wrote: >> I grabbed the latest i915.8.patch from kib@'s website and compiled it >> against r276774 (today) >> >> Machine is a Lenovo T530, booted UEFI, with the nvidia GPU disabled. >> >> CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz (2594.16-MHz K8-class CPU) >> >> It is an Ivy-bridge CPU/GPU >> >> I installed xorg and kde, and when I try to start KDE, it loads, and >> gets so far as showing the FreeBSD wallpaper, then panics: >> >> >> text dump: http://www.allanjude.com/bsd/i915_core.3.txt >> Full dump: (26mb compressed, 740mb original) > This is useless for anybody except you. > >> http://www.allanjude.com/bsd/i915_vmcore.3.xz >> >> Unread portion of the kernel message buffer: >> panic: In GPU write domain >> cpuid = 3 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe045e52e600 >> vpanic() at vpanic+0x189/frame 0xfffffe045e52e680 >> kassert_panic() at kassert_panic+0x132/frame 0xfffffe045e52e6f0 >> i915_gem_pread_ioctl() at i915_gem_pread_ioctl+0x678/frame >> 0xfffffe045e52e790 >> drm_ioctl() at drm_ioctl+0x318/frame 0xfffffe045e52e800 >> devfs_ioctl_f() at devfs_ioctl_f+0x122/frame 0xfffffe045e52e860 >> kern_ioctl() at kern_ioctl+0x2c0/frame 0xfffffe045e52e8c0 >> sys_ioctl() at sys_ioctl+0x153/frame 0xfffffe045e52e9a0 >> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe045e52eab0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe045e52eab0 >> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8022a56fa, rsp = >> 0x7fffffffe718, rbp = 0x7fffffffe740 --- >> KDB: enter: panic >> Uptime: 9m19s >> Dumping 739 out of 16176 >> MB:..3%..11%..22%..31%..42%..52%..61%..72%..81%..91% >> >> Reading symbols from /boot/kernel/i915kms.ko.symbols...done. >> Loaded symbols for /boot/kernel/i915kms.ko.symbols >> Reading symbols from /boot/kernel/drm2.ko.symbols...done. >> Loaded symbols for /boot/kernel/drm2.ko.symbols >> Reading symbols from /boot/kernel/iicbus.ko.symbols...done. >> Loaded symbols for /boot/kernel/iicbus.ko.symbols >> Reading symbols from /boot/kernel/iic.ko.symbols...done. >> Loaded symbols for /boot/kernel/iic.ko.symbols >> Reading symbols from /boot/kernel/iicbb.ko.symbols...done. >> Loaded symbols for /boot/kernel/iicbb.ko.symbols >> #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 >> ) at pcpu.h:219 >> 219 pcpu.h: No such file or directory. >> in pcpu.h >> (kgdb) #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 >> ) at pcpu.h:219 >> #1 0xffffffff80965d27 in kern_reboot (howto=Unhandled dwarf expression >> opcode 0x93 >> ) >> at /usr/src/sys/kern/kern_shutdown.c:448 >> #2 0xffffffff80966318 in vpanic (fmt=, >> ap=) at /usr/src/sys/kern/kern_shutdown.c:747 >> #3 0xffffffff80966142 in kassert_panic (fmt=) >> at /usr/src/sys/kern/kern_shutdown.c:635 >> #4 0xffffffff81e1de88 in i915_gem_pread_ioctl (dev=0xfffff8002ffd1000, >> data=0xfffffe045e52e8f0, file=) >> at >> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:3010 > >> #5 0xffffffff81e9a398 in drm_ioctl (kdev=, >> cmd=2149606492, data=0xfffffe045e52e8f0 "y", flags=Unhandled dwarf >> expression opcode 0x93 >> ) >> at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:942 >> #6 0xffffffff80849942 in devfs_ioctl_f (fp=0xfffff80009c15690, >> com=2149606492, data=0xfffffe045e52e8f0, cred=0xfffffe045e52e8f0, >> td=0xfffff80009c74000) at /usr/src/sys/fs/devfs/devfs_vnops.c:775 >> #7 0xffffffff809c3ad0 in kern_ioctl (td=0xfffff80009c74000, >> fd=, com=0, data=) at >> file.h:318 >> #8 0xffffffff809c3763 in sys_ioctl (td=0xfffff80009c74000, >> uap=0xfffffe045e52ea40) at /usr/src/sys/kern/sys_generic.c:718 >> #9 0xffffffff80d8590a in amd64_syscall (td=0xfffff80009c74000, traced=0) >> at subr_syscall.c:133 >> #10 0xffffffff80d632ab in Xfast_syscall () >> at /usr/src/sys/amd64/amd64/exception.S:395 >> #11 0x00000008022a56fa in ?? () >> Previous frame inner to this frame (corrupt stack?) >> Current language: auto; currently minimal >> > > Is this reproducable ? > > Try the following patch on top of i915.8. > > commit 9af6c652745f551e2b6ce5218e350a5e47999feb > Author: Konstantin Belousov > Date: Wed Jan 7 20:21:46 2015 +0200 > > Properly move object into gtt domain when needed. > > diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.c > index 0f72d08..58cbb59 100644 > --- a/sys/dev/drm2/i915/i915_gem.c > +++ b/sys/dev/drm2/i915/i915_gem.c > @@ -1251,7 +1251,7 @@ i915_gem_shmem_pread(struct drm_device *dev, > * optimizes for the case when the gpu will dirty the data > * anyway again before the next pread happens. */ > needs_clflush = !cpu_cache_is_coherent(dev, obj->cache_level); > - ret = i915_gem_object_wait_rendering(obj); > + ret = i915_gem_object_set_to_gtt_domain(obj, false); > if (ret) > return ret; > } > @@ -1579,7 +1579,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev, > * optimizes for the case when the gpu will use the data > * right away and we therefore have to clflush anyway. */ > needs_clflush_after = cpu_write_needs_clflush(obj); > - ret = i915_gem_object_wait_rendering(obj); > + ret = i915_gem_object_set_to_gtt_domain(obj, true); > if (ret) > return ret; > } > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 07:12:47 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F108BDE7 for ; Tue, 20 Jan 2015 07:12:47 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8036F62 for ; Tue, 20 Jan 2015 07:12:47 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YDSzV-0002J7-9X for freebsd-current@freebsd.org; Tue, 20 Jan 2015 08:12:45 +0100 Date: Tue, 20 Jan 2015 08:12:45 +0100 From: Kurt Jaeger To: freebsd-current@freebsd.org Subject: Broadwell support ? Message-ID: <20150120071245.GY44537@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 07:12:48 -0000 Hi! Is the state of Broadwell support sufficient to play around with it on new laptops ? Thanks! -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 07:22:03 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6AFDF64 for ; Tue, 20 Jan 2015 07:22:03 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 941AEAF for ; Tue, 20 Jan 2015 07:22:03 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1YDT8T-000id6-1J>; Tue, 20 Jan 2015 08:22:01 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=prometheus) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1YDT8S-001Wl6-U0>; Tue, 20 Jan 2015 08:22:01 +0100 Date: Tue, 20 Jan 2015 08:20:29 +0100 From: "O. Hartmann" To: Kurt Jaeger Subject: Re: Broadwell support ? Message-ID: <20150120082029.77ba994a@prometheus> In-Reply-To: <20150120071245.GY44537@home.opsec.eu> References: <20150120071245.GY44537@home.opsec.eu> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 07:22:03 -0000 On Tue, 20 Jan 2015 08:12:45 +0100 Kurt Jaeger wrote: > Hi! > > Is the state of Broadwell support sufficient to play around with > it on new laptops ? > > Thanks! > I doubt this, a look at Haswell and its support (concerning iGPU) should be sufficient. From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 07:28:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47BAE2D9; Tue, 20 Jan 2015 07:28:59 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F21DBE6; Tue, 20 Jan 2015 07:28:58 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4F3A11FE023; Tue, 20 Jan 2015 08:28:56 +0100 (CET) Message-ID: <54BE03EB.2070604@selasky.org> Date: Tue, 20 Jan 2015 08:29:47 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jason Wolfe , John Baldwin Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <54BADFB3.3030405@selasky.org> In-Reply-To: <54BADFB3.3030405@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 07:28:59 -0000 On 01/17/15 23:18, Hans Petter Selasky wrote: > On 01/17/15 20:11, Jason Wolfe wrote: >> >> HPS, >> >> Just to give a quick status update, this patch has most certainly >> resolved our spin lock held too long panics on stable/10. >> >> Thank you to JHB for spending some time digging into the issue and >> leading us to td_slpcallout as the culprit, and HPS for your rewrite. >> I had heard rumors of other being affected by similar issues, so this >> seems like a fine candidate for an MFC if possible. >> >> Jason >> > > Hi Jason, > > I'm glad to hear that my patch has resolved your issue and I'm happy we > now have a more stable system. > > It was actually a co-worker at work which wrote some bad code which I > started debugging which then lead me to look at the callout subsystem. > One bug kills the other ;-) > > I'm planning a MFC to 10-stable - yes, and will possibly add the > _callout_stop_safe() function to not break binary compatibility with > existing drivers as part of the MFC. > > --HPS Hi, Here is a followup patch for the TCP stack like I mentioned in the beginning of the work done on the callout subsystem: https://reviews.freebsd.org/D1563 If someone has a setup for massive TCP testing please give it a spin. Thank you! --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 07:55:22 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0218909 for ; Tue, 20 Jan 2015 07:55:21 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id B325C3A4 for ; Tue, 20 Jan 2015 07:55:21 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 2ACF48E3E4 for ; Tue, 20 Jan 2015 07:55:20 +0000 (UTC) Message-ID: <54BE09EF.1010407@freebsd.org> Date: Tue, 20 Jan 2015 02:55:27 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: i915 crash References: <54ACCBB3.1080906@freebsd.org> <20150107182314.GO42409@kib.kiev.ua> In-Reply-To: <20150107182314.GO42409@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ifvu7DGWNNPgxcE5ADRDAxO7lBKAqOvoJ" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 07:55:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ifvu7DGWNNPgxcE5ADRDAxO7lBKAqOvoJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Very sorry, I didn't see your reply until Adrian's reply brought this thread back to the top of my email stack. On 2015-01-07 13:23, Konstantin Belousov wrote: > On Wed, Jan 07, 2015 at 01:01:23AM -0500, Allan Jude wrote: >> I grabbed the latest i915.8.patch from kib@'s website and compiled it >> against r276774 (today) >> >> Machine is a Lenovo T530, booted UEFI, with the nvidia GPU disabled. >> >> CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz (2594.16-MHz K8-class CP= U) >> >> It is an Ivy-bridge CPU/GPU >> >> I installed xorg and kde, and when I try to start KDE, it loads, and >> gets so far as showing the FreeBSD wallpaper, then panics: >> >=20 > Is this reproducable ? Yes, every time I try to start KDE it panics. Verified 3 times in a row. >=20 > Try the following patch on top of i915.8. This patch fixes the panic. I can run KDE and enjoy all the graphical goodness. Thank you >=20 > commit 9af6c652745f551e2b6ce5218e350a5e47999feb > Author: Konstantin Belousov > Date: Wed Jan 7 20:21:46 2015 +0200 >=20 > Properly move object into gtt domain when needed. >=20 > diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.= c > index 0f72d08..58cbb59 100644 > --- a/sys/dev/drm2/i915/i915_gem.c > +++ b/sys/dev/drm2/i915/i915_gem.c > @@ -1251,7 +1251,7 @@ i915_gem_shmem_pread(struct drm_device *dev, > * optimizes for the case when the gpu will dirty the data > * anyway again before the next pread happens. */ > needs_clflush =3D !cpu_cache_is_coherent(dev, obj->cache_level); > - ret =3D i915_gem_object_wait_rendering(obj); > + ret =3D i915_gem_object_set_to_gtt_domain(obj, false); > if (ret) > return ret; > } > @@ -1579,7 +1579,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev, > * optimizes for the case when the gpu will use the data > * right away and we therefore have to clflush anyway. */ > needs_clflush_after =3D cpu_write_needs_clflush(obj); > - ret =3D i915_gem_object_wait_rendering(obj); > + ret =3D i915_gem_object_set_to_gtt_domain(obj, true); > if (ret) > return ret; > } > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 --=20 Allan Jude --Ifvu7DGWNNPgxcE5ADRDAxO7lBKAqOvoJ 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.22 (MingW32) iQIcBAEBAgAGBQJUvgnyAAoJEJrBFpNRJZKftRIP/1I8qDHk+apB39/gnQrwdDb8 1u9SXyuSbcw1Gkq+sOxRb9tQVH+JGmqmob4eI9Qw2tCSY0ZtItWCt6pdkL/Y0ht+ EhlAnhE0X1t1u39yLBQeWs1OJ7m7CJBIhZ44qywyfR7NMPCMmvh3sZ23Cxe8SRu1 zQ0l5GtLa21zLmNHAzgM99GLkSCtgPVmi21GMwV+KbeM/wUwo2iKKkq+FapbWOJg Hkb9Vedjom0WkZOMj2d5wylA2ERBd4zeEkajmmIMnBm29utMgETHelZXLh5CkbWU Anl9OA82Xg+5oBlGTzyxlsfRIjcL4LAiy+lYdGVSa0AzyftT56/IOGNDiTuLh6si c7LTgc3ma7bz+U/Iaj2mnOf2F6L3fg3R3KIScNlTbVCh9sGaUnNyZ1jMnGX/IAd8 Su5ZPXu/58ruvyPbwG22Cipv7sf8PAHCM1pYtR3TlNht2HRMnapt+wM8HMlkV/80 c8DCbIBxEJQIsQlCf4WFKqgnye9t2Pr4P1QSitPl9lMRJ01AB+5OESoI4me3PAdx NROskvLy2GM3tEXjV1WCSxPqbsZtrowd0JH4dogTo+fmROAKHq7WjvZc+gKWiDxa rth8vXLEp18fzgwbpEG264eWcOWsC41gi7fi8H5jve/ljlks0nKqZDcem4u13W+q txQrFoAr1LKv2iFTLwNA =VkM2 -----END PGP SIGNATURE----- --Ifvu7DGWNNPgxcE5ADRDAxO7lBKAqOvoJ-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 08:55:13 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 280287DA for ; Tue, 20 Jan 2015 08:55:13 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id DFE0DBD0 for ; Tue, 20 Jan 2015 08:55:12 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id CA31E3BD50 for ; Tue, 20 Jan 2015 08:55:05 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t0K8t5ws001187 for ; Tue, 20 Jan 2015 08:55:05 GMT (envelope-from phk@phk.freebsd.dk) To: current@freebsd.org Subject: Current trouble From: Poul-Henning Kamp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1185.1421744105.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jan 2015 08:55:05 +0000 Message-ID: <1186.1421744105@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 08:55:13 -0000 I just tried current as of yesterday and had to give up rather quickly. unbound sig#11'ed on bootup, couldn't find a coredump. Trying to read a PDF file with evince I got one: $ evince Fatal error 'mutex is on list' at line 424 in file /freebsd/svn_src/head/l= ib/libthr/thread/thr_mutex.c (errno =3D 2) Abort (core dumped) Backtrace looks like: #0 0x000000080457648a in thr_kill () from /lib/libc.so.7 #1 0x00000008045763f8 in raise () from /lib/libc.so.7 #2 0x0000000804574959 in abort () from /lib/libc.so.7 #3 0x000000080422660a in pthread_attr_getaffinity_np () from /lib/libthr.= so.3 #4 0x0000000804221c00 in pthread_mutex_destroy () from /lib/libthr.so.3 #5 0x0000000810ee0aa9 in Array::decRef () from /usr/local/lib/libpoppler.= so.46 #6 0x0000000810f524ef in Object::free () from /usr/local/lib/libpoppler.s= o.46 #7 0x0000000810f07408 in Gfx::go () from /usr/local/lib/libpoppler.so.46 #8 0x0000000810f06ecb in Gfx::display () from /usr/local/lib/libpoppler.s= o.46 #9 0x0000000810f57058 in Page::displaySlice () from /usr/local/lib/libpoppler.so.46 #10 0x0000000810a3b3e2 in _poppler_page_render () from /usr/local/lib/libpoppler-glib.so.8 #11 0x000000081080df51 in register_evince_backend () from /usr/local/lib/evince/4/backends/libpdfdocument.so #12 0x000000081080d2c5 in register_evince_backend () from /usr/local/lib/evince/4/backends/libpdfdocument.so #13 0x0000000800ae4cc1 in ev_job_print_set_cairo () from /usr/local/lib/libevview3.so.3 #14 0x0000000800ae5bc0 in ev_job_scheduler_get_running_thread_job () from /usr/local/lib/libevview3.so.3 #15 0x00000008039360fa in g_thread_proxy () from /usr/local/lib/libglib-2.0.so.0 #16 0x000000080421b6e4 in pthread_create () from /lib/libthr.so.3 #17 0x0000000000000000 in ?? () I'm not sure if these two observations are connected, but it was enough to make -current unworkable for me... -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 10:47:47 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CB9811F; Tue, 20 Jan 2015 10:47:47 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4EFAA7E; Tue, 20 Jan 2015 10:47:46 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YDWLQ-000CZz-VR; Tue, 20 Jan 2015 13:47:36 +0300 Date: Tue, 20 Jan 2015 13:47:36 +0300 From: Slawa Olhovchenkov To: Hans Petter Selasky Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress Message-ID: <20150120104736.GA78629@zxy.spb.ru> References: <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <54BADFB3.3030405@selasky.org> <54BE03EB.2070604@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BE03EB.2070604@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Adrian Chadd , FreeBSD Current , Jason Wolfe , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 10:47:47 -0000 On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote: > On 01/17/15 23:18, Hans Petter Selasky wrote: > > On 01/17/15 20:11, Jason Wolfe wrote: > >> > >> HPS, > >> > >> Just to give a quick status update, this patch has most certainly > >> resolved our spin lock held too long panics on stable/10. > >> > >> Thank you to JHB for spending some time digging into the issue and > >> leading us to td_slpcallout as the culprit, and HPS for your rewrite. > >> I had heard rumors of other being affected by similar issues, so this > >> seems like a fine candidate for an MFC if possible. > >> > >> Jason > >> > > > > Hi Jason, > > > > I'm glad to hear that my patch has resolved your issue and I'm happy we > > now have a more stable system. > > > > It was actually a co-worker at work which wrote some bad code which I > > started debugging which then lead me to look at the callout subsystem. > > One bug kills the other ;-) > > > > I'm planning a MFC to 10-stable - yes, and will possibly add the > > _callout_stop_safe() function to not break binary compatibility with > > existing drivers as part of the MFC. > > > > --HPS > > Hi, > > Here is a followup patch for the TCP stack like I mentioned in the > beginning of the work done on the callout subsystem: > > https://reviews.freebsd.org/D1563 > > If someone has a setup for massive TCP testing please give it a spin. I have on 10.1 (with applied r261906). From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 11:46:11 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8295717C; Tue, 20 Jan 2015 11:46:11 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10C0D14E; Tue, 20 Jan 2015 11:46:10 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 7C2AF16A40B; Tue, 20 Jan 2015 12:45:57 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4UoEo7xHbEK; Tue, 20 Jan 2015 12:45:35 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e] (unknown [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e]) by smtp.digiware.nl (Postfix) with ESMTP id 0DD9F16A405; Tue, 20 Jan 2015 12:45:35 +0100 (CET) Message-ID: <54BE3FDC.9030904@digiware.nl> Date: Tue, 20 Jan 2015 12:45:32 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: d@delphij.net, Garrett Cooper , Brandon Allbery Subject: Re: old bug: mount_nfs path/name is limited to 88 chars References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> <54BDA9DD.5040608@delphij.net> In-Reply-To: <54BDA9DD.5040608@delphij.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: mexas@bris.ac.uk, rmacklem@uoguelph.ca, freebsd-stable , freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 11:46:11 -0000 On 2015-01-20 2:05, Xin Li wrote: >> Doing it in 11 makes sense since there is a compat layer for 10 >> now… if I knew all of the steps I would happily do them as annoys >> me from time to time as well with the path length issue. > > Compat layer may break applications in other funny ways and we > probably have to return e.g. ENAMETOOLONG for legacy applications if > the names are too long to fit into the buffer, but I don't see any > easy solution either: I wish we have bumped it in 2003 when the struct > receives its first big revamp by bumping all statistic fields to 64-bit. On 2015-01-20 1:23, Allan Jude wrote:> On 2015-01-19 16:20, Garrett > > Especially with ZFS, I find I have a lot more mounts now, under longer > and longer path names, and then I have > .zfs/snapshots/snapshotnamehere/path/to/file > > etc. > > Definitely a +1 for "this is something we need for 11" +1 Well to be honest: Things are already broken for me ATM. I do have paths that are too long, and tools trip over it. Things like building the locate database just don't have everything. Which is a pain, especially for finding things fast in backups of ZFS, where the path is even more convoluted that what Allan suggests So whether being bitten by the cat of the dog: it still hurts. Perhaps it is an intermediate solution to add new settings which are going to be used for userspace programs, like USER_MNAMELEN and USER_PATH_MAX. It will certainly give ENAMETOOLONG back when it involves systemcalls. But then a lot of the other tool stuff would just function. --WjW From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 17:07:42 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7128A197 for ; Tue, 20 Jan 2015 17:07:42 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13AEBC74 for ; Tue, 20 Jan 2015 17:07:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0KH7apo005421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2015 19:07:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0KH7apo005421 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0KH7YCW005420; Tue, 20 Jan 2015 19:07:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 20 Jan 2015 19:07:34 +0200 From: Konstantin Belousov To: Poul-Henning Kamp Subject: Re: Current trouble Message-ID: <20150120170734.GJ42409@kib.kiev.ua> References: <1186.1421744105@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1186.1421744105@critter.freebsd.dk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 17:07:42 -0000 On Tue, Jan 20, 2015 at 08:55:05AM +0000, Poul-Henning Kamp wrote: > I just tried current as of yesterday and had to give up rather quickly. > > unbound sig#11'ed on bootup, couldn't find a coredump. > > Trying to read a PDF file with evince I got one: > > $ evince > Fatal error 'mutex is on list' at line 424 in file /freebsd/svn_src/head/lib/libthr/thread/thr_mutex.c (errno = 2) > Abort (core dumped) This message typically mean that non-async signal safe function was called after fork in the multithreaded process. Cannot say anything more useful. The backtrace below clearly indicates that a new thread was in the process of being created, but what was the global state of process ? > > Backtrace looks like: > > #0 0x000000080457648a in thr_kill () from /lib/libc.so.7 > #1 0x00000008045763f8 in raise () from /lib/libc.so.7 > #2 0x0000000804574959 in abort () from /lib/libc.so.7 > #3 0x000000080422660a in pthread_attr_getaffinity_np () from /lib/libthr.so.3 > #4 0x0000000804221c00 in pthread_mutex_destroy () from /lib/libthr.so.3 > #5 0x0000000810ee0aa9 in Array::decRef () from /usr/local/lib/libpoppler.so.46 > #6 0x0000000810f524ef in Object::free () from /usr/local/lib/libpoppler.so.46 > #7 0x0000000810f07408 in Gfx::go () from /usr/local/lib/libpoppler.so.46 > #8 0x0000000810f06ecb in Gfx::display () from /usr/local/lib/libpoppler.so.46 > #9 0x0000000810f57058 in Page::displaySlice () > from /usr/local/lib/libpoppler.so.46 > #10 0x0000000810a3b3e2 in _poppler_page_render () > from /usr/local/lib/libpoppler-glib.so.8 > #11 0x000000081080df51 in register_evince_backend () > from /usr/local/lib/evince/4/backends/libpdfdocument.so > #12 0x000000081080d2c5 in register_evince_backend () > from /usr/local/lib/evince/4/backends/libpdfdocument.so > #13 0x0000000800ae4cc1 in ev_job_print_set_cairo () > from /usr/local/lib/libevview3.so.3 > #14 0x0000000800ae5bc0 in ev_job_scheduler_get_running_thread_job () > from /usr/local/lib/libevview3.so.3 > #15 0x00000008039360fa in g_thread_proxy () > from /usr/local/lib/libglib-2.0.so.0 > #16 0x000000080421b6e4 in pthread_create () from /lib/libthr.so.3 > #17 0x0000000000000000 in ?? () > > I'm not sure if these two observations are connected, but it was enough > to make -current unworkable for me... > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 19:02:47 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E86127AA; Tue, 20 Jan 2015 19:02:47 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2B54BCF; Tue, 20 Jan 2015 19:02:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AF7A3B9A5; Tue, 20 Jan 2015 14:02:46 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [PATCH] nmbclusters should be always positive Date: Tue, 20 Jan 2015 11:19:23 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201501201119.23123.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Jan 2015 14:02:46 -0500 (EST) Cc: Davide Italiano X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 20 Jan 2015 19:02:48 -0000 On Monday, January 19, 2015 6:12:25 pm Davide Italiano wrote: > Currently, the following is allowed in FreeBSD: > > root@rabbit1:/home/davide/udp-clt # sysctl kern.ipc.nmbclusters=2147483647 > kern.ipc.nmbclusters: 2036598 -> -2147483648 > > The following is an attempt of fixing. > I also think nmbcluster should actually be u_int and not it, but this > is a discussion for another day, maybe. > > diff --git a/sys/kern/kern_mbuf.c b/sys/kern/kern_mbuf.c > index 7ab6509..15b38a9 100644 > --- a/sys/kern/kern_mbuf.c > +++ b/sys/kern/kern_mbuf.c > @@ -162,7 +162,7 @@ sysctl_nmbclusters(SYSCTL_HANDLER_ARGS) > newnmbclusters = nmbclusters; > error = sysctl_handle_int(oidp, &newnmbclusters, 0, req); > if (error == 0 && req->newptr && newnmbclusters != nmbclusters) { > - if (newnmbclusters > nmbclusters && > + if (newnmbclusters > 0 && newnmbclusters > nmbclusters && > nmbufs >= nmbclusters + nmbjumbop + nmbjumbo9 + > nmbjumbo16) { > nmbclusters = newnmbclusters; > nmbclusters = uma_zone_set_max(zone_clust, nmbclusters); 1) If you fix this one you need to fix the other handlers in this file (all the jumbo ones, etc.) 2) Shouldn't the 'newnmbclusters > nmbclusters' check catch this already? That should fail right? Might be worth figuring out why it isn't. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 09:46:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7268A14 for ; Wed, 21 Jan 2015 09:46:42 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 668F937D for ; Wed, 21 Jan 2015 09:46:42 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 5788816A405 for ; Wed, 21 Jan 2015 10:46:38 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ6_8hP7CYkL; Wed, 21 Jan 2015 10:46:37 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e] (unknown [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e]) by smtp.digiware.nl (Postfix) with ESMTP id D4E5116A408 for ; Wed, 21 Jan 2015 10:34:36 +0100 (CET) Message-ID: <54BF72A9.5000608@digiware.nl> Date: Wed, 21 Jan 2015 10:34:33 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FreeBSD Current Subject: Head not buildin in zfs.c Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Jan 2015 09:46:42 -0000 Found this lastnight build. Just fetched the most recent HEAD. Error remains --- zfs/zfs.o --- In file included from /usr/srcs/src11/src/lib/libprocstat/zfs/../zfs.c:39: /usr/srcs/src11/src/lib/libprocstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:538:9: error: 'NSEC_TO_TICK' macro redefined [-Werror,-Wmacro-redefined] #define NSEC_TO_TICK(usec) ((usec) / (NANOSEC / hz)) ^ /usr/srcs/src11/src/lib/libprocstat/zfs/../../../sys/cddl/compat/opensolaris/sys/time.h:54:9: note: previous definition is here #define NSEC_TO_TICK(nsec) ((nsec) / (NANOSEC / hz)) ^ /etc/{make,src}.conf are empty --WjW From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 09:51:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92A95D15 for ; Wed, 21 Jan 2015 09:51:53 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E22165C for ; Wed, 21 Jan 2015 09:51:53 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id y10so9278810pdj.9 for ; Wed, 21 Jan 2015 01:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2G+3GH0blk9Id0ouoF0mVTJ7xFh/sxTq/z6uV05JEBM=; b=gL/Neod6PZBNDUpDDyHwHPc1p7BhePt6+8mMT/HkrZvnsO9/GVY2uoeYui8qTNmiZc fYO9I0ZEsD+M/giL2m3LmfZnyPT3gFm/9NnRjKiqFwXtgtI5Lf/2ZKlOi+jl6q4xXtcP m3hROs/lXAFezbjcTnmMo+DGAOELam2QJwYUi6/V9I6Ag7RCmMFPmyatV2RZdWfxvFLZ 8JwaMA0Y5BJXiLvDZ/Xq1JltBTAv2Rl7FvHAn8FE/a29dHABowGpSOG8HyLZHFPrCHAx YRJJd6rys8dFuDq+lAot6OccP4IJCxmaSt94yt2RWJ9t7C5QjqLEl47YnnPVRMW3vvuY zS4w== X-Received: by 10.67.1.132 with SMTP id bg4mr26957702pad.151.1421833912951; Wed, 21 Jan 2015 01:51:52 -0800 (PST) Received: from neil.creepingfur.org (ashpool.creepingfur.is. [70.36.196.189]) by mx.google.com with ESMTPSA id s7sm2521011pdj.22.2015.01.21.01.51.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 01:51:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Head not buildin in zfs.c From: Benjamin Perrault In-Reply-To: <54BF72A9.5000608@digiware.nl> Date: Wed, 21 Jan 2015 01:51:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <31627BCE-2B7A-44AA-9442-2D9347C1F571@gmail.com> References: <54BF72A9.5000608@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1993) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Jan 2015 09:51:53 -0000 > On Jan 21, 2015, at 1:34 AM, Willem Jan Withagen = wrote: >=20 >=20 > Found this lastnight build. > Just fetched the most recent HEAD. > Error remains >=20 > --- zfs/zfs.o --- > In file included from = /usr/srcs/src11/src/lib/libprocstat/zfs/../zfs.c:39: > = /usr/srcs/src11/src/lib/libprocstat/zfs/../../../cddl/contrib/opensolaris/= lib/libzpool/common/sys/zfs_context.h:538:9: error: 'NSEC_TO_TICK' macro = redefined [-Werror,-Wmacro-redefined] > #define NSEC_TO_TICK(usec) ((usec) / (NANOSEC / hz)) > ^ > = /usr/srcs/src11/src/lib/libprocstat/zfs/../../../sys/cddl/compat/opensolar= is/sys/time.h:54:9: note: previous definition is here > #define NSEC_TO_TICK(nsec) ((nsec) / (NANOSEC / hz)) > ^ > /etc/{make,src}.conf are empty >=20 > --WjW > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" I=E2=80=99m seeing the exact same issue. It began for me at r277472 and = is still persisting as of r277482 ( the most recent HEAD as of writing = this email ). cheers and thanks, -bp= From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 10:05:40 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D398FE2 for ; Wed, 21 Jan 2015 10:05:40 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DBE177E7 for ; Wed, 21 Jan 2015 10:05:39 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 8731616A405; Wed, 21 Jan 2015 11:05:35 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfxLxTzY9zQG; Wed, 21 Jan 2015 11:05:25 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e] (unknown [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e]) by smtp.digiware.nl (Postfix) with ESMTP id 179A816A403; Wed, 21 Jan 2015 11:05:25 +0100 (CET) Message-ID: <54BF79E1.3060401@digiware.nl> Date: Wed, 21 Jan 2015 11:05:21 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Benjamin Perrault Subject: Re: Head not buildin in zfs.c References: <54BF72A9.5000608@digiware.nl> <31627BCE-2B7A-44AA-9442-2D9347C1F571@gmail.com> In-Reply-To: <31627BCE-2B7A-44AA-9442-2D9347C1F571@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Jan 2015 10:05:40 -0000 On 2015-01-21 10:51, Benjamin Perrault wrote: > >> On Jan 21, 2015, at 1:34 AM, Willem Jan Withagen >> wrote: >> >> >> Found this lastnight build. Just fetched the most recent HEAD. >> Error remains >> >> --- zfs/zfs.o --- In file included from >> /usr/srcs/src11/src/lib/libprocstat/zfs/../zfs.c:39: >> /usr/srcs/src11/src/lib/libprocstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:538:9: >> error: 'NSEC_TO_TICK' macro redefined [-Werror,-Wmacro-redefined] >> #define NSEC_TO_TICK(usec) ((usec) / (NANOSEC / hz)) ^ >> /usr/srcs/src11/src/lib/libprocstat/zfs/../../../sys/cddl/compat/opensolaris/sys/time.h:54:9: >> note: previous definition is here #define NSEC_TO_TICK(nsec) >> ((nsec) / (NANOSEC / hz)) ^ /etc/{make,src}.conf are empty >> > I’m seeing the exact same issue. It began for me at r277472 and is > still persisting as of r277482 ( the most recent HEAD as of writing > this email ). Well, the problem is reported several times during compilation. This is the first warning that also has -Werror, and hence building stops. I have not been able to find where this -Werror "all of a sudden" pops up. Has to be in any of those commits... --WjW From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 10:09:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77E801F5; Wed, 21 Jan 2015 10:09:20 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DB3F833; Wed, 21 Jan 2015 10:09:20 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id fp1so24049514pdb.4; Wed, 21 Jan 2015 02:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=BenPNd23R/cymC/Sba6sKdeTHFOLMr0jH+vK+PuEpbE=; b=xGA4bs3UW0c5L6S3pl6uXulgZKkkEqvf4+mHaCkY599ytXpm9V8XbAl2m7n7LvUPv7 /HYeMYFFwcXIHIJZr0JMAnw2yXQlB14ht8XeJ8QhVmRWZq4cyOZuI0e/vCRW8AZ0hUW5 QF4xpxvy6FUqVSSFN0Gz9cDIerMpaw8pnw85NqfnESL5IiKsoLxwp1ckxI/S4DuoSWoH EQg/Hk98y1mmCl4iNroGy1INzOs7cn8ShUZhSVxlCoTIIUMHE5s9u/oMSTPnlzOrEIFc ro72fCb+2a0EN60ZfP9UbfyaamU3xH7YRi3e6+aeNWXIR8ApqN/9wmMtnzlYSbU00hEZ 38wA== X-Received: by 10.68.132.229 with SMTP id ox5mr61394418pbb.94.1421834959812; Wed, 21 Jan 2015 02:09:19 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:18f4:9d77:102c:ab55? ([2601:8:ab80:7d6:18f4:9d77:102c:ab55]) by mx.google.com with ESMTPSA id pm2sm5381487pbb.81.2015.01.21.02.09.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 02:09:19 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E9204763-C9A2-44CA-A614-9579DBEF342C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Head not buildin in zfs.c From: Garrett Cooper In-Reply-To: <54BF79E1.3060401@digiware.nl> Date: Wed, 21 Jan 2015 02:08:54 -0800 Message-Id: References: <54BF72A9.5000608@digiware.nl> <31627BCE-2B7A-44AA-9442-2D9347C1F571@gmail.com> <54BF79E1.3060401@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1878.6) Cc: Benjamin Perrault , FreeBSD Current , Will Andrews X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Jan 2015 10:09:20 -0000 --Apple-Mail=_E9204763-C9A2-44CA-A614-9579DBEF342C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 21, 2015, at 2:05, Willem Jan Withagen wrote: > On 2015-01-21 10:51, Benjamin Perrault wrote: >>=20 >>> On Jan 21, 2015, at 1:34 AM, Willem Jan Withagen >>> wrote: >>>=20 >>>=20 >>> Found this lastnight build. Just fetched the most recent HEAD. >>> Error remains >>>=20 >>> --- zfs/zfs.o --- In file included from >>> /usr/srcs/src11/src/lib/libprocstat/zfs/../zfs.c:39: >>> = /usr/srcs/src11/src/lib/libprocstat/zfs/../../../cddl/contrib/opensolaris/= lib/libzpool/common/sys/zfs_context.h:538:9: >>> error: 'NSEC_TO_TICK' macro redefined [-Werror,-Wmacro-redefined] >>> #define NSEC_TO_TICK(usec) ((usec) / (NANOSEC / hz)) ^ >>> = /usr/srcs/src11/src/lib/libprocstat/zfs/../../../sys/cddl/compat/opensolar= is/sys/time.h:54:9: >>> note: previous definition is here #define NSEC_TO_TICK(nsec) >>> ((nsec) / (NANOSEC / hz)) ^ /etc/{make,src}.conf are empty >>>=20 >=20 >> I=92m seeing the exact same issue. It began for me at r277472 and is >> still persisting as of r277482 ( the most recent HEAD as of writing >> this email ). >=20 > Well, the problem is reported several times during compilation. > This is the first warning that also has -Werror, and hence building = stops. >=20 > I have not been able to find where this -Werror "all of a sudden" pops = up. >=20 > Has to be in any of those commits... It=92s a mismatch in the macro definitions, made in the commit = below. I=92m testing out a fix for it right now. Thanks for the report! ------------------------------------------------------------------------ r277449 | will | 2015-01-20 14:29:27 -0800 (Tue, 20 Jan 2015) | 2 lines NSEC_TO_TICK(usec) -> NSEC_TO_TICK(nsec) --Apple-Mail=_E9204763-C9A2-44CA-A614-9579DBEF342C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUv3q2AAoJEMZr5QU6S73e22QH/2GvMa6XZ89HqwbPz8+y0mHu m/CVTijTCzvrXH9ECQuTr6oV7k1VMap1I5PMsbeqnaZyVrM6dDL3PhlMpVDuq1rF lhOQIIjrkWMROR4wa4XYaaJWq8HByILXFL5+iquEmDFvSWkM+5UnF4NCm1FvAq4D Q54Xni/cITbLDs+Mj7wEeNCtPYF6QnoMDrfoxyn9/nyqaAuZTBfWJ6b0IQBnYb1o a4zPURG41LKaNsGwcRbJyPQXRvEotWHKuCo/jOff+BsG5i+u29Il605KsLiPXXkO QFIGll60FSslCK9E1SBxpKqnJa8GyUDxWxPoI+3y8GMy4k2DjK2lh8CFmW4OOPI= =X8nr -----END PGP SIGNATURE----- --Apple-Mail=_E9204763-C9A2-44CA-A614-9579DBEF342C-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 10:17:22 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E96023B4; Wed, 21 Jan 2015 10:17:22 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A240F91B; Wed, 21 Jan 2015 10:17:22 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 725A816A403; Wed, 21 Jan 2015 11:17:20 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3Mue_PUkLde; Wed, 21 Jan 2015 11:17:19 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e] (unknown [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e]) by smtp.digiware.nl (Postfix) with ESMTP id 323AA16A401; Wed, 21 Jan 2015 11:17:19 +0100 (CET) Message-ID: <54BF7CAB.4050008@digiware.nl> Date: Wed, 21 Jan 2015 11:17:15 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: Head not buildin in zfs.c References: <54BF72A9.5000608@digiware.nl> <31627BCE-2B7A-44AA-9442-2D9347C1F571@gmail.com> <54BF79E1.3060401@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Benjamin Perrault , FreeBSD Current , Will Andrews X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Jan 2015 10:17:23 -0000 On 2015-01-21 11:08, Garrett Cooper wrote: > On Jan 21, 2015, at 2:05, Willem Jan Withagen wrote: > >> On 2015-01-21 10:51, Benjamin Perrault wrote: >>> >>>> On Jan 21, 2015, at 1:34 AM, Willem Jan Withagen >>>> wrote: >>>> >>>> >>>> Found this lastnight build. Just fetched the most recent HEAD. >>>> Error remains >>>> >>>> --- zfs/zfs.o --- In file included from >>>> /usr/srcs/src11/src/lib/libprocstat/zfs/../zfs.c:39: >>>> /usr/srcs/src11/src/lib/libprocstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:538:9: >>>> error: 'NSEC_TO_TICK' macro redefined [-Werror,-Wmacro-redefined] >>>> #define NSEC_TO_TICK(usec) ((usec) / (NANOSEC / hz)) ^ >>>> /usr/srcs/src11/src/lib/libprocstat/zfs/../../../sys/cddl/compat/opensolaris/sys/time.h:54:9: >>>> note: previous definition is here #define NSEC_TO_TICK(nsec) >>>> ((nsec) / (NANOSEC / hz)) ^ /etc/{make,src}.conf are empty >>>> >> >>> I’m seeing the exact same issue. It began for me at r277472 and is >>> still persisting as of r277482 ( the most recent HEAD as of writing >>> this email ). >> >> Well, the problem is reported several times during compilation. >> This is the first warning that also has -Werror, and hence building stops. >> >> I have not been able to find where this -Werror "all of a sudden" pops up. >> >> Has to be in any of those commits... > > It’s a mismatch in the macro definitions, made in the commit below. > I’m testing out a fix for it right now. > Thanks for the report! > > ------------------------------------------------------------------------ > r277449 | will | 2015-01-20 14:29:27 -0800 (Tue, 20 Jan 2015) | 2 lines > > NSEC_TO_TICK(usec) -> NSEC_TO_TICK(nsec) > Right, picky nasty compilers being fussy. ;) I did in look in the svn log of both .h files, but overlooked what you just found..... Need more coffee. I'll be waiting the the fix in the tree.. Thanx, --WjW From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 10:48:24 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07484DD8; Wed, 21 Jan 2015 10:48:24 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0CE5CA4; Wed, 21 Jan 2015 10:48:23 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kx10so7825156pab.12; Wed, 21 Jan 2015 02:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LApSwFRU1wGDzVPqu6+MPGOMC94DWvVJHIxNJoHBXbE=; b=IUbV38srmtKoWA5/aX4Xox1s7E+12hsc0leFZ8CFrE/KRoNB4ICe41deeckfsw+FCW 4zS58JlT9n7ygryzfc8KiJxmxN00jTG9XS70G9u47E3awUGi5oPhPRYi5ctq0WouqjY5 1UW1WxFCUUlPBvb6J5SnfM3+YfGcN1q+qJceCqhLgiuWqhr6rrE51/Xf994GPy8nxgQr sevFX/BfNisfVE3G0yVzAAL2AMhh4KLJ9Fc7Sp34eLeeoboCVsIBed3ku6NiIbJ7XN9G z/6ogD9y9NLdD4SZRUoOBvVUoGYuT+eVVqPqwcNmT6WT/zOPNJIzxaXfh2hzSjq5xOEE 5+8A== X-Received: by 10.67.5.42 with SMTP id cj10mr61294681pad.65.1421837303364; Wed, 21 Jan 2015 02:48:23 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:d8a3:315f:79ac:33b7? ([2601:8:ab80:7d6:d8a3:315f:79ac:33b7]) by mx.google.com with ESMTPSA id k5sm2707017pdb.14.2015.01.21.02.48.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 02:48:22 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_94047186-1861-4D68-AB66-656A13E094B1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Head not buildin in zfs.c From: Garrett Cooper In-Reply-To: <54BF7CAB.4050008@digiware.nl> Date: Wed, 21 Jan 2015 02:47:57 -0800 Message-Id: <5AD836D7-4223-4E2C-93F9-EA1C16215275@gmail.com> References: <54BF72A9.5000608@digiware.nl> <31627BCE-2B7A-44AA-9442-2D9347C1F571@gmail.com> <54BF79E1.3060401@digiware.nl> <54BF7CAB.4050008@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1878.6) Cc: Benjamin Perrault , FreeBSD Current , Will Andrews X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Jan 2015 10:48:24 -0000 --Apple-Mail=_94047186-1861-4D68-AB66-656A13E094B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 21, 2015, at 2:17, Willem Jan Withagen wrote: =85 > Right, picky nasty compilers being fussy. ;) >=20 > I did in look in the svn log of both .h files, but overlooked what you = just found..... Need more coffee. >=20 > I'll be waiting the the fix in the tree.. Fixed in r277484 =97 thanks! --Apple-Mail=_94047186-1861-4D68-AB66-656A13E094B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUv4PdAAoJEMZr5QU6S73euhsH/2keD8lKRIde5RBQfF+ttVD5 9OJTvs+ycyPbIJaFujU/E4rY4eo2KrbhXHGLbKXwHbLLiOiqrDhxJJQVoGR1aBgQ /6QJ4mQQqxm++HpjH2oxIIxtvQdXR4wLF7BeQZnqOkU1ZtkrfkIiGi4oAIFbkfXT 0rlyEpdiwDWMhIoZlonTVD6biKssy0oPwPaMbHXj330HKaveaa9H7pi7/gogczfn jh7hTJ2AENfxaQ4knYpe5fUyZ7P8FVespRJ3DK0VpoYEEAP6bIFpwV9+4mevIw3R 3fa2iNe1Y1TsLHbwqgtjS+H1rXBAi8pqT4yHk0rKZFQnSOkyeRHEQR3nRUMeCjo= =I782 -----END PGP SIGNATURE----- --Apple-Mail=_94047186-1861-4D68-AB66-656A13E094B1-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 13:40:24 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 387EAB22 for ; Wed, 21 Jan 2015 13:40:24 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECE4B15A for ; Wed, 21 Jan 2015 13:40:23 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id E6E8416A405; Wed, 21 Jan 2015 14:40:19 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmzwahGFI3IH; Wed, 21 Jan 2015 14:40:18 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e] (unknown [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e]) by smtp.digiware.nl (Postfix) with ESMTP id 8F52E16A403; Wed, 21 Jan 2015 14:40:18 +0100 (CET) Message-ID: <54BFAC3E.8060708@digiware.nl> Date: Wed, 21 Jan 2015 14:40:14 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FreeBSD Current , bzeeb+freebsd+lor@zabbadoz.net Subject: LOR with bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Jan 2015 13:40:24 -0000 Hoi, Looked at: http://sources.zabbadoz.net/freebsd/lor.html#howtoreportalor But did not find any reference to ffs_vnops, so it might be a new one? I got this from running 'make installworld' of todays HEAD IN a bhyveVM which was already running thismornings kernel. So it was not the Dom0 server, but the actual version running in the VM FreeBSD-11 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r277423: Wed Jan 21 09:38:40 UTC 2015 wjw@FreeBSD-11:/usr/obj/usr/src/sys/GENERIC amd64 --WjW lock order reversal: 1st 0xfffff80009aa2240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2164 2nd 0xfffffe01ea244770 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 3rd 0xfffff801685dc418 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2164 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe02332ecd60 witness_checkorder() at witness_checkorder+0xe50/frame 0xfffffe02332ecdf0 __lockmgr_args() at __lockmgr_args+0xacf/frame 0xfffffe02332ecf20 ffs_lock() at ffs_lock+0x84/frame 0xfffffe02332ecf70 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe02332ecfa0 _vn_lock() at _vn_lock+0x8a/frame 0xfffffe02332ed010 vget() at vget+0x67/frame 0xfffffe02332ed050 vfs_hash_get() at vfs_hash_get+0xdc/frame 0xfffffe02332ed0a0 ffs_vgetf() at ffs_vgetf+0x40/frame 0xfffffe02332ed130 softdep_sync_buf() at softdep_sync_buf+0xa90/frame 0xfffffe02332ed210 ffs_syncvnode() at ffs_syncvnode+0x259/frame 0xfffffe02332ed290 ffs_truncate() at ffs_truncate+0x671/frame 0xfffffe02332ed470 ufs_direnter() at ufs_direnter+0x7d2/frame 0xfffffe02332ed530 ufs_makeinode() at ufs_makeinode+0x5bf/frame 0xfffffe02332ed6f0 ufs_symlink() at ufs_symlink+0x32/frame 0xfffffe02332ed740 VOP_SYMLINK_APV() at VOP_SYMLINK_APV+0xf7/frame 0xfffffe02332ed770 kern_symlinkat() at kern_symlinkat+0x245/frame 0xfffffe02332ed9a0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe02332edab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe02332edab0 --- syscall (57, FreeBSD ELF64, sys_symlink), rip = 0x4101ba, rsp = 0x7ffffffec3d8, rbp = 0x7ffffffec800 --- From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 15:10:08 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A738CF16 for ; Wed, 21 Jan 2015 15:10:08 +0000 (UTC) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 757F6E0F for ; Wed, 21 Jan 2015 15:10:08 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id l13so22790225iga.5 for ; Wed, 21 Jan 2015 07:10:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=TGjad2jsjS553pQ7mVBAIOPNwOceRjNxyfVd1w2TSyM=; b=YwwNpwXcr6ryvkul6QMTBx8+xfeBsilc5FH/qeVJpxVbPCZZE84joGUDEhLtw2Gb2s lblPoZNS3C5G1JNRCR8bN9dT67kGGpVZcUJq561TUSYSCyjyOQty7r3CyPFQoO62B7lT A1E3eNe16E2J2UQ0pSTAzKhzzWL0pasou7N3xndIA3NJcUU/h4yqaVjVovP0MXsKX2B5 pUXfXSnLzvvJ1A/i6WV3MAB95UM3uPkZW0pmux1o2KKJsn8EptXGdzucJeiV2stwjP47 pbN6qIUa9B0uVxunyqAVvllyn8rjBBx8zTBnMSsly9bmUdfWf1pKdELN5Z2liIJ5ijDL RuFQ== X-Gm-Message-State: ALoCoQkIcXh9vrucWgkUPyzdP7zTK9IDXP2pOYwXzCLzsFDuf2vP5Vs/sV5mfUybGaF575bB//NU X-Received: by 10.50.107.7 with SMTP id gy7mr35066060igb.49.1421853007441; Wed, 21 Jan 2015 07:10:07 -0800 (PST) Received: from sol.firepipe.net (c-50-183-92-30.hsd1.co.comcast.net. [50.183.92.30]) by mx.google.com with ESMTPSA id e3sm5938994igg.16.2015.01.21.07.10.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 07:10:06 -0800 (PST) Date: Wed, 21 Jan 2015 08:10:04 -0700 From: Will Andrews To: Garrett Cooper Subject: Re: Head not buildin in zfs.c Message-ID: <20150121151002.GA38973@sol.firepipe.net> References: <54BF72A9.5000608@digiware.nl> <31627BCE-2B7A-44AA-9442-2D9347C1F571@gmail.com> <54BF79E1.3060401@digiware.nl> <54BF7CAB.4050008@digiware.nl> <5AD836D7-4223-4E2C-93F9-EA1C16215275@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <5AD836D7-4223-4E2C-93F9-EA1C16215275@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Benjamin Perrault , Willem Jan Withagen , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Jan 2015 15:10:08 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 21, 2015 at 02:47:57AM -0800, Garrett Cooper wrote: > On Jan 21, 2015, at 2:17, Willem Jan Withagen wrote: >=20 > =E2=80=A6 >=20 > > Right, picky nasty compilers being fussy. ;) > >=20 > > I did in look in the svn log of both .h files, but overlooked what you = just found..... Need more coffee. > >=20 > > I'll be waiting the the fix in the tree.. >=20 > Fixed in r277484 =E2=80=94 thanks! Thanks! Sorry for the noise. --Will. --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEUEARECAAYFAlS/wUoACgkQF47idPgWcsU/jACfXOEEat0ctr1aZYJkZu1c+Za8 XdwAmJKPbv17qNaJ+RJcpE+vwyQYBR8= =dD5V -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 21:47:07 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1C00AD1 for ; Wed, 21 Jan 2015 21:47:06 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D6D162AA for ; Wed, 21 Jan 2015 21:47:06 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t0LLl6BV000954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 21 Jan 2015 13:47:06 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t0LLl6G0000953 for freebsd-current@freebsd.org; Wed, 21 Jan 2015 13:47:06 -0800 (PST) (envelope-from sgk) Date: Wed, 21 Jan 2015 13:47:06 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: panic in pmap_remove_pages() Message-ID: <20150121214706.GA912@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Jan 2015 21:47:07 -0000 Just got this panic. If anyone is interested I have the kenrel and core, so can do some additional poking around. troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.0 Wed Jan 21 13:28:04 PST 2015 FreeBSD troutmask.apl.washington.edu 11.0-CURRENT FreeBSD 11.0-CURRENT #7 r276378M: Mon Dec 29 14:13:57 PST 2014 kargl@troutmask.apl.washington.edu:/data/obj/usr/src/sys/SPEW amd64 panic: general protection fault Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid = 3; apic id = 13 instruction pointer = 0x20:0xffffffff8079abf9 stack pointer = 0x28:0xfffffe047325e360 frame pointer = 0x28:0xfffffe047325e440 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 41779 (z) trap number = 9 panic: general protection fault cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe047325e020 panic() at panic+0x1c1/frame 0xfffffe047325e0e0 trap_fatal() at trap_fatal+0x396/frame 0xfffffe047325e140 trap() at trap+0x6ce/frame 0xfffffe047325e2a0 calltrap() at calltrap+0x8/frame 0xfffffe047325e2a0 --- trap 0x9, rip = 0xffffffff8079abf9, rsp = 0xfffffe047325e360, rbp = 0xfffffe047325e440 --- pmap_remove_pages() at pmap_remove_pages+0x539/frame 0xfffffe047325e440 exec_new_vmspace() at exec_new_vmspace+0x180/frame 0xfffffe047325e4a0 exec_elf64_imgact() at exec_elf64_imgact+0x6c0/frame 0xfffffe047325e570 kern_execve() at kern_execve+0x484/frame 0xfffffe047325e8c0 sys_execve() at sys_execve+0x35/frame 0xfffffe047325e920 amd64_syscall() at amd64_syscall+0x289/frame 0xfffffe047325ea30 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe047325ea30 --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x4251ba, rsp = 0x7ffffe8ebab8, rbp = 0x7ffffe8ec1c0 --- Uptime: 22d22h22m46s #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff80555bd7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff80556040 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0xffffffff807a2986 in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:867 #4 0xffffffff807a25de in trap (frame=) at /usr/src/sys/amd64/amd64/trap.c:201 #5 0xffffffff80787ca3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:235 #6 0xffffffff8079abf9 in pmap_remove_pages (pmap=0xfffff801c627dec8) at /usr/src/sys/amd64/amd64/pmap.c:5389 #7 0xffffffff8051fa00 in exec_new_vmspace (imgp=0xfffffe047325e6e0, sv=0xffffffff80b3e8e8) at /usr/src/sys/kern/kern_exec.c:1036 #8 0xffffffff804fed20 in exec_elf64_imgact (imgp=0xfffffe047325e6e0) at /usr/src/sys/kern/imgact_elf.c:830 #9 0xffffffff8051e4f4 in kern_execve (td=0xfffff8027588f490, args=0xfffffe047325e8d8, mac_p=0x1da) at /usr/src/sys/kern/kern_exec.c:486 #10 0xffffffff8051de15 in sys_execve (td=, uap=) at /usr/src/sys/kern/kern_exec.c:210 #11 0xffffffff807a3199 in amd64_syscall (td=0xfffff8027588f490, traced=0) at subr_syscall.c:133 #12 0xffffffff80787f8b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 #13 0x00000000004251ba in ?? () -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 21:58:07 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BF29E5C; Wed, 21 Jan 2015 21:58:07 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 488F03ED; Wed, 21 Jan 2015 21:58:05 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id t0LLF8JR030205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Jan 2015 08:15:13 +1100 (AEDT) (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.9/8.14.9) with ESMTP id t0LLF21G032529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Jan 2015 08:15:02 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id t0LLF0bn032528; Thu, 22 Jan 2015 08:15:00 +1100 (AEDT) (envelope-from peter) Date: Thu, 22 Jan 2015 08:15:00 +1100 From: Peter Jeremy To: Bryan Venteicher Subject: Re: [CFT] Paravirtualized KVM clock Message-ID: <20150121211500.GA32478@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD-current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Jan 2015 21:58:07 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2015-Jan-04 11:56:14 -0600, Bryan Venteicher wrote: >For the last few weeks, I've been working on adding support for KVM clock >in the projects/paravirt branch. Currently, a KVM VM guest will end up >selecting either the HPET or ACPI as the timecounter source. Unfortunately, >this is very costly since every timecounter fetch causes a VM exit. KVM >clock allows the guest to use the TSC instead; it is very similar to the >existing Xen timer. A somewhat late response but have you looked at https://github.com/blitz/freebsd/commit/cdc5f872b3e48cc0dda031fc7d6bdedc65c= 3148f I've been running this[*] on a Google Compute Engine instance for about 6 months without problems. [*] I had to patch out the test for KVM_FEATURE_CLOCKSOURCE_STABLE_BIT but I think that's a GCE issue. --=20 Peter Jeremy --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUwBbUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0EPcP/1rx8DK61b3Bz7Oiju0gbkXd OJrhFO/WVuJ6P7yRW3Feg17C2+FVMqnqPZ5XyaaQNBGnUuHuEYx4o5JM7OlrfeLW WVog+gr0Gg7th/lMPkFFy+WK7QlX/nDFLbRnkcOdiuqGIJZ4EDqYTwkmJxCWqNOv ynlq8BrKUMV2Ff2NeUFx8EnoqxYiuP48ExpLTlJcbHylRKFWkBPUOjKX97ljsO9o X1WPzGH3XmHzEVkEANlwTDqV/hYVwKxcLuyTVsmxn5K0L/XV/jn/qI7ukWfWk0VO WDFXkZUZ4WkrrP5O/5C/7j7GjvPOk0JYK9YnI7wzrh9x5BI86L5PH//1CqL/splo 9MeiS95Pm8LVqK0ggjNt+kYhail1DdCrufH8OdPcE9/rQVCEXKTsxPygz3sdW5AE ttQlikoh2rXFfyPbJlYxTTpoJx6lHhx/eBlhTVgMoX32bAYlR4h7laXJ1q2/Mb1w FtzjKRjHGso2iiFiP+NsomHWNhJRGKTT/gcQnJ33xCa6B6Asew+UpeCAVM4brGxg NWeAkL6nt3JsOBgEKiuNksp7HZituMYRpEai2fkKCcqPcHplutD8qSd93ALO8anY M0Iggid9bE/zfMDQltm6A/SdYFb0HrXEFCDzQffLbU3nwOGi+CSM2BnoV/1uZggn 9v+JtxMBJBKhL+W20HK2 =PgOy -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 01:06:47 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 533E3637 for ; Thu, 22 Jan 2015 01:06:47 +0000 (UTC) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD481B8E for ; Thu, 22 Jan 2015 01:06:46 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id s18so22529712lam.5 for ; Wed, 21 Jan 2015 17:06:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QLHUUh3vO4ncsxCsjMXuT6DjfPAQiJ0erU3SyayxbK0=; b=cqjQMCBMVwxjaD8QrouLYbkw6175M9pzukEtV4yD3WVOF6WwVsv9vRYTKBY0sWgVsY NyYCekqkraniK2Ys0zPIWpuLbD7MZEBO0KQNwACVGI1m+P70m+H0bcJdPp6qm20s4dlN TB6KTfz0+LiMWPDo9kaPQxWtn1BTtkFC1zZeCw9+h8VW+uUoynsPAzTvfqTXhP1HspSD lZg4Qli1nmNJMGttqW7H091K+PDmKV4lEk58RG4TcdMMMwmiCS8FhDh4BgvZM5bOCL1W fs1TlxNz/Wvu5Q4Br8j/++ox16f+IlvsEDW+AgE1c65IEnuV8H5EgMeYbm6JfyhldUBT zWRQ== X-Gm-Message-State: ALoCoQn3lottDpbXSRF/ybhmKX7hpugAjqMDVzTEaUH3qiojssKVU6ve33GpV93jVN9TtYF/0a0y X-Received: by 10.152.3.195 with SMTP id e3mr47529350lae.8.1421888804255; Wed, 21 Jan 2015 17:06:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.201.226 with HTTP; Wed, 21 Jan 2015 17:06:22 -0800 (PST) X-Originating-IP: [67.198.113.68] In-Reply-To: <20150121211500.GA32478@server.rulingia.com> References: <20150121211500.GA32478@server.rulingia.com> From: Bryan Venteicher Date: Wed, 21 Jan 2015 19:06:22 -0600 Message-ID: Subject: Re: [CFT] Paravirtualized KVM clock To: Peter Jeremy Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 01:06:47 -0000 On Wed, Jan 21, 2015 at 3:15 PM, Peter Jeremy wrote: > On 2015-Jan-04 11:56:14 -0600, Bryan Venteicher < > bryanv@daemoninthecloset.org> wrote: > >For the last few weeks, I've been working on adding support for KVM clock > >in the projects/paravirt branch. Currently, a KVM VM guest will end up > >selecting either the HPET or ACPI as the timecounter source. > Unfortunately, > >this is very costly since every timecounter fetch causes a VM exit. KVM > >clock allows the guest to use the TSC instead; it is very similar to the > >existing Xen timer. > > A somewhat late response but have you looked at > > https://github.com/blitz/freebsd/commit/cdc5f872b3e48cc0dda031fc7d6bdedc65c3148f > I've been running this[*] on a Google Compute Engine instance for about 6 > months without problems. > > A goal of my work was to put a bit of infrastructure in place so FreeBSD can support pvops across a variety of hypervisors. KVMCLOCK happens to be about the easiest to implement, and has a decent performance win for many situations. I think that commit is broken on SMP guests: CPU_FOREACH() does not switch the current CPU, so it just keeps writing to the MSR on the BSP. [*] I had to patch out the test for KVM_FEATURE_CLOCKSOURCE_STABLE_BIT but > I think that's a GCE issue. > > -- > Peter Jeremy > From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 04:32:37 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1A6BF65; Thu, 22 Jan 2015 04:32:37 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC8912DE; Thu, 22 Jan 2015 04:32:37 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id vy18so1197928iec.8; Wed, 21 Jan 2015 20:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=unY3O/N9ontjyTOQFqqXUo4+FiC/D3pVGCCWhvNHfzw=; b=0cHYyZSTXLgkqzFl9YIfQpqBjSnVX+9P4kqZVDtnsHZ4a9ICpuKGIHeJvT0ULJ+NXv Se5LZZ29DLTtIcj8woIb4D1NMFuhX7T+MITnwNLQN32iKA5EXYQtqwm3k43Nl2w5Rb3r hsAEbe5/zXb6oFTA/4gDpt5+44bw2wCUAQm+nR62+7XD2iNxBPFDLWRJ5rCHkD6FISQI qndXQHOkvK123u6HyxSCNAaJfydE0NtUiZBvTfqIgir+2t7qB4RLOqhb/mw8Tou8rwJ2 FT91OuE+m9nRw+1ki9Sg+LT7toOZGgojoRTkKNNsJyfNqKGfpKfT/dpLtebs9GCZDGmc 6SRA== MIME-Version: 1.0 X-Received: by 10.50.93.70 with SMTP id cs6mr9410469igb.6.1421901157131; Wed, 21 Jan 2015 20:32:37 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Wed, 21 Jan 2015 20:32:37 -0800 (PST) Date: Wed, 21 Jan 2015 20:32:37 -0800 X-Google-Sender-Auth: h6SSGYpcVE4HdO9XYtoSXpV5FnI Message-ID: Subject: logged errors with current drm stuff From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 04:32:38 -0000 Hi! I'm seeing this with your patch now: error: [drm:pid5:i915_gem_object_unbind] *ERROR* Attempting to unbind pinned buffer Nothing seems to be problematic at the moment; but it does seem to happen quite frequently. Any ideas? -adrian From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 10:15:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A955A65; Thu, 22 Jan 2015 10:15:53 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53332AEC; Thu, 22 Jan 2015 10:15:52 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 11AE91FE023; Thu, 22 Jan 2015 11:15:51 +0100 (CET) Message-ID: <54C0CE09.500@selasky.org> Date: Thu, 22 Jan 2015 11:16:41 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Slawa Olhovchenkov Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <54BADFB3.3030405@selasky.org> <54BE03EB.2070604@selasky.org> <20150120104736.GA78629@zxy.spb.ru> In-Reply-To: <20150120104736.GA78629@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Current , Jason Wolfe , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 10:15:53 -0000 On 01/20/15 11:47, Slawa Olhovchenkov wrote: > On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote: > >> On 01/17/15 23:18, Hans Petter Selasky wrote: >>> On 01/17/15 20:11, Jason Wolfe wrote: >>>> >>>> HPS, >>>> >>>> Just to give a quick status update, this patch has most certainly >>>> resolved our spin lock held too long panics on stable/10. >>>> >>>> Thank you to JHB for spending some time digging into the issue and >>>> leading us to td_slpcallout as the culprit, and HPS for your rewrite. >>>> I had heard rumors of other being affected by similar issues, so this >>>> seems like a fine candidate for an MFC if possible. >>>> >>>> Jason >>>> >>> >>> Hi Jason, >>> >>> I'm glad to hear that my patch has resolved your issue and I'm happy we >>> now have a more stable system. >>> >>> It was actually a co-worker at work which wrote some bad code which I >>> started debugging which then lead me to look at the callout subsystem. >>> One bug kills the other ;-) >>> >>> I'm planning a MFC to 10-stable - yes, and will possibly add the >>> _callout_stop_safe() function to not break binary compatibility with >>> existing drivers as part of the MFC. >>> >>> --HPS >> >> Hi, >> >> Here is a followup patch for the TCP stack like I mentioned in the >> beginning of the work done on the callout subsystem: >> >> https://reviews.freebsd.org/D1563 >> >> If someone has a setup for massive TCP testing please give it a spin. > > I have on 10.1 (with applied r261906). FYI: r277213 is going to be pulled out from -current in at maximum a few hours from now, because developers need more time to review patches in surrounding areas like the TCP stack area to restore distribution of callouts on multiple CPUs when using MPSAFE callouts to avoid congestion in the TCP stack. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 10:27:46 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA418D4A; Thu, 22 Jan 2015 10:27:46 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C27ABF8; Thu, 22 Jan 2015 10:27:46 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0MARe4r095047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 12:27:40 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0MARe4r095047 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0MARenC095046; Thu, 22 Jan 2015 12:27:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 Jan 2015 12:27:40 +0200 From: Konstantin Belousov To: Hans Petter Selasky Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress Message-ID: <20150122102740.GZ42409@kib.kiev.ua> References: <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <54BADFB3.3030405@selasky.org> <54BE03EB.2070604@selasky.org> <20150120104736.GA78629@zxy.spb.ru> <54C0CE09.500@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54C0CE09.500@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 10:27:46 -0000 On Thu, Jan 22, 2015 at 11:16:41AM +0100, Hans Petter Selasky wrote: > On 01/20/15 11:47, Slawa Olhovchenkov wrote: > > On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote: > > > >> On 01/17/15 23:18, Hans Petter Selasky wrote: > >>> On 01/17/15 20:11, Jason Wolfe wrote: > >>>> > >>>> HPS, > >>>> > >>>> Just to give a quick status update, this patch has most certainly > >>>> resolved our spin lock held too long panics on stable/10. > >>>> > >>>> Thank you to JHB for spending some time digging into the issue and > >>>> leading us to td_slpcallout as the culprit, and HPS for your rewrite. > >>>> I had heard rumors of other being affected by similar issues, so this > >>>> seems like a fine candidate for an MFC if possible. > >>>> > >>>> Jason > >>>> > >>> > >>> Hi Jason, > >>> > >>> I'm glad to hear that my patch has resolved your issue and I'm happy we > >>> now have a more stable system. > >>> > >>> It was actually a co-worker at work which wrote some bad code which I > >>> started debugging which then lead me to look at the callout subsystem. > >>> One bug kills the other ;-) > >>> > >>> I'm planning a MFC to 10-stable - yes, and will possibly add the > >>> _callout_stop_safe() function to not break binary compatibility with > >>> existing drivers as part of the MFC. > >>> > >>> --HPS > >> > >> Hi, > >> > >> Here is a followup patch for the TCP stack like I mentioned in the > >> beginning of the work done on the callout subsystem: > >> > >> https://reviews.freebsd.org/D1563 > >> > >> If someone has a setup for massive TCP testing please give it a spin. > > > > I have on 10.1 (with applied r261906). > > FYI: > > r277213 is going to be pulled out from -current in at maximum a few > hours from now, because developers need more time to review patches in > surrounding areas like the TCP stack area to restore distribution of > callouts on multiple CPUs when using MPSAFE callouts to avoid congestion > in the TCP stack. No, r277213 was requested to be reverted not due to TCP issues. The main complain is that you left indefinite amount of cases degraded, and there is no analysis of each such case, nor even a list of the cases that need to be fixed (or argumentation why consumer of the callout KPI could be left as is). Just providing fix for one place is not enough. From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 11:02:07 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43F4F819 for ; Thu, 22 Jan 2015 11:02:07 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9F1FFCC for ; Thu, 22 Jan 2015 11:02:06 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id y19so998066wgg.11 for ; Thu, 22 Jan 2015 03:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to :mime-version:content-type:content-disposition:user-agent; bh=qyJ+dCWNJOX/am9vI6Ou0/DoylniuEL31AaieIlJVeg=; b=LxT41TfmH4jAN0t758wI9/5RMKhfVzhWSe//qz28j0YvbDVMfKNyRCMCwQgt5Ql5iK 0BtSGATnU2liwHh/Oixa5EM8A7WruuFdIqRt1Nyq8julhuEmQqdKH4cslj9r5OdxJEeT 8uZK+mgO8CAK88AQyFp3D8e+4vwsTtm2rNYbzPjOrsfxHKL625oOl69WKnSRifQrqShX +EgLfum/BkaIyPSJpuZxRI4YePCk9uAP6gXrWfFKjwcPxCJNnSkNxjHifSD8Rg2PbXcM 4RK69MZuNld9jRpVj6VwxNrz8u6muJb/DhkUT48EhtTJe/+RpTZkCoB8+7T+dryPTj52 PQZw== X-Received: by 10.194.190.39 with SMTP id gn7mr1968828wjc.30.1421924525221; Thu, 22 Jan 2015 03:02:05 -0800 (PST) Received: from brick.home (abpi241.neoplus.adsl.tpnet.pl. [83.8.50.241]) by mx.google.com with ESMTPSA id h13sm2559986wiw.4.2015.01.22.03.02.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jan 2015 03:02:04 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 22 Jan 2015 12:02:01 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: current@FreeBSD.org Subject: Suspend/resume with i915. Message-ID: <20150122110201.GA3996@brick.home> Mail-Followup-To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 11:02:07 -0000 I'm trying to fix resume on my T61, broken by some change several months ago; according to pciconf it's 'Mobile GM965/GL960 Integrated Graphics Controller (primary)'. It's running current CURRENT and up to date packages. Suspend and resume makes Xorg do something weird - there is screen corruption, or rather window corruption. The GNOME 3 desktop looks pretty normal, except that gnome-terminal (launched before suspend) window looks as if the buffer layout changed underneath it; for example, instead of one flashing cursor there are several, horizontally, across the window. New windows are simply black. No segv. Setting kern.vt.suspendswitch=0 makes the behaviour disappear, replaced by segmentation faults of gnome-shell. With stock gdb it looks like this: #0 0x000000081518d7b3 in __driDriverGetExtensions_i965 () from /usr/local/lib/dri/i965_dri.so #1 0x00000008151353ef in __driDriverGetExtensions_i965 () from /usr/local/lib/dri/i965_dri.so #2 0x0000000804dfe70c in cogl_framebuffer_clear4f () from /usr/local/lib/libcogl.so.20 With gdb from ports and graphics/dri port rebuilt with debug flags, using 'make CFLAGS="-O0 -ggdb" WITH_DEBUG=yes STRIP= clean all deinstall reinstall', it makes more sense: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 804806400 (LWP 100123)] 0x0000000805bb490b in get_stencil_miptree (irb=0x80483fe80) at brw_misc_state.c:225 225 if (irb->mt->stencil_mt) (gdb) where #0 0x0000000805bb490b in get_stencil_miptree (irb=0x80483fe80) at brw_misc_state.c:225 #1 0x0000000805bb3cbd in brw_workaround_depthstencil_alignment ( brw=0x804907028, clear_mask=18) at brw_misc_state.c:241 #2 0x0000000805b3355e in brw_clear (ctx=0x804907028, mask=18) at brw_clear.c:235 #3 0x000000080568309e in _mesa_Clear (mask=16640) at ../../src/mesa/main/clear.c:225 There are several suggested fixes for this, like those: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/media-libs/mesa/files/10.3-dri-i965-Return-NULL-if-we-don-t-have-a-miptree.patch https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-checkins/5HAd07ICk94 They don't seem to work, though, and the Mesa codebase doesn't exactly look promising. Now, what I've noticed is that if I switch to VT0 (ctrl-alt-f1) and then suspend, the resume works flawlessly, and after switching to Xorg it runs without any problems either. This got me thinking... Adding this: /usr/sbin/vidcontrol -s 1 < /dev/ttyv0 to /etc/rc.suspend, with kern.vt.suspendswitch=0, prevents suspend with Xorg from breaking things, with a drawback that one has to manually switch back to Xorg after resume. So, questions: 1. Are there any patches that could actually fix suspend/resume with Xorg, instead of working around it? 2. Does the rc.suspend workaround seem like a proper one? My theory is that it works better than kern.vt.suspendswitch=1 because it gives Xserver a chance to properly release VT, or "deinitialize stuff". Does it make sense? If so, I could add "vidcontrol -w" to return number of current console, and use it, together with "vidcontrol -s", in rc.suspend and rc.resume scripts, if kern.vty.suspendswitch is enabled. That would provide a properly working workaround without need for any manual configuration. 3. This is a weird one - the workaround works when closing a lid, and when doing "acpiconf -s3" in gnome-terminal window, but does not work when suspend was initiated by Fn-F4. Any ideas? All feedback is welcome. From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 15:21:56 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFF90BA2 for ; Thu, 22 Jan 2015 15:21:56 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56669332 for ; Thu, 22 Jan 2015 15:21:56 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id hs14so2188913lab.8 for ; Thu, 22 Jan 2015 07:21:54 -0800 (PST) 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=TFvxHss4LW2BRToaDvp9N+f8XB9GWlOom+ML4GW6d68=; b=MqualdyRWlQTPUegjyYApvIvlUALEcjaCb3pdRf/QjHYURuyrawF9AgL25JbUVQStp +opOrc1PCLZemSO4GRnawESRTD6eH7hgmjK3fnRUZUYrmiF0luUn63mIJMpGhZdzKq3W 59UgvDtsHCQeQUfiPOh8coKZp61YiZnFKQpD0NPjL+1fSxpS56ATUB01FpOtSA/3b8p9 q+OwsemRYPRUCP7+nuB3vs59VAmvO+1KmrOPQLgQ52cOM/Bxi3CCRu5j1VOBRnKOHCxP RWeJY6xcDjx/Irn0P0Manhe8P6g24QfMHYTVSRhOnjUrkO91jgYvqyR4sNrAPFUX5lFd qGaQ== X-Received: by 10.112.133.4 with SMTP id oy4mr2185451lbb.83.1421940114222; Thu, 22 Jan 2015 07:21:54 -0800 (PST) Received: from edge ([91.123.18.167]) by mx.google.com with ESMTPSA id vu9sm5809321lbb.36.2015.01.22.07.21.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Jan 2015 07:21:53 -0800 (PST) Received: from misha (uid 1001) (envelope-from misha@edge) id 8929c3 by edge (DragonFly Mail Agent capsicum_v0.1 (capability sandbox enabled)); Thu, 22 Jan 2015 15:21:52 +0000 Date: Thu, 22 Jan 2015 18:21:52 +0300 From: Mikhail To: Konstantin Belousov Subject: Re: logged errors with current drm stuff Message-ID: <20150122152152.GA857@edge> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 15:21:56 -0000 On 07:32 22-Jan 2015 Adrian Chadd wrote: > Hi! > > I'm seeing this with your patch now: > > error: [drm:pid5:i915_gem_object_unbind] *ERROR* Attempting to unbind > pinned buffer > > Nothing seems to be problematic at the moment; but it does seem to > happen quite frequently. > > Any ideas? To add on this, with latest DRM I've lost ability to change my backlight on Lenovo E530. >From /var/log/messages: error: [drm:pid790:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 16000000, was 12000000 error: [drm:pid790:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 16070000, was 16000000 error: [drm:pid790:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 00070000, was 16070000 From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 15:30:40 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8E7EF32; Thu, 22 Jan 2015 15:30:40 +0000 (UTC) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DAF33CF; Thu, 22 Jan 2015 15:30:40 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id v63so1821880oia.7; Thu, 22 Jan 2015 07:30:39 -0800 (PST) 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=EHjAFRLeb/i4QVwsGHtbxZJNqWYBi27rKF0ELHuIXjE=; b=tXVwPaDtQG73z9RoLSDld/QCsrHUZRpKjzRn1OGtQRQ0tLB4/gooAKcm4PQPuJ1BZq ysk/JXwHvSqSdsNDLEkxAPWYPpItOgLvmKGqsSBOM82/goNR07YoHWVj0ZMxWcf/BWrc I/6zT9Q3OQ4dHIJxO2PS9EQX8Z3zw3NneRvl9WMgSYAy8Lijh3j2vcssGYyLfYX1++xL SIURqknLsu+2+aah6QtN2dwm56sYb/Ao5wsyltioj+sdWt4ke9SQ2B6g/dTpVrEs6c1w TzXA6h4h7i9dkuRgiXF1Z4fXkGEm4jqRBSBGvzNkpNR+aiAxhoVr7CqUQ0YB3GukryJh vzCA== MIME-Version: 1.0 X-Received: by 10.202.53.139 with SMTP id c133mr1135894oia.109.1421940639890; Thu, 22 Jan 2015 07:30:39 -0800 (PST) Received: by 10.202.105.7 with HTTP; Thu, 22 Jan 2015 07:30:39 -0800 (PST) In-Reply-To: <20150122152152.GA857@edge> References: <20150122152152.GA857@edge> Date: Thu, 22 Jan 2015 16:30:39 +0100 Message-ID: Subject: Re: logged errors with current drm stuff From: Johannes Dieterich To: Mikhail Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , freebsd-current , Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 15:30:40 -0000 Hi, On Thu, Jan 22, 2015 at 4:21 PM, Mikhail wrote: > On 07:32 22-Jan 2015 Adrian Chadd wrote: >> Hi! >> >> I'm seeing this with your patch now: >> >> error: [drm:pid5:i915_gem_object_unbind] *ERROR* Attempting to unbind >> pinned buffer >> >> Nothing seems to be problematic at the moment; but it does seem to >> happen quite frequently. >> >> Any ideas? > > To add on this, with latest DRM I've lost ability to change my backlight > on Lenovo E530. > > From /var/log/messages: > > error: [drm:pid790:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 16000000, was 12000000 > error: [drm:pid790:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 16070000, was 16000000 > error: [drm:pid790:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 00070000, was 16070000 That one has been in the patch since October for me (see: http://permalink.gmane.org/gmane.os.freebsd.current/161187 ) on a i5-3320M. I however could not observe any impact of the error for my usage beyond the flooded messages. I am not sure if it has to do with the backlight changes you triggered as I certainly didn't change mine and still got them. Johannes From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 16:57:34 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D039965B for ; Thu, 22 Jan 2015 16:57:34 +0000 (UTC) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A65B6FBF for ; Thu, 22 Jan 2015 16:57:34 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id rd3so1918863pab.3 for ; Thu, 22 Jan 2015 08:57:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type :content-transfer-encoding:subject:message-id:date:to:mime-version; bh=qJ9xLYNZ0Nd4PCaV7vN7O6AZg0WFezBtMsfsh+qHPsw=; b=mSmTgWpVGyYvKeY+Korjt/Enm+XzSiMxxNOOZyomg0go0sieOP24d9TFn7UpVecEuU skbxmsSpOONY/MOd45qNUbcguhqi3xE+736bs6SKERZ0JsyQEcA8Thi49XV0NB4hfgxc 4SDPahCQ+6IbhVV3ufx2mioLjhhqkoXSDbdFNKZNI3eh5XG0u34p4xPP3cc5WMDeLRja y5dsowX3SmyTjoh3SlrIfWDks95VcL4e98ZiSYWftgSUgXShYNv1ohxiG4vU5nczWMrb oyY0K/SW2OE6iTV3qKUbipVaBFiqOit59Fccui5kRNsCJ2Ie4sPDuWsitc2xWMg1Y9Pj Pd9Q== X-Gm-Message-State: ALoCoQkFOBO8Jhybe7GFdZK1jcIlzGTMiumJ9SfdjqBh5pUwU19VBEOGoNm1cLKDIQS5r5t/thyN X-Received: by 10.70.123.166 with SMTP id mb6mr3609394pdb.95.1421945847907; Thu, 22 Jan 2015 08:57:27 -0800 (PST) Received: from bsdimp.corp.netflix.com ([69.53.237.72]) by mx.google.com with ESMTPSA id rn15sm9804495pab.10.2015.01.22.08.57.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Jan 2015 08:57:27 -0800 (PST) Sender: Warner Losh From: Warner Losh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: If you use MCA devices, please let me know Message-Id: <2659453B-8F3B-496C-828C-19A59AC93806@bsdimp.com> Date: Thu, 22 Jan 2015 09:57:26 -0700 To: FreeBSD Stable , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 16:57:34 -0000 Greetings, I=E2=80=99m wondering if there are any people out there using MCA = machines under FreeBSD. If so, please let me know. It would be great to know the model and FreeBSD = version. Thanks! Warner From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 21:07:56 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55728AE3 for ; Thu, 22 Jan 2015 21:07:56 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0F705E8 for ; Thu, 22 Jan 2015 21:07:55 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id n3so24504594wiv.1 for ; Thu, 22 Jan 2015 13:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fDD4HtAJGl210QW8p47SU5/lwUCbCUm/x5lkGYPnnaY=; b=uLU6FGAuOuPfKdqzfsdqLf/e2MFxvUGZEgYZin1XBGntCuJTb8LdIePbDgYb74+Zl6 N4tINdULF2HU04vpe6UjiDlauijlFx6ucs1Q3tMI4o9mqu7OhO6c9N49WqPOu+4zr0TT GUg+UMvOqc3p8EeDKERzCACvoc7ghQHI/4Mnh384CvY8bs1U3K4vtpFyqnqRKRj4Fe7t sg7w5kMophndIxjfvfl91mtFnpWoXvb3VDITbMGCt9S2HiL4M41GeuHGbh8lUesR2hqk Z7Fd50s44G9SWE/4FMzLL5bRNgvuVpWnyUNQQ/MUnFJZ/KkB9q014d2eHPzjR7pbhKe4 mNqg== MIME-Version: 1.0 X-Received: by 10.180.12.75 with SMTP id w11mr9146365wib.9.1421960873949; Thu, 22 Jan 2015 13:07:53 -0800 (PST) Received: by 10.217.64.10 with HTTP; Thu, 22 Jan 2015 13:07:53 -0800 (PST) Date: Thu, 22 Jan 2015 22:07:53 +0100 Message-ID: Subject: i915 backlight control broken From: "Ranjan1018 ." <214748mv@gmail.com> To: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 21:07:56 -0000 Just upgraded my laptop from r277395 to r277534. The backlight control via hw.acpi.video.lcd0.brightness do not works: the backlight is always at 100%. Maurizio From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 21:22:36 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61B591B3 for ; Thu, 22 Jan 2015 21:22:36 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E54A681B for ; Thu, 22 Jan 2015 21:22:35 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id bs8so42948377wib.0 for ; Thu, 22 Jan 2015 13:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QyBSoNB+8dS7C675jmYk5KadYoemabixrNecyjPOVvk=; b=tEqJYQ9pn2QTTIcy/jTSFktp+A0qHAJ8v/KM1a3eqH0Ixf4abLfSmerw/IgYue/wa2 20DMevcDiRYT9+xS7OHSLKlLJiKOITF0Rhy6MG50TJ+j3JdyRADYhN28IFvq7dYcVrRg LR9jipwbzrMGWDhuKlsXPR04F6tS+AwH5GmQm969sUN0TncBA6PR1sRaIRSCnACSBebV m+YPvsEv9PkHfR4MUCc5VJor2R5BVptGj1wim2fgH0Vt4HKLUFasznTjqOMFjCPstwQt tiafxN5jNjJqjnGHAbMPQVodSxm6yOgR9KSOTGyUoBv5XfDwHhUeMhnwf/B9+Fns+NYo aedA== X-Received: by 10.180.85.33 with SMTP id e1mr18111326wiz.55.1421961754475; Thu, 22 Jan 2015 13:22:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.16.98 with HTTP; Thu, 22 Jan 2015 13:22:14 -0800 (PST) In-Reply-To: References: From: Miguel Clara Date: Thu, 22 Jan 2015 21:22:14 +0000 Message-ID: Subject: Re: i915 backlight control broken To: "Ranjan1018 ." <214748mv@gmail.com> Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 21:22:36 -0000 Was it working before? For me it never did on 10 or 11 I don't see the sysctl and xbacklight reports: "No outputs have backlight property". I have the same issue in a HP and an Accer never could make it work. Melhores Cumprimentos // Best Regards ----------------------------------------------- *Miguel Clara* *IT - Sys Admin & Developer* *E-mail: *miguelmclara@gmail.com www.linkedin.com/in/miguelmclara/ On Thu, Jan 22, 2015 at 9:07 PM, Ranjan1018 . <214748mv@gmail.com> wrote: > Just upgraded my laptop from r277395 to r277534. The backlight control via > hw.acpi.video.lcd0.brightness do not works: the backlight is always at > 100%. > > Maurizio > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 21:40:11 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A2C240F for ; Thu, 22 Jan 2015 21:40:11 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4B6594D for ; Thu, 22 Jan 2015 21:40:10 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id q107so3430777qgd.1 for ; Thu, 22 Jan 2015 13:40:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Nk+/Nj4qDlNY3+dcoGTJyzk0b6/kxKRaXPWQJo5eVI0=; b=J7tTLJbEXJs3ZsIrlH/WMCCLKPTYWHnnG8LpSPT7Kzjs4awEqEQ/RSXwbVH8NE+/uf D+goE6mPBl+hagJ2pNKCHvK5KBT6Qra6sGPmOLERMAwKWLDGTCobgpc5Ql99cTrktTDw 5l2zabMdcijBbFZP5R86CjpezKAa/2jLj9JEvXQZvpTHCfXbxZ85ZMLMcrF0LU/vVPJb Czl/UOpH4B+jtum/8qCWOnMXlql9FVbqw6VHqT4jc8bJjObTAzZnhBFzsvGlQJpXFxCU rJEaBrrgShmbGgmFRxD/jiSc1x2dgWN/JTRBjhh18mtmaT+dhmyeY/XNo6vNEGuBpppq jn2g== X-Received: by 10.224.73.135 with SMTP id q7mr7242689qaj.6.1421962808401; Thu, 22 Jan 2015 13:40:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.22.49 with HTTP; Thu, 22 Jan 2015 13:39:28 -0800 (PST) In-Reply-To: References: From: Henry Hu Date: Thu, 22 Jan 2015 16:39:28 -0500 Message-ID: Subject: Re: i915 backlight control broken To: Miguel Clara Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Ranjan1018 ." <214748mv@gmail.com>, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 21:40:11 -0000 On Thu, Jan 22, 2015 at 4:22 PM, Miguel Clara wrote: > Was it working before? > > For me it never did on 10 or 11 > > I don't see the sysctl and xbacklight reports: "No outputs have backlight > property". > If you don't see the sysctl, do you have kernel module acpi_video loaded? xbacklight is always broken.... > > I have the same issue in a HP and an Accer never could make it work. > > > > > Melhores Cumprimentos // Best Regards > ----------------------------------------------- > *Miguel Clara* > *IT - Sys Admin & Developer* > *E-mail: *miguelmclara@gmail.com > www.linkedin.com/in/miguelmclara/ > > On Thu, Jan 22, 2015 at 9:07 PM, Ranjan1018 . <214748mv@gmail.com> wrote: > > > Just upgraded my laptop from r277395 to r277534. The backlight control > via > > hw.acpi.video.lcd0.brightness do not works: the backlight is always at > > 100%. > > > > Maurizio > > _______________________________________________ > > 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" > -- Cheers, Henry From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 21:43:50 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DD6E68A for ; Thu, 22 Jan 2015 21:43:50 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C59DFA11 for ; Thu, 22 Jan 2015 21:43:49 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id r20so45062486wiv.0 for ; Thu, 22 Jan 2015 13:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SbuHvdK5s+6CsfypJugBF0ITU/VltQcqfwhYtEZyYHc=; b=ggDWw7LAOzD2//ZSUIOvx04ZhIOUHdR66XiF2TXeEb+2EHS9hErIYIcDlu8NYyJHAo g4o+9FUzSAGGGcYPpnKKlqMR5xXMSUoL+mgEgfmbm9r+K9li9LfZYMuw183UG0ueYlW8 HtyOe7VwkR7q9yqksq5SGT9vQuTsdcBNzbTjf2NHmbj79JqllqpuVEWFOmpn5vUcR++6 FkdK0T3qLZKjxBzLW3xVwTXESUAkfESXfVCH77zyNHUpHF1G1xs4lfVWWPPLViTy3nRz 54IPT+yhdE7jltQDnBBGh7kv07AhArGaGNreNg8TRqG/CPSeiWFOrktOHOAhbTJm1+Hm 9SCA== X-Received: by 10.180.8.35 with SMTP id o3mr6896290wia.60.1421963028254; Thu, 22 Jan 2015 13:43:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.16.98 with HTTP; Thu, 22 Jan 2015 13:43:27 -0800 (PST) In-Reply-To: References: From: Miguel Clara Date: Thu, 22 Jan 2015 21:43:27 +0000 Message-ID: Subject: Re: i915 backlight control broken To: Henry Hu Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Ranjan1018 ." <214748mv@gmail.com>, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 21:43:50 -0000 On Thu, Jan 22, 2015 at 9:39 PM, Henry Hu wrote: > > > On Thu, Jan 22, 2015 at 4:22 PM, Miguel Clara > wrote: > >> Was it working before? >> >> For me it never did on 10 or 11 >> >> I don't see the sysctl and xbacklight reports: "No outputs have backlight >> property". >> > > If you don't see the sysctl, do you have kernel module acpi_video loaded? > > xbacklight is always broken.... > I do, In the HP case I have acpi_video and acpi_hp, in the acer just acpi_video. > >> I have the same issue in a HP and an Accer never could make it work. >> >> >> >> >> Melhores Cumprimentos // Best Regards >> ----------------------------------------------- >> *Miguel Clara* >> *IT - Sys Admin & Developer* >> *E-mail: *miguelmclara@gmail.com >> www.linkedin.com/in/miguelmclara/ >> >> On Thu, Jan 22, 2015 at 9:07 PM, Ranjan1018 . <214748mv@gmail.com> wrote: >> >> > Just upgraded my laptop from r277395 to r277534. The backlight control >> via >> > hw.acpi.video.lcd0.brightness do not works: the backlight is always at >> > 100%. >> > >> > Maurizio >> > _______________________________________________ >> > 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 >> " >> > > > > -- > Cheers, > Henry > From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 22:41:28 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD6CC626 for ; Thu, 22 Jan 2015 22:41:28 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98E39F37 for ; Thu, 22 Jan 2015 22:41:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id t0MMfRcD055618 for ; Thu, 22 Jan 2015 22:41:27 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id t0MMfRF2055616 for freebsd-current@freebsd.org; Thu, 22 Jan 2015 22:41:27 GMT (envelope-from bdrewery) Received: (qmail 25414 invoked from network); 22 Jan 2015 16:41:26 -0600 Received: from unknown (HELO ?10.10.1.139?) (freebsd@shatow.net@10.10.1.139) by sweb.xzibition.com with ESMTPA; 22 Jan 2015 16:41:26 -0600 Message-ID: <54C17CA5.9060703@FreeBSD.org> Date: Thu, 22 Jan 2015 16:41:41 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Konstantin Belousov , Hans Petter Selasky Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <54BADFB3.3030405@selasky.org> <54BE03EB.2070604@selasky.org> <20150120104736.GA78629@zxy.spb.ru> <54C0CE09.500@selasky.org> <20150122102740.GZ42409@kib.kiev.ua> In-Reply-To: <20150122102740.GZ42409@kib.kiev.ua> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V8R6iQUN5gKR6jDkMvLB0xg2tvPakJXN1" Cc: FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 22:41:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V8R6iQUN5gKR6jDkMvLB0xg2tvPakJXN1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/22/2015 4:27 AM, Konstantin Belousov wrote: > On Thu, Jan 22, 2015 at 11:16:41AM +0100, Hans Petter Selasky wrote: >> On 01/20/15 11:47, Slawa Olhovchenkov wrote: >>> On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote: >>> >>>> On 01/17/15 23:18, Hans Petter Selasky wrote: >>>>> On 01/17/15 20:11, Jason Wolfe wrote: >>>>>> >>>>>> HPS, >>>>>> >>>>>> Just to give a quick status update, this patch has most certainly >>>>>> resolved our spin lock held too long panics on stable/10. >>>>>> >>>>>> Thank you to JHB for spending some time digging into the issue and= >>>>>> leading us to td_slpcallout as the culprit, and HPS for your rewri= te. >>>>>> I had heard rumors of other being affected by similar issues, so t= his >>>>>> seems like a fine candidate for an MFC if possible. >>>>>> >>>>>> Jason >>>>>> >>>>> >>>>> Hi Jason, >>>>> >>>>> I'm glad to hear that my patch has resolved your issue and I'm happ= y we >>>>> now have a more stable system. >>>>> >>>>> It was actually a co-worker at work which wrote some bad code which= I >>>>> started debugging which then lead me to look at the callout subsyst= em. >>>>> One bug kills the other ;-) >>>>> >>>>> I'm planning a MFC to 10-stable - yes, and will possibly add the >>>>> _callout_stop_safe() function to not break binary compatibility wit= h >>>>> existing drivers as part of the MFC. >>>>> >>>>> --HPS >>>> >>>> Hi, >>>> >>>> Here is a followup patch for the TCP stack like I mentioned in the >>>> beginning of the work done on the callout subsystem: >>>> >>>> https://reviews.freebsd.org/D1563 >>>> >>>> If someone has a setup for massive TCP testing please give it a spin= =2E >>> >>> I have on 10.1 (with applied r261906). >> >> FYI: >> >> r277213 is going to be pulled out from -current in at maximum a few=20 >> hours from now, because developers need more time to review patches in= =20 >> surrounding areas like the TCP stack area to restore distribution of=20 >> callouts on multiple CPUs when using MPSAFE callouts to avoid congesti= on=20 >> in the TCP stack. >=20 > No, r277213 was requested to be reverted not due to TCP issues. >=20 > The main complain is that you left indefinite amount of cases degraded,= > and there is no analysis of each such case, nor even a list of the case= s > that need to be fixed (or argumentation why consumer of the callout KPI= > could be left as is). >=20 > Just providing fix for one place is not enough. I have a similar concern about out-of-tree work. It would be surprising for a vendor or module developer to find their performance degrade if they missed accounting for this change. At a minimum, an UPDATING entry should be added explaining the change and what must be done for consumers= =2E --=20 Regards, Bryan Drewery --V8R6iQUN5gKR6jDkMvLB0xg2tvPakJXN1 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 iQEcBAEBAgAGBQJUwXylAAoJEDXXcbtuRpfP7dkIAM2nPjOqScYn2BhbXYckptZz fjScHRVBYGP03MCP1GGM6Jncr9uQrrzoOdp+8Bmn1ezquSdl5i7sLmVedVpuFKtP PzICFgl0pPkVie1ixByCqJ4ADiADmSU5sxOaDFOvQXtRaPEviHUnrhBaTWItHdEP ZUA8cHvzBgT2MXCmTCdFPnFJfxn3Ap+yvzL6lrgLuq+fVJNc23jTtRg12ipVzgGs LorIxFz/PUmrQ1tl8rb8ODk8rbeFQXiPCTMXHrFB0E6EGzrKQo6vRSLWAg7X2wQT xh+CReBtmRSNrP7C28ShBg5RmQVYzpurPFX+FWEMuqfGVbAiJzYRQozp1vSn0lI= =sTj3 -----END PGP SIGNATURE----- --V8R6iQUN5gKR6jDkMvLB0xg2tvPakJXN1-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 22:50:31 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 126C09DF; Thu, 22 Jan 2015 22:50:31 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id E0E39A0; Thu, 22 Jan 2015 22:50:30 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 22 Jan 2015 14:53:31 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id t0MMoLFf017112; Thu, 22 Jan 2015 14:50:21 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id t0MMoKkH017111; Thu, 22 Jan 2015 14:50:20 -0800 (PST) (envelope-from ambrisko) Date: Thu, 22 Jan 2015 14:50:20 -0800 From: Doug Ambrisko To: Willem Jan Withagen Subject: Re: old bug: mount_nfs path/name is limited to 88 chars Message-ID: <20150122225020.GA13161@ambrisko.com> References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> <54BDA9DD.5040608@delphij.net> <54BE3FDC.9030904@digiware.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BE3FDC.9030904@digiware.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd current , freebsd-stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Jan 2015 22:50:31 -0000 On Tue, Jan 20, 2015 at 12:45:32PM +0100, Willem Jan Withagen wrote: | On 2015-01-20 2:05, Xin Li wrote: | >>Doing it in 11 makes sense since there is a compat layer for 10 | >>now? if I knew all of the steps I would happily do them as annoys | >>me from time to time as well with the path length issue. | > | >Compat layer may break applications in other funny ways and we | >probably have to return e.g. ENAMETOOLONG for legacy applications if | >the names are too long to fit into the buffer, but I don't see any | >easy solution either: I wish we have bumped it in 2003 when the struct | >receives its first big revamp by bumping all statistic fields to 64-bit. | | On 2015-01-20 1:23, Allan Jude wrote:> On 2015-01-19 16:20, Garrett > | > Especially with ZFS, I find I have a lot more mounts now, under longer | > and longer path names, and then I have | > .zfs/snapshots/snapshotnamehere/path/to/file | > | > etc. | > | > Definitely a +1 for "this is something we need for 11" | | +1 | | Well to be honest: Things are already broken for me ATM. | I do have paths that are too long, and tools trip over it. | | Things like building the locate database just don't have everything. | Which is a pain, especially for finding things fast in backups of ZFS, | where the path is even more convoluted that what Allan suggests | | So whether being bitten by the cat of the dog: it still hurts. | | Perhaps it is an intermediate solution to add new settings which are | going to be used for userspace programs, like USER_MNAMELEN and | USER_PATH_MAX. It will certainly give ENAMETOOLONG back when it involves | systemcalls. But then a lot of the other tool stuff would just function. I have a patch at: http://www.ambrisko.com/doug/mount/latest.patch for -current (Nov). It should work with most file systems, that is I tried to cover them all. I haven't tested with ZFS but it should work. I left some debug "HELLO's" in there just to make sure mounting looked right. They can be safely deleted. If someone wants to test it and report issues (with a simple test case) I can fix it and add it to my test script. This code won't be going into FreeBSD now since the 64 bit inode will negate the need for it since the size will be a lot larger. Thanks, Doug A. From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 08:41:03 2015 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 361183C1 for ; Fri, 23 Jan 2015 08:41:03 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C185108 for ; Fri, 23 Jan 2015 08:41:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0N8ev9m093048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jan 2015 10:40:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0N8ev9m093048 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0N8evsF093047 for current@FreeBSD.org; Fri, 23 Jan 2015 10:40:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 Jan 2015 10:40:57 +0200 From: Konstantin Belousov To: current@FreeBSD.org Subject: Re: Suspend/resume with i915. Message-ID: <20150123084057.GD42409@kib.kiev.ua> References: <20150122110201.GA3996@brick.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150122110201.GA3996@brick.home> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Jan 2015 08:41:03 -0000 On Thu, Jan 22, 2015 at 12:02:01PM +0100, Edward Tomasz Napiera??a wrote: > I'm trying to fix resume on my T61, broken by some change several > months ago; according to pciconf it's 'Mobile GM965/GL960 Integrated > Graphics Controller (primary)'. It's running current CURRENT and > up to date packages. > > Suspend and resume makes Xorg do something weird - there is screen > corruption, or rather window corruption. The GNOME 3 desktop looks > pretty normal, except that gnome-terminal (launched before suspend) > window looks as if the buffer layout changed underneath it; for example, > instead of one flashing cursor there are several, horizontally, across > the window. New windows are simply black. No segv. > > Setting kern.vt.suspendswitch=0 makes the behaviour disappear, replaced > by segmentation faults of gnome-shell. With stock gdb it looks like this: At least one big known issue with suspend is that userspace activity is not stopped, which makes the driver suspend code operating on the non-steady state of devices. I committed the facility to stop userspace before suspend, and avg promised to integrate this into suspend path, but he did not. You might try to search mailing lists for reference to his earlier patch. From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 10:51:08 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99A9DB9B for ; Fri, 23 Jan 2015 10:51:08 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21CD8114 for ; Fri, 23 Jan 2015 10:51:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0NAp2os022202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 12:51:02 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0NAp2os022202 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0NAp0P7022199; Fri, 23 Jan 2015 12:51:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 Jan 2015 12:51:00 +0200 From: Konstantin Belousov To: Steve Kargl Subject: Re: panic in pmap_remove_pages() Message-ID: <20150123105100.GH42409@kib.kiev.ua> References: <20150121214706.GA912@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150121214706.GA912@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Jan 2015 10:51:08 -0000 On Wed, Jan 21, 2015 at 01:47:06PM -0800, Steve Kargl wrote: > Just got this panic. If anyone is interested I have the > kenrel and core, so can do some additional poking around. > > troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.0 > > Wed Jan 21 13:28:04 PST 2015 > > FreeBSD troutmask.apl.washington.edu 11.0-CURRENT FreeBSD 11.0-CURRENT #7 r276378M: Mon Dec 29 14:13:57 PST 2014 kargl@troutmask.apl.washington.edu:/data/obj/usr/src/sys/SPEW amd64 > > panic: general protection fault > > Unread portion of the kernel message buffer: > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 3; apic id = 13 > instruction pointer = 0x20:0xffffffff8079abf9 > stack pointer = 0x28:0xfffffe047325e360 > frame pointer = 0x28:0xfffffe047325e440 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 41779 (z) > trap number = 9 > panic: general protection fault > cpuid = 3 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe047325e020 > panic() at panic+0x1c1/frame 0xfffffe047325e0e0 > trap_fatal() at trap_fatal+0x396/frame 0xfffffe047325e140 > trap() at trap+0x6ce/frame 0xfffffe047325e2a0 > calltrap() at calltrap+0x8/frame 0xfffffe047325e2a0 > --- trap 0x9, rip = 0xffffffff8079abf9, rsp = 0xfffffe047325e360, rbp = 0xfffffe047325e440 --- > pmap_remove_pages() at pmap_remove_pages+0x539/frame 0xfffffe047325e440 > exec_new_vmspace() at exec_new_vmspace+0x180/frame 0xfffffe047325e4a0 > exec_elf64_imgact() at exec_elf64_imgact+0x6c0/frame 0xfffffe047325e570 > kern_execve() at kern_execve+0x484/frame 0xfffffe047325e8c0 > sys_execve() at sys_execve+0x35/frame 0xfffffe047325e920 > amd64_syscall() at amd64_syscall+0x289/frame 0xfffffe047325ea30 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe047325ea30 > --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x4251ba, rsp = 0x7ffffe8ebab8, rbp = 0x7ffffe8ec1c0 --- > Uptime: 22d22h22m46s > > #0 doadump (textdump=1) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=1) at pcpu.h:219 > #1 0xffffffff80555bd7 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff80556040 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:746 > #3 0xffffffff807a2986 in trap_fatal (frame=, > eva=) at /usr/src/sys/amd64/amd64/trap.c:867 > #4 0xffffffff807a25de in trap (frame=) > at /usr/src/sys/amd64/amd64/trap.c:201 > #5 0xffffffff80787ca3 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:235 > #6 0xffffffff8079abf9 in pmap_remove_pages (pmap=0xfffff801c627dec8) > at /usr/src/sys/amd64/amd64/pmap.c:5389 Please do 'frame 6' and from there, do 'p *m'. Is it reproducable ? > #7 0xffffffff8051fa00 in exec_new_vmspace (imgp=0xfffffe047325e6e0, > sv=0xffffffff80b3e8e8) at /usr/src/sys/kern/kern_exec.c:1036 > #8 0xffffffff804fed20 in exec_elf64_imgact (imgp=0xfffffe047325e6e0) > at /usr/src/sys/kern/imgact_elf.c:830 > #9 0xffffffff8051e4f4 in kern_execve (td=0xfffff8027588f490, > args=0xfffffe047325e8d8, mac_p=0x1da) at /usr/src/sys/kern/kern_exec.c:486 > #10 0xffffffff8051de15 in sys_execve (td=, > uap=) at /usr/src/sys/kern/kern_exec.c:210 > #11 0xffffffff807a3199 in amd64_syscall (td=0xfffff8027588f490, traced=0) > at subr_syscall.c:133 > #12 0xffffffff80787f8b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:395 > #13 0x00000000004251ba in ?? () > > -- > Steve > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 14:11:36 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF890FE7; Fri, 23 Jan 2015 14:11:36 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9235CAFB; Fri, 23 Jan 2015 14:11:36 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 746701FB; Fri, 23 Jan 2015 09:11:26 -0500 (EST) Message-ID: <54C25688.7000306@protected-networks.net> Date: Fri, 23 Jan 2015 09:11:20 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: SVN r377448 breaks net-snmp on -current References: <54BD5D99.8000200@protected-networks.net> <20150119205316.2f5880d6.ohartman@zedat.fu-berlin.de> In-Reply-To: <20150119205316.2f5880d6.ohartman@zedat.fu-berlin.de> OpenPGP: id=0442D492 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2nUdlGEIX73gUHuKLA9nUohfm5xnMUBTI" Cc: zi@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Jan 2015 14:11:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2nUdlGEIX73gUHuKLA9nUohfm5xnMUBTI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/19/15 14:53, O. Hartmann wrote: > Am Mon, 19 Jan 2015 14:40:09 -0500 > Michael Butler schrieb: >=20 >> Apparently, there was some 'magic' to accessing these sysctls: [ .. snip .. ] >> ./.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp_st= at' >> ./.libs/libnetsnmpmibs.so: undefined reference to `sysctl_read_icmp6_s= tat' >> ./.libs/libnetsnmpmibs.so: undefined reference to >> `sysctl_read_icmp6_msg_stat' >> ./.libs/libnetsnmpmibs.so: undefined reference to >> `sysctl_read_icmp_msg_stat' >> cc: error: linker command failed with exit code 1 (use -v to see invoc= ation) >> *** Error code 1 >=20 > Me, too here. I just filed a PR: Bug 196904 - net-mgmt/net-snmp: undefi= ned reference to > `sysctl_read_XXXXXX=20 >=20 > oh >=20 I note an attempt at fixing this in r377525 but I still see build failures :-( imb --2nUdlGEIX73gUHuKLA9nUohfm5xnMUBTI 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 iEYEARECAAYFAlTCVowACgkQQv9rrgRC1JLDFgCgslG5vS6GKwHmR4MEXz6wHJ8j Xp0AoIABWWnVenVNBOs5XBYBTZ8E7fDE =gyug -----END PGP SIGNATURE----- --2nUdlGEIX73gUHuKLA9nUohfm5xnMUBTI-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 23 15:58:14 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF32FE63 for ; Fri, 23 Jan 2015 15:58:14 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 93096966 for ; Fri, 23 Jan 2015 15:58:14 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t0NFw8BK045625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Jan 2015 07:58:08 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t0NFw8P9045624; Fri, 23 Jan 2015 07:58:08 -0800 (PST) (envelope-from sgk) Date: Fri, 23 Jan 2015 07:58:08 -0800 From: Steve Kargl To: Konstantin Belousov Subject: Re: panic in pmap_remove_pages() Message-ID: <20150123155808.GA36783@troutmask.apl.washington.edu> References: <20150121214706.GA912@troutmask.apl.washington.edu> <20150123105100.GH42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150123105100.GH42409@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Jan 2015 15:58:14 -0000 On Fri, Jan 23, 2015 at 12:51:00PM +0200, Konstantin Belousov wrote: > On Wed, Jan 21, 2015 at 01:47:06PM -0800, Steve Kargl wrote: > > Fatal trap 9: general protection fault while in kernel mode > > cpuid = 3; apic id = 13 > > instruction pointer = 0x20:0xffffffff8079abf9 > > stack pointer = 0x28:0xfffffe047325e360 > > frame pointer = 0x28:0xfffffe047325e440 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 41779 (z) > > trap number = 9 > > panic: general protection fault > > cpuid = 3 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe047325e020 > > panic() at panic+0x1c1/frame 0xfffffe047325e0e0 > > trap_fatal() at trap_fatal+0x396/frame 0xfffffe047325e140 > > trap() at trap+0x6ce/frame 0xfffffe047325e2a0 > > calltrap() at calltrap+0x8/frame 0xfffffe047325e2a0 > > --- trap 0x9, rip = 0xffffffff8079abf9, rsp = 0xfffffe047325e360, rbp = 0xfffffe047325e440 --- > > pmap_remove_pages() at pmap_remove_pages+0x539/frame 0xfffffe047325e440 > > exec_new_vmspace() at exec_new_vmspace+0x180/frame 0xfffffe047325e4a0 > > exec_elf64_imgact() at exec_elf64_imgact+0x6c0/frame 0xfffffe047325e570 > > kern_execve() at kern_execve+0x484/frame 0xfffffe047325e8c0 > > sys_execve() at sys_execve+0x35/frame 0xfffffe047325e920 > > amd64_syscall() at amd64_syscall+0x289/frame 0xfffffe047325ea30 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe047325ea30 > > --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x4251ba, rsp = 0x7ffffe8ebab8, rbp = 0x7ffffe8ec1c0 --- > > Uptime: 22d22h22m46s > > > > #0 doadump (textdump=1) at pcpu.h:219 > > 219 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) #0 doadump (textdump=1) at pcpu.h:219 > > #1 0xffffffff80555bd7 in kern_reboot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:447 > > #2 0xffffffff80556040 in panic (fmt=) > > at /usr/src/sys/kern/kern_shutdown.c:746 > > #3 0xffffffff807a2986 in trap_fatal (frame=, > > eva=) at /usr/src/sys/amd64/amd64/trap.c:867 > > #4 0xffffffff807a25de in trap (frame=) > > at /usr/src/sys/amd64/amd64/trap.c:201 > > #5 0xffffffff80787ca3 in calltrap () > > at /usr/src/sys/amd64/amd64/exception.S:235 > > #6 0xffffffff8079abf9 in pmap_remove_pages (pmap=0xfffff801c627dec8) > > at /usr/src/sys/amd64/amd64/pmap.c:5389 > Please do 'frame 6' and from there, do 'p *m'. Is it reproducable ? > (kgdb) p *m $9 = {plinks = {q = {tqe_next = 0xfffff804384044c0, tqe_prev = 0xfffff8042e89eac0}, s = {ss = { sle_next = 0xfffff804384044c0}, pv = 0xfffff8042e89eac0}, memguard = { p = 18446735295740134592, v = 18446735295577189056}}, listq = { tqe_next = 0xfffff8043cddb158, tqe_prev = 0xfffff804335c2358}, object = 0xfffff801882d5100, pindex = 30, phys_addr = 4352778240, md = { pv_list = {tqh_first = 0xfffff800bc1d37a8, tqh_last = 0xfefff800bc1d37b0}, pv_gen = 1012, pat_mode = 6}, wire_count = 0, busy_lock = 1, hold_count = 0, flags = 0, aflags = 1 '\001', oflags = 0 '\0', queue = 1 '\001', psind = 0 '\0', segind = 7 '\a', order = 13 '\r', pool = 0 '\0', act_count = 5 '\005', valid = 255 'ÿ', dirty = 255 'ÿ'} It would have been reproducible except that the panic truncated the program 'z' (which caused the panic) to 0 bytes and took the source code I was writing. Neither 'z' nor the source code appeared in /usr/lost+found. Unfortunately, the source code was a quickly written Fortran program with obviously a programming error, and I doubt that I'll be able to replicate the program. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 00:30:27 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 221C5EC1 for ; Sat, 24 Jan 2015 00:30:27 +0000 (UTC) Received: from smtpout1.timeweb.ru (smtpout1.timeweb.ru [92.53.117.15]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8188BA9 for ; Sat, 24 Jan 2015 00:30:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=amdmi3.ru; s=dkim; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=tOq3z/Dz9/c6k+HcMZPZXLJiDpejvBb78izcfc7RLZc=; b=YFyGLpRV46pY3hphZXIetusVDbOYL4cu7bxBwHdJlFc4OBd2TxqzHhgj740hzAZOMkCJK2yweJEzApa+WP3YnGxMc3QVCHZZ4Q8lJXm1JqaaSCnRMGX2mU0cTahtGOVioKzGkEj/dLKR4uGiKcluhKXx3XzqAtuNLmvFRrIltIo=; Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YEocD-0003Hp-0Z for freebsd-current@FreeBSD.org; Sat, 24 Jan 2015 03:30:17 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 68993209 for ; Sat, 24 Jan 2015 03:29:40 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 20D9C787D; Sat, 24 Jan 2015 03:29:56 +0300 (MSK) Date: Sat, 24 Jan 2015 03:29:56 +0300 From: Dmitry Marakasov To: freebsd-current@FreeBSD.org Subject: OptionalObsoleteFiles.inc completeness improvement, try 2 Message-ID: <20150124002956.GI1101@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 00:30:27 -0000 Hi! Some years ago I've started a project of improving OptionalObsoleteFiles.inc completeness, which allows make delete-old / delete-old-libs / delete-old-dirs targets completelty remove files which are normally installed when specific src.conf WITHOUT_* knobs are set. In other words, if a user has some WITHOUT_* set in src.conf, specific files are not installed by installworld, but not removed by remove-old, which I try to fix. In yet other words, I want to make it so `make installworld -DWITHOUT_foo=yes` and `make installworld && make delete-old -DWITHOUT_foo=yes` result in the very same file sets. Though the project seems to be useful and have real demand (added to IdeasPage by netchild@, though removed later by brooks@ [1]) and interest ([2]), the change was ignored back then and now the patch is completely rotten. I can redo it, but I need a reviewer. Here's a first small part of the patch: https://reviews.freebsd.org/D1600 The WIP branch with other changes is [3] Also there is a question of delete-old-dirs removing directories which are created by mtree run by installworld unconditionally. This seems to be incorrect - either directories should be installed conditionally or not removed by delete-old-dirs. My patch will address this issue as well, by not remiving unconditionally installed dirs. [1] https://wiki.freebsd.org/action/diff/IdeasPage?action=diff&rev1=260&rev2=261 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168341#c6 [3] https://github.com/AMDmi3/freebsd/compare/obsolete-files -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 00:35:03 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1163EFF3 for ; Sat, 24 Jan 2015 00:35:03 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3017BD7 for ; Sat, 24 Jan 2015 00:35:02 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id fp1so781191pdb.4 for ; Fri, 23 Jan 2015 16:35:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=r8D1Jpqmk0OghDmHLUWOfzHH0siaWFgwsal09m2LYUY=; b=bd85bjarSPm51vLQ/chHItd8zSaZzxoHYsVz4DbowZdHzYOqON4sMuO+Bb3weL+acC MdU4V32KHSkoTrRPQ28vHJZ0zabY0fKxnZJUdX01qOJS3IJwfgObaM+lz+wPyCUc7+mE ngEu9l7TebPr2qY4ZdYbXBRbBSgtxRSm+EJfSzjWIfo4iNxYWrelL1v1MqyRoAu/EZ1B tuDNcBBdcAj6bN50UlJdBm6s15JfQBNU+tHaGebJzrTw0QUsFKnURmXYlYvJWth/P/8/ Cgshs92mv6DN4eersMfyDP9Nax2rGHUvKicHBJys+sd7xX/yanRWT3sZE1mkFswtnCwt +XhA== X-Received: by 10.66.156.229 with SMTP id wh5mr15423312pab.119.1422059702445; Fri, 23 Jan 2015 16:35:02 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id l5sm3043467pbq.40.2015.01.23.16.35.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Jan 2015 16:35:01 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_29980FBF-9A7A-48F8-AB20-F035AAF70108"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: OptionalObsoleteFiles.inc completeness improvement, try 2 From: Garrett Cooper In-Reply-To: <20150124002956.GI1101@hades.panopticon> Date: Fri, 23 Jan 2015 16:35:00 -0800 Message-Id: <4F0C24D1-9313-49BC-992E-5C31DAC6DADC@gmail.com> References: <20150124002956.GI1101@hades.panopticon> To: Dmitry Marakasov X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 00:35:03 -0000 --Apple-Mail=_29980FBF-9A7A-48F8-AB20-F035AAF70108 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 23, 2015, at 16:29, Dmitry Marakasov wrote: > Hi! >=20 > Some years ago I've started a project of improving > OptionalObsoleteFiles.inc completeness, which allows make delete-old > / delete-old-libs / delete-old-dirs targets completelty remove files > which are normally installed when specific src.conf WITHOUT_* knobs > are set. >=20 > In other words, if a user has some WITHOUT_* set in src.conf, > specific files are not installed by installworld, but not removed > by remove-old, which I try to fix. >=20 > In yet other words, I want to make it so `make installworld > -DWITHOUT_foo=3Dyes` and `make installworld && make delete-old > -DWITHOUT_foo=3Dyes` result in the very same file sets. >=20 > Though the project seems to be useful and have real demand (added > to IdeasPage by netchild@, though removed later by brooks@ [1]) > and interest ([2]), the change was ignored back then and now the > patch is completely rotten. I can redo it, but I need a reviewer. > Here's a first small part of the patch: >=20 > https://reviews.freebsd.org/D1600 >=20 > The WIP branch with other changes is [3] >=20 > Also there is a question of delete-old-dirs removing directories > which are created by mtree run by installworld unconditionally. > This seems to be incorrect - either directories should be installed > conditionally or not removed by delete-old-dirs. My patch will > address this issue as well, by not remiving unconditionally installed > dirs. >=20 > [1] = https://wiki.freebsd.org/action/diff/IdeasPage?action=3Ddiff&rev1=3D260&re= v2=3D261 > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D168341#c6 > [3] https://github.com/AMDmi3/freebsd/compare/obsolete-files Hi Dmitry, Seems like we=92ve duplicated work a bit. Have you looked at = ^/projects/building-blocks yet ? Thanks! --Apple-Mail=_29980FBF-9A7A-48F8-AB20-F035AAF70108 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUwui0AAoJEMZr5QU6S73eahwIAIKBn5dnwfkueF0nHPdKNzYq aVCfjVrTXobTHmkrz1/PrKanqDRVdOYpBzcDZwVXLyJjIg6+Q38YSnEp0PpRGMff l/IbGsG6iQVyCFan1qK8PCygdGDw7X9vT3RJzMr+wIAFQ1o5Al0mgU8TUuAl5yAR rxUxw/5mkTGw8w1W/ZFTVzliWT6yJQq+CIeXXPR15hSUGcQ61/ivLFM16LL2mMV1 mFBsBjonnZfAKhHIPH68DqvRUm7U4ZfVg7uA3eclQuDJ6ULr42pZJXxwO9BRmMkw V81+dchwpPrOR6RHckCyAi8D8AogWNw+LCh8IAR6n3sEWS7Y+zSU9sRv9LR4FyE= =FRW5 -----END PGP SIGNATURE----- --Apple-Mail=_29980FBF-9A7A-48F8-AB20-F035AAF70108-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 01:16:35 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E767E95F for ; Sat, 24 Jan 2015 01:16:34 +0000 (UTC) Received: from smtpout1.timeweb.ru (smtpout1.timeweb.ru [92.53.117.15]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 977D5F3A for ; Sat, 24 Jan 2015 01:16:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=amdmi3.ru; s=dkim; h=Content-Transfer-Encoding:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=EbUO3noukaSaHNj25c0YoyngEH+wVm4HFbPCN4tF+7Y=; b=CydahQbn7hN3WwmE3IRu/nhBUujvOqtzkr9/LeBczoM0WnsnMts2VLrcMNDvdHdMD7XrEVw8wRai9QiWT0Ez/QCilKjPyD5ai0yM8bupQclHGRu9KpeFHEUJz0IQunhr+EOl9OOUvYaFtdxSQx8z/xz5eq55HIPqZdt+jftWJ5U=; Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YEpKv-00063L-K7; Sat, 24 Jan 2015 04:16:29 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id E66BD2C5; Sat, 24 Jan 2015 04:15:54 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 52E074D91; Sat, 24 Jan 2015 04:16:10 +0300 (MSK) Date: Sat, 24 Jan 2015 04:16:10 +0300 From: Dmitry Marakasov To: Garrett Cooper Subject: Re: OptionalObsoleteFiles.inc completeness improvement, try 2 Message-ID: <20150124011610.GJ1101@hades.panopticon> References: <20150124002956.GI1101@hades.panopticon> <4F0C24D1-9313-49BC-992E-5C31DAC6DADC@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F0C24D1-9313-49BC-992E-5C31DAC6DADC@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 01:16:35 -0000 * Garrett Cooper (yaneurabeya@gmail.com) wrote: > > Some years ago I've started a project of improving > > OptionalObsoleteFiles.inc completeness, which allows make delete-old > > / delete-old-libs / delete-old-dirs targets completelty remove files > > which are normally installed when specific src.conf WITHOUT_* knobs > > are set. > >=20 > > In other words, if a user has some WITHOUT_* set in src.conf, > > specific files are not installed by installworld, but not removed > > by remove-old, which I try to fix. > >=20 > > In yet other words, I want to make it so `make installworld > > -DWITHOUT_foo=3Dyes` and `make installworld && make delete-old > > -DWITHOUT_foo=3Dyes` result in the very same file sets. > >=20 > > Though the project seems to be useful and have real demand (added > > to IdeasPage by netchild@, though removed later by brooks@ [1]) > > and interest ([2]), the change was ignored back then and now the > > patch is completely rotten. I can redo it, but I need a reviewer. > > Here's a first small part of the patch: > >=20 > > https://reviews.freebsd.org/D1600 > >=20 > > The WIP branch with other changes is [3] > >=20 > > Also there is a question of delete-old-dirs removing directories > > which are created by mtree run by installworld unconditionally. > > This seems to be incorrect - either directories should be installed > > conditionally or not removed by delete-old-dirs. My patch will > > address this issue as well, by not remiving unconditionally installed > > dirs. > >=20 > > [1] https://wiki.freebsd.org/action/diff/IdeasPage?action=3Ddiff&rev1= =3D260&rev2=3D261 > > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D168341#c6 > > [3] https://github.com/AMDmi3/freebsd/compare/obsolete-files >=20 > Hi Dmitry, > Seems like we=E2=80=99ve duplicated work a bit. Have you looked at ^/p= rojects/building-blocks yet ? Hm, seems so, partly. How do you gather missing entries? My way is pretty dumb, I just do bunch of installworlds + delete-old's and add diff to the file, you probably do it more cleverly. Will committing my changes interfere with your work? If so, it may be better to direct them to your branch instead. Especially if you are more aware of knob combinations and their effects. --=20 Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 01:20:51 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B43DB62 for ; Sat, 24 Jan 2015 01:20:51 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5489FE4 for ; Sat, 24 Jan 2015 01:20:50 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id fa1so387444pad.8 for ; Fri, 23 Jan 2015 17:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=CYfZtrKLeYsSSi/XZuGarxLKFA9M0I9u1J0jIPC5bfw=; b=KjO77ZqAQnWvit8uVisEYkIWgvLyDW7+4WxeEZsElIYv9KrgsHuWBjELckJOnvgcAH dwWTWnhx2M/c0xaIh+jTJbcJqw2ar783ld4Pde7NQVrDIv2Kr7ZeS11AiLe93+CTGUOR i8eO2psppNXouOX8oZ/XOwODWBfSw6KS45xNkQgWP8cbEkk6yiUZLrZku/O8eHZJYbLO kClUfa6m7inW0ZT0XBuaK5VJlHEKDMJwPpPhtyLizbwDA0/MCJqNnq01vmnQH52IvjJi N3GCTJ8NUpwqXVEwUDG3HTrDNxnKCW0GCz0VZ+SmSZ+SPB0VCN/6LvGF4SJxGhB188qj 9INg== X-Received: by 10.66.62.229 with SMTP id b5mr16227523pas.30.1422062450440; Fri, 23 Jan 2015 17:20:50 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id nh4sm3107573pdb.37.2015.01.23.17.20.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Jan 2015 17:20:49 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_0CA27C11-562F-4509-8911-BA879DD8017C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: OptionalObsoleteFiles.inc completeness improvement, try 2 From: Garrett Cooper In-Reply-To: <20150124011610.GJ1101@hades.panopticon> Date: Fri, 23 Jan 2015 17:20:48 -0800 Message-Id: <8162C656-E851-492D-840A-27A222E3A7CC@gmail.com> References: <20150124002956.GI1101@hades.panopticon> <4F0C24D1-9313-49BC-992E-5C31DAC6DADC@gmail.com> <20150124011610.GJ1101@hades.panopticon> To: Dmitry Marakasov X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 01:20:51 -0000 --Apple-Mail=_0CA27C11-562F-4509-8911-BA879DD8017C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 23, 2015, at 17:16, Dmitry Marakasov wrote: > * Garrett Cooper (yaneurabeya@gmail.com) wrote: >=20 >>> Some years ago I've started a project of improving >>> OptionalObsoleteFiles.inc completeness, which allows make delete-old >>> / delete-old-libs / delete-old-dirs targets completelty remove files >>> which are normally installed when specific src.conf WITHOUT_* knobs >>> are set. >>>=20 >>> In other words, if a user has some WITHOUT_* set in src.conf, >>> specific files are not installed by installworld, but not removed >>> by remove-old, which I try to fix. >>>=20 >>> In yet other words, I want to make it so `make installworld >>> -DWITHOUT_foo=3Dyes` and `make installworld && make delete-old >>> -DWITHOUT_foo=3Dyes` result in the very same file sets. >>>=20 >>> Though the project seems to be useful and have real demand (added >>> to IdeasPage by netchild@, though removed later by brooks@ [1]) >>> and interest ([2]), the change was ignored back then and now the >>> patch is completely rotten. I can redo it, but I need a reviewer. >>> Here's a first small part of the patch: >>>=20 >>> https://reviews.freebsd.org/D1600 >>>=20 >>> The WIP branch with other changes is [3] >>>=20 >>> Also there is a question of delete-old-dirs removing directories >>> which are created by mtree run by installworld unconditionally. >>> This seems to be incorrect - either directories should be installed >>> conditionally or not removed by delete-old-dirs. My patch will >>> address this issue as well, by not remiving unconditionally = installed >>> dirs. >>>=20 >>> [1] = https://wiki.freebsd.org/action/diff/IdeasPage?action=3Ddiff&rev1=3D260&re= v2=3D261 >>> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D168341#c6 >>> [3] https://github.com/AMDmi3/freebsd/compare/obsolete-files >>=20 >> Hi Dmitry, >> Seems like we=92ve duplicated work a bit. Have you looked at = ^/projects/building-blocks yet ? >=20 > Hm, seems so, partly. How do you gather missing entries? My way is > pretty dumb, I just do bunch of installworlds + delete-old's and add > diff to the file, you probably do it more cleverly. Will committing > my changes interfere with your work? If so, it may be better to direct > them to your branch instead. Especially if you are more aware of knob > combinations and their effects. I wrote this script to track what files get installed by directories:=20 = https://svnweb.freebsd.org/base/projects/building-blocks/tools/add-optiona= l-obsolete-files-entries.sh?revision=3D275238&view=3Dmarkup . It=92s not = perfect (doesn=92t work for =93kitchen sink=94 directories like etc/ and = share/=85), but it=92s a reasonable starting point for grabbing all of = the files. I=92m going to hold off on the rc.d deletions/rewrites for dependent = services after I do more targeted review/testing, as it might screw up = boot order in unexpected ways with services and programs that get run = out of order, but I=92m reasonably confident that the contents of the = branch work. I was going to start cherry-picking changes from the branch this = weekend. Thanks! --Apple-Mail=_0CA27C11-562F-4509-8911-BA879DD8017C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUwvNwAAoJEMZr5QU6S73eWZwH/i2qFvTPQX3ziU0h2jQ2h3FZ bjk3CDAYN1eL73lProxq75e+AAram7NlQUg6h6trGzPW+SDB1ajJLBTwIpkzMff5 lVrVFtGiishyRUic7kvYfGXkDpaEG8HsCrIRorEZ4C5L7UUNL5aZrtKS9WNYm4qS H7sYel5apLZwBapshWzwkziWqQjTjCXNivsRbmpC3+rAOm9EJ/IPD/VASpd1LeW9 RLuLhACRpBujPDiCEgyru/IHycTSvdeWZ6dc63mk5nXn31uC8ATsBK9527RtBNMb d80qmjDv19J/AQjh5ntOvHMxr0Sd2EJm/AMQgjZvQMxwqAyYTnqGEzl9nRuuW1U= =wzWi -----END PGP SIGNATURE----- --Apple-Mail=_0CA27C11-562F-4509-8911-BA879DD8017C-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 01:23:25 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4B68C71 for ; Sat, 24 Jan 2015 01:23:24 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9B758 for ; Sat, 24 Jan 2015 01:23:24 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id lj1so408431pab.6 for ; Fri, 23 Jan 2015 17:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3wjl8FS0r9XNMeqVvd35CxGxNx5I77qYUodksB1JnDs=; b=ZSzRao7uYmL4wV6bSMSeKVYN86rNIJbVKMxr0ObdSPsElkLyo+24dFlJcEfBf1BlMh GKoFcOUJreSunKKWvlLw48zlRHzt1vDgajk2fVQmGjpNBu669hPM/uV+x6BwUAMXg6kq w/lw0DVfIbB/8wyVPalnYHHLdL6YNwJxdulzN2VTRnU3fCkrnKxzr3kr1G3NdEFjNwJm SSCakYLCkBWRyVvgjzb0i3sZIgZgA7XlRkXT7exJZ25HNg5cv9C9OQYr68cmgfDp1LT1 mbCwLbdgEevGCOOGNEjL27MBPcilGyZ1d826rGBBpf6HKNMh+d93Q2hmeJv2RcNxkcDh dRMg== X-Received: by 10.68.203.195 with SMTP id ks3mr16068488pbc.104.1422062604331; Fri, 23 Jan 2015 17:23:24 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id ej7sm3126226pac.21.2015.01.23.17.23.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Jan 2015 17:23:23 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C22E1B49-1F7B-49E6-B4C3-C8054815AC7C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: OptionalObsoleteFiles.inc completeness improvement, try 2 From: Garrett Cooper In-Reply-To: <8162C656-E851-492D-840A-27A222E3A7CC@gmail.com> Date: Fri, 23 Jan 2015 17:23:22 -0800 Message-Id: <8D1D9451-B8B1-4121-8F89-E03951DB65BF@gmail.com> References: <20150124002956.GI1101@hades.panopticon> <4F0C24D1-9313-49BC-992E-5C31DAC6DADC@gmail.com> <20150124011610.GJ1101@hades.panopticon> <8162C656-E851-492D-840A-27A222E3A7CC@gmail.com> To: Dmitry Marakasov X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 01:23:25 -0000 --Apple-Mail=_C22E1B49-1F7B-49E6-B4C3-C8054815AC7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 23, 2015, at 17:20, Garrett Cooper wrote: > On Jan 23, 2015, at 17:16, Dmitry Marakasov wrote: >=20 >> * Garrett Cooper (yaneurabeya@gmail.com) wrote: >>=20 >>>> Some years ago I've started a project of improving >>>> OptionalObsoleteFiles.inc completeness, which allows make = delete-old >>>> / delete-old-libs / delete-old-dirs targets completelty remove = files >>>> which are normally installed when specific src.conf WITHOUT_* knobs >>>> are set. >>>>=20 >>>> In other words, if a user has some WITHOUT_* set in src.conf, >>>> specific files are not installed by installworld, but not removed >>>> by remove-old, which I try to fix. >>>>=20 >>>> In yet other words, I want to make it so `make installworld >>>> -DWITHOUT_foo=3Dyes` and `make installworld && make delete-old >>>> -DWITHOUT_foo=3Dyes` result in the very same file sets. >>>>=20 >>>> Though the project seems to be useful and have real demand (added >>>> to IdeasPage by netchild@, though removed later by brooks@ [1]) >>>> and interest ([2]), the change was ignored back then and now the >>>> patch is completely rotten. I can redo it, but I need a reviewer. >>>> Here's a first small part of the patch: >>>>=20 >>>> https://reviews.freebsd.org/D1600 >>>>=20 >>>> The WIP branch with other changes is [3] >>>>=20 >>>> Also there is a question of delete-old-dirs removing directories >>>> which are created by mtree run by installworld unconditionally. >>>> This seems to be incorrect - either directories should be installed >>>> conditionally or not removed by delete-old-dirs. My patch will >>>> address this issue as well, by not remiving unconditionally = installed >>>> dirs. >>>>=20 >>>> [1] = https://wiki.freebsd.org/action/diff/IdeasPage?action=3Ddiff&rev1=3D260&re= v2=3D261 >>>> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D168341#c6 >>>> [3] https://github.com/AMDmi3/freebsd/compare/obsolete-files >>>=20 >>> Hi Dmitry, >>> Seems like we=92ve duplicated work a bit. Have you looked at = ^/projects/building-blocks yet ? >>=20 >> Hm, seems so, partly. How do you gather missing entries? My way is >> pretty dumb, I just do bunch of installworlds + delete-old's and add >> diff to the file, you probably do it more cleverly. Will committing >> my changes interfere with your work? If so, it may be better to = direct >> them to your branch instead. Especially if you are more aware of knob >> combinations and their effects. >=20 > I wrote this script to track what files get installed by directories:=20= > = https://svnweb.freebsd.org/base/projects/building-blocks/tools/add-optiona= l-obsolete-files-entries.sh?revision=3D275238&view=3Dmarkup . It=92s not = perfect (doesn=92t work for =93kitchen sink=94 directories like etc/ and = share/=85), but it=92s a reasonable starting point for grabbing all of = the files. >=20 > I=92m going to hold off on the rc.d deletions/rewrites for dependent = services after I do more targeted review/testing, as it might screw up = boot order in unexpected ways with services and programs that get run = out of order, but I=92m reasonably confident that the contents of the = branch work. >=20 > I was going to start cherry-picking changes from the branch this = weekend. Forgot to respond on one important point: reviewing and committing the = higher-level changes (make remove-old) shouldn=92t be a problem, and = I=92ll be sure to commit the overlapping changes with = OptionalObsoleteFiles.inc first to reduce the diff between our branches. Thanks! --Apple-Mail=_C22E1B49-1F7B-49E6-B4C3-C8054815AC7C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUwvQKAAoJEMZr5QU6S73ecRIIAIDbkwf6RXRp0ag8Fy4rkLhF 67JD+JX2fETcQM3Igorq8VY0BF4rILIFdrDxxRpf8h+LzOqeGMw5Dv041HUl3PV1 5LhjBUTGbSsZuVk8w9iY+6WTN2w4dvHGjfoSCNtxc81BMirehmqR+/mEVi/TY6Xc jFK/Ru1xphzD21uwExRonhBPSXawQ48Ti+gl6uCaPLlDsiFN8X0v+k2JxxJkM5Q+ Tn4CpXEtNvdcoR9jR1Xr5U3hzJC3UUrA8rKj9BfsLZET6Y4i+UwWpfADdTjhOOEK pHafYWVHQmp2xUytF5Qx5zJD+dualnjuJiihVHTReHmRPh2yYcsfgrWtUtTMmlo= =djr9 -----END PGP SIGNATURE----- --Apple-Mail=_C22E1B49-1F7B-49E6-B4C3-C8054815AC7C-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 08:05:51 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57D343C0; Sat, 24 Jan 2015 08:05:51 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9CBF33; Sat, 24 Jan 2015 08:05:50 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D15C67300A; Sat, 24 Jan 2015 09:11:01 +0100 (CET) Date: Sat, 24 Jan 2015 09:11:01 +0100 From: Luigi Rizzo To: current@freebsd.org, emaste@freebsd.org Subject: elftoolchain version of strip unlinks hard-linked files ? Message-ID: <20150124081101.GA74579@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 08:05:51 -0000 I just found that recent versions of 'strip' on head (the change occurred between svn 276756 and 277633, not in the code but with the change from GNU binutils to the elf toolchain) when operating on hard-linked files, creates a new file instead of modifying the original: This is the old behaviour: $ rm a b c; cp some-binary a; ln a b; ln a c; ls -l a b c -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:57 a -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:57 b -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:57 c $ ./old-strip a $ ls -l a b c -rwxr-xr-x 3 luigi wheel 37000 Jan 23 15:57 a -rwxr-xr-x 3 luigi wheel 37000 Jan 23 15:57 b -rwxr-xr-x 3 luigi wheel 37000 Jan 23 15:57 c $ ./old-strip --version GNU strip 2.17.50 [FreeBSD] 2007-07-03 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. and this is the new one: $rm a b c; cp some-binary a; ln a b; ln a c; ls -l a b c -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:58 a -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:58 b -rwxr-xr-x 3 luigi wheel 42527 Jan 23 15:58 c $ ~/FreeBSD/usr/obj-pico-amd64/usr/home/luigi/FreeBSD/head/tmp/usr/bin/strip a $ ls -l a b c -rwxr-xr-x 1 luigi wheel 37000 Jan 23 15:58 a -rwxr-xr-x 2 luigi wheel 42527 Jan 23 15:58 b -rwxr-xr-x 2 luigi wheel 42527 Jan 23 15:58 c $ ~/FreeBSD/usr/obj-pico-amd64/usr/home/luigi/FreeBSD/head/tmp/usr/bin/strip --version strip (elftoolchain r3136M) I believe the elftoolchain is doing it wrong and should be fixed. The GNU version seems to use a function called smart_rename() (see contrib/binutils/binutils : objcopy.c and rename.c ) that deals with multiple hard links. (for the records, I found it out because it explodes the /stand directory generated by crunchgen when i build a picobsd image). It is also weird that the new strip, despite being statically linked, looks up for helper programs somewhere, because if i copy it to a different directory it makes the copy but no longer works correctly: $ cp ~/FreeBSD/usr/obj-pico-amd64/usr/home/luigi/FreeBSD/head/tmp/usr/bin/strip ./new-strip $ file ./new-strip ./new-strip: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 10.1 (1001506), not stripped $ rm a b c; cp some-binary a; ln a b; ln a c; ls -l a b c -rwxr-xr-x 3 luigi wheel 42527 Jan 23 16:01 a -rwxr-xr-x 3 luigi wheel 42527 Jan 23 16:01 b -rwxr-xr-x 3 luigi wheel 42527 Jan 23 16:01 c $ ./new-strip a $ ls -l a b c -rwxr-xr-x 1 luigi wheel 42527 Jan 23 16:02 a -rwxr-xr-x 2 luigi wheel 42527 Jan 23 16:01 b -rwxr-xr-x 2 luigi wheel 42527 Jan 23 16:01 c Note how this time the file has been unlinked and recreated, but not stripped. There is no mention of dependencies in the manpage head/contrib/elftoolchain/elfcopy/strip.1 and since the file is statically linked i find the behaviour very surprising. cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 10:02:01 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92E8D9B7 for ; Sat, 24 Jan 2015 10:02:01 +0000 (UTC) Received: from dchagin.static.corbina.net (dchagin.static.corbina.ru [78.107.232.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dchagin.static.corbina.net", Issuer "dchagin.static.corbina.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1530DBF0 for ; Sat, 24 Jan 2015 10:02:00 +0000 (UTC) Received: from dchagin.static.corbina.net (localhost [127.0.0.1]) by dchagin.static.corbina.net (8.14.9/8.14.9) with ESMTP id t0O9kX7s001841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 24 Jan 2015 12:46:33 +0300 (MSK) (envelope-from dchagin@dchagin.static.corbina.net) Received: (from dchagin@localhost) by dchagin.static.corbina.net (8.14.9/8.14.9/Submit) id t0O9kXvG001840 for freebsd-current@freebsd.org; Sat, 24 Jan 2015 12:46:33 +0300 (MSK) (envelope-from dchagin) Date: Sat, 24 Jan 2015 12:46:33 +0300 From: Chagin Dmitry To: freebsd-current@freebsd.org Subject: dblfault panic r277611 Message-ID: <20150124094633.GA1804@dchagin.static.corbina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 10:02:01 -0000 Hi, dchagin.static.corbina.net dumped core - see /var/crash/vmcore.7 Sat Jan 24 01:02:20 MSK 2015 FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r27= 7611+c41ef74(lemul): Sat Jan 24 00:53:45 MSK 2015 root@dchagin.static.c= orbina.net:/home/rootobj/home/git/head/sys/YOY amd64 panic: double fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: ffs_syncvnode+0x3b0/frame 0xfffffe033c22bd50 ffs_truncate() at ffs_truncate+0xc6a/frame 0xfffffe033c22c150 ufs_direnter() at ufs_direnter+0xde5/frame 0xfffffe033c22c280 ufs_mkdir() at ufs_mkdir+0xb07/frame 0xfffffe033c22c4a0 Fatal double fault rip =3D 0xffffffff807a8d03 rsp =3D 0xfffffe033c228e60 rbp =3D 0xfffffe033c229000 cpuid =3D 5; apic id =3D 05 panic: double fault cpuid =3D 5 KDB: enter: panic Reading symbols from /boot/kernel/if_tap.ko.symbols...done. Loaded symbols for /boot/kernel/if_tap.ko.symbols Reading symbols from /boot/kernel/if_bridge.ko.symbols...done. Loaded symbols for /boot/kernel/if_bridge.ko.symbols Reading symbols from /boot/kernel/bridgestp.ko.symbols...done. Loaded symbols for /boot/kernel/bridgestp.ko.symbols Reading symbols from /boot/kernel/usb.ko.symbols...done. Loaded symbols for /boot/kernel/usb.ko.symbols Reading symbols from /boot/kernel/xhci.ko.symbols...done. Loaded symbols for /boot/kernel/xhci.ko.symbols Reading symbols from /boot/kernel/vmm.ko.symbols...done. Loaded symbols for /boot/kernel/vmm.ko.symbols Reading symbols from /boot/kernel/nmdm.ko.symbols...done. Loaded symbols for /boot/kernel/nmdm.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/pseudofs.ko.symbols...done. Loaded symbols for /boot/kernel/pseudofs.ko.symbols Reading symbols from /boot/kernel/linux_common.ko.symbols...done. Loaded symbols for /boot/kernel/linux_common.ko.symbols Reading symbols from /boot/kernel/procfs.ko.symbols...done. Loaded symbols for /boot/kernel/procfs.ko.symbols Reading symbols from /boot/kernel/ukbd.ko.symbols...done. Loaded symbols for /boot/kernel/ukbd.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols #0 doadump (textdump=3D771179792) at /home/git/head/sys/kern/kern_shutdown.c:262 262 dumptid =3D curthread->td_tid; (kgdb) #0 doadump (textdump=3D771179792) at /home/git/head/sys/kern/kern_shutdown.c:262 #1 0xffffffff803c1b08 in db_fncall_generic (addr=3D-2139713712,=20 rv=3D0xfffffe032df744a0, nargs=3D0, args=3D0xfffffe032df744b0) at /home/git/head/sys/ddb/db_command.c:568 #2 0xffffffff803c17d3 in db_fncall (dummy1=3D-2185367173664, dummy2=3D0,= =20 dummy3=3D0, dummy4=3D0xfffffe032df745e0 "\n") at /home/git/head/sys/ddb/db_command.c:616 #3 0xffffffff803c142b in db_command (last_cmdp=3D0xffffffff810fd6a8,=20 cmd_table=3D0x0, dopager=3D1) at /home/git/head/sys/ddb/db_command.c:440 #4 0xffffffff803c0f9d in db_command_loop () at /home/git/head/sys/ddb/db_command.c:493 #5 0xffffffff803c58d9 in db_trap (type=3D3, code=3D0) at /home/git/head/sys/ddb/db_main.c:251 #6 0xffffffff807cc704 in kdb_trap (type=3D3, code=3D0, tf=3D0xfffffe032df7= 4cc0) at /home/git/head/sys/kern/subr_kdb.c:654 #7 0xffffffff80c94e1d in trap (frame=3D0xfffffe032df74cc0) at /home/git/head/sys/amd64/amd64/trap.c:546 #8 0xffffffff80c9655f in trap_check (frame=3D0xfffffe032df74cc0) at /home/git/head/sys/amd64/amd64/trap.c:645 #9 0xffffffff80c691a2 in calltrap () at /home/git/head/sys/amd64/amd64/exception.S:235 #10 0xffffffff807cbf15 in breakpoint () at cpufunc.h:63 #11 0xffffffff807cbaff in kdb_enter (why=3D0xffffffff80dcd635 "panic",=20 msg=3D0xffffffff80dcd635 "panic") at /home/git/head/sys/kern/subr_kdb.c= :443 #12 0xffffffff80769768 in vpanic (fmt=3D0xffffffff80e24597 "double fault",= =20 ap=3D0xfffffe032df74ec0) at /home/git/head/sys/kern/kern_shutdown.c:740 #13 0xffffffff80769820 in panic (fmt=3D0xffffffff80e24597 "double fault") at /home/git/head/sys/kern/kern_shutdown.c:676 #14 0xffffffff80c9667d in dblfault_handler (frame=3D0xfffffe032df74f40) at /home/git/head/sys/amd64/amd64/trap.c:912 #15 0xffffffff80c6929c in Xdblfault () at /home/git/head/sys/amd64/amd64/exception.S:291 #16 0xffffffff807a8d03 in cpu_search_lowest (cg=3DCannot access memory at a= ddress 0xfffffe033c228ec8 ) at /home/git/head/sys/kern/sched_ule.c:764 #17 0xffffffff807a9094 in cpu_search_lowest (cg=3D0xffffffff8128a6e8,=20 low=3D0xfffffe033c2292f8) at /home/git/head/sys/kern/sched_ule.c:690 #18 0xffffffff807a9094 in cpu_search_lowest (cg=3D0xffffffff8128a6b0,=20 low=3D0xfffffe033c229380) at /home/git/head/sys/kern/sched_ule.c:690 #19 0xffffffff807b0f56 in sched_lowest (cg=3D0xffffffff8128a6b0, mask=3D {__bits =3D {255, 0, 0, 0}}, pri=3D121, maxload=3D2147483647, prefe= r=3D5) at /home/git/head/sys/kern/sched_ule.c:796 #20 0xffffffff807abcdb in sched_pickcpu (td=3D0xfffff80009e5a9a0, flags=3D0) at /home/git/head/sys/kern/sched_ule.c:1276 #21 0xffffffff807ace35 in sched_add (td=3D0xfffff80009e5a9a0, flags=3D0) at /home/git/head/sys/kern/sched_ule.c:2395 #22 0xffffffff807acac9 in sched_wakeup (td=3D0xfffff80009e5a9a0) at /home/git/head/sys/kern/sched_ule.c:2029 #23 0xffffffff8077d6a8 in setrunnable (td=3D0xfffff80009e5a9a0) at /home/git/head/sys/kern/kern_synch.c:544 #24 0xffffffff807e4e98 in sleepq_resume_thread (sq=3D0xfffff80009e55d80,=20 td=3D0xfffff80009e5a9a0, pri=3D0) at /home/git/head/sys/kern/subr_sleepqueue.c:776 #25 0xffffffff807e306a in sleepq_timeout (arg=3D0xfffff80009e5a9a0) at /home/git/head/sys/kern/subr_sleepqueue.c:915 #26 0xffffffff80791b40 in softclock_call_cc (c=3D0xfffff80009e5ad38,=20 cc=3D0xffffffff813a4200, direct=3D1) at /home/git/head/sys/kern/kern_timeout.c:724 #27 0xffffffff807913bd in callout_process (now=3D740683739317) at /home/git/head/sys/kern/kern_timeout.c:499 #28 0xffffffff80ce346a in handleevents (now=3D740683739317, fake=3D0) at /home/git/head/sys/kern/kern_clocksource.c:212 #29 0xffffffff80ce3fd6 in timercb (et=3D0xffffffff8137df68, arg=3D0x0) at /home/git/head/sys/kern/kern_clocksource.c:345 #30 0xffffffff80d376e3 in lapic_handle_timer (frame=3D0xfffffe033c229c50) at /home/git/head/sys/x86/x86/local_apic.c:883 #31 0xffffffff80c69cfc in Xtimerint () at apic_vector.S:109 #32 0xffffffff80c745ef in write_rflags (rf=3D642) at cpufunc.h:382 #33 0xffffffff80c6f225 in intr_restore (rflags=3D642) at cpufunc.h:775 #34 0xffffffff80c71ce8 in spinlock_exit () at /home/git/head/sys/amd64/amd64/machdep.c:2177 #35 0xffffffff8074335c in __mtx_unlock_spin_flags (c=3D0xffffffff8119ec80,= =20 opts=3D0, file=3D0xffffffff80dc3d2b "/home/git/head/sys/kern/kern_cons.= c",=20 line=3D530) at /home/git/head/sys/kern/kern_mutex.c:305 #36 0xffffffff806df9fc in cnputs (p=3D0xfffffe033c22a402 "\"<\003=D0=A7=D0= =AA=D0=AA") at /home/git/head/sys/kern/kern_cons.c:530 #37 0xffffffff807d76ae in putbuf (c=3D10, ap=3D0xfffffe033c22a3b8) at /home/git/head/sys/kern/subr_prf.c:427 #38 0xffffffff807d60d6 in putchar (c=3D10, arg=3D0xfffffe033c22a3b8) at /home/git/head/sys/kern/subr_prf.c:471 #39 0xffffffff807d43e3 in kvprintf (fmt=3D0xffffffff80d77b33 "",=20 func=3D0xffffffff807d6010 , arg=3D0xfffffe033c22a3b8, radix=3D= 10,=20 ap=3D0xfffffe033c22a510) at /home/git/head/sys/kern/subr_prf.c:720 #40 0xffffffff807d6569 in _vprintf (level=3D-1, flags=3D5,=20 fmt=3D0xffffffff80d77b31 "%c", ap=3D0xfffffe033c22a510) at /home/git/head/sys/kern/subr_prf.c:271 #41 0xffffffff807d68dd in vprintf (fmt=3D0xffffffff80d77b31 "%c",=20 ap=3D0xfffffe033c22a510) at /home/git/head/sys/kern/subr_prf.c:388 #42 0xffffffff807d689b in printf (fmt=3D0xffffffff80d77b31 "%c") at /home/git/head/sys/kern/subr_prf.c:377 #43 0xffffffff803c5d55 in db_putc (c=3D10) at /home/git/head/sys/ddb/db_output.c:156 #44 0xffffffff803c5b21 in db_putchar (c=3D10, arg=3D0xfffffe033c22aad8) at /home/git/head/sys/ddb/db_output.c:128 #45 0xffffffff807d3b65 in kvprintf (fmt=3D0xffffffff80d8090f "",=20 func=3D0xffffffff803c5af0 , arg=3D0xfffffe033c22aad8, radix= =3D16,=20 ap=3D0xfffffe033c22aac0) at /home/git/head/sys/kern/subr_prf.c:645 #46 0xffffffff803c5ad8 in db_printf (fmt=3D0xffffffff80d8090e "\n") at /home/git/head/sys/ddb/db_output.c:340 #47 0xffffffff80c67f73 in db_print_stack_entry ( name=3D0xffffffff815c8262 "ufs_mkdir", narg=3D0, argnp=3D0x0,=20 argp=3D0xfffffe033c22c4b0, callpc=3D18446744071574694567,=20 frame=3D0xfffffe033c22c4a0) at /home/git/head/sys/amd64/amd64/db_trace.= c:260 #48 0xffffffff80c66f3b in db_backtrace (td=3D0xfffff801ad926000, tf=3D0x0,= =20 frame=3D0xfffffe033c22c4a0, pc=3D18446744071574694567, count=3D1005) at /home/git/head/sys/amd64/amd64/db_trace.c:462 #49 0xffffffff80c66bdf in db_trace_self () at /home/git/head/sys/amd64/amd64/db_trace.c:498 #50 0xffffffff803c568e in db_trace_self_wrapper () at /home/git/head/sys/ddb/db_main.c:268 #51 0xffffffff807cbcd8 in kdb_backtrace () at /home/git/head/sys/kern/subr_kdb.c:370 #52 0xffffffff807fe924 in _witness_debugger (cond=3D1,=20 msg=3D0xffffffff80dd6e29 "witness_checkorder") at /home/git/head/sys/kern/subr_witness.c:2904 #53 0xffffffff807fe2de in witness_checkorder (lock=3D0xfffff80193effd50,=20 flags=3D9, file=3D0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.= c",=20 line=3D2164, interlock=3D0xfffff80193effd80) at /home/git/head/sys/kern/subr_witness.c:1365 #54 0xffffffff80730d65 in __lockmgr_args (lk=3D0xfffff80193effd50,=20 flags=3D524544, ilk=3D0xfffff80193effd80, wmesg=3D0x0, pri=3D0, timo=3D= 0,=20 file=3D0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=3D= 2164) at /home/git/head/sys/kern/kern_lock.c:756 #55 0xffffffff80bf1438 in _lockmgr_args (lk=3D0xfffff80193effd50, flags=3D5= 24544,=20 ilk=3D0xfffff80193effd80, wmesg=3D0x0, prio=3D0, timo=3D0,=20 file=3D0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=3D= 2164) at lockmgr.h:98 #56 0xffffffff80bef677 in ffs_lock (ap=3D0xfffffe033c22b7c8) at /home/git/head/sys/ufs/ffs/ffs_vnops.c:385 #57 0xffffffff80d47cd4 in VOP_LOCK1_APV (vop=3D0xffffffff810cd328,=20 a=3D0xfffffe033c22b7c8) at vnode_if.c:2082 #58 0xffffffff808ac2f3 in VOP_LOCK1 (vp=3D0xfffff80193effce8, flags=3D52454= 4,=20 file=3D0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=3D= 2164) at vnode_if.h:859 #59 0xffffffff808aa122 in _vn_lock (vp=3D0xfffff80193effce8, flags=3D524544= ,=20 file=3D0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=3D= 2164) at /home/git/head/sys/kern/vfs_vnops.c:1531 #60 0xffffffff8088d636 in vget (vp=3D0xfffff80193effce8, flags=3D524544,=20 td=3D0xfffff801ad926000) at /home/git/head/sys/kern/vfs_subr.c:2164 #61 0xffffffff8087884f in vfs_hash_get (mp=3D0xfffff80009db2000, hash=3D712= 69052,=20 flags=3D524288, td=3D0xfffff801ad926000, vpp=3D0xfffffe033c22bb40, fn= =3D0,=20 arg=3D0x0) at /home/git/head/sys/kern/vfs_hash.c:89 #62 0xffffffff80be7969 in ffs_vgetf (mp=3D0xfffff80009db2000, ino=3D7126905= 2,=20 flags=3D524288, vpp=3D0xfffffe033c22bb40, ffs_flags=3D1) at /home/git/head/sys/ufs/ffs/ffs_vfsops.c:1636 #63 0xffffffff80bd1d02 in flush_pagedep_deps (pvp=3D0xfffff80193c8d588,=20 mp=3D0xfffff80009db2000, diraddhdp=3D0xfffff80193769b58) at /home/git/head/sys/ufs/ffs/ffs_softdep.c:12929 #64 0xffffffff80bd182c in softdep_sync_buf (vp=3D0xfffff80193c8d588,=20 bp=3D0xfffffe02d6a8d6d0, waitfor=3D1) at /home/git/head/sys/ufs/ffs/ffs_softdep.c:12621 #65 0xffffffff80bf0d40 in ffs_syncvnode (vp=3D0xfffff80193c8d588, waitfor= =3D1,=20 flags=3D0) at /home/git/head/sys/ufs/ffs/ffs_vnops.c:280 #66 0xffffffff80babd9a in ffs_truncate (vp=3D0xfffff80193c8d588, length=3D5= 12,=20 flags=3D2176, cred=3D0xfffff80009c52b00) at /home/git/head/sys/ufs/ffs/ffs_inode.c:339 #67 0xffffffff80bfd315 in ufs_direnter (dvp=3D0xfffff80193c8d588,=20 tvp=3D0xfffff80193effce8, dirp=3D0xfffffe033c22c390, cnp=3D0xfffffe033c= 22c720,=20 newdirbp=3D0xfffffe02d66d7db0, isrename=3D0) at /home/git/head/sys/ufs/ufs/ufs_lookup.c:1133 #68 0xffffffff80c0aaa7 in ufs_mkdir (ap=3D0xfffffe033c22c558) at /home/git/head/sys/ufs/ufs/ufs_vnops.c:1963 #69 0xffffffff80d460fd in VOP_MKDIR_APV (vop=3D0xffffffff810cddd8,=20 a=3D0xfffffe033c22c558) at vnode_if.c:1607 #70 0xffffffff808a5979 in VOP_MKDIR (dvp=3D0xfffff80193c8d588,=20 vpp=3D0xfffffe033c22c6f8, cnp=3D0xfffffe033c22c720, vap=3D0xfffffe033c2= 2c768) at vnode_if.h:665 #71 0xffffffff808a585c in kern_mkdirat (td=3D0xfffff801ad926000, fd=3D-100,= =20 path=3D0x7fffffffe949
,=20 segflg=3DUIO_USERSPACE, mode=3D511) at /home/git/head/sys/kern/vfs_syscalls.c:3747 #72 0xffffffff808a54c3 in sys_mkdir (td=3D0xfffff801ad926000,=20 uap=3D0xfffffe033c22ca58) at /home/git/head/sys/kern/vfs_syscalls.c:3678 #73 0xffffffff80c97044 in syscallenter (td=3D0xfffff801ad926000,=20 sa=3D0xfffffe033c22ca48) at subr_syscall.c:133 #74 0xffffffff80c9694a in amd64_syscall (td=3D0xfffff801ad926000, traced=3D= 0) at /home/git/head/sys/amd64/amd64/trap.c:986 #75 0xffffffff80c6948b in Xfast_syscall () at /home/git/head/sys/amd64/amd64/exception.S:395 #76 0x0000000800946eca in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb)=20 --=20 Have fun! chd From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 10:35:32 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 362D318A; Sat, 24 Jan 2015 10:35:32 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6EC85EC0; Sat, 24 Jan 2015 10:35:31 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0OAZJbj083263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jan 2015 12:35:19 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0OAZJbj083263 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0OAZJFc083262; Sat, 24 Jan 2015 12:35:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 24 Jan 2015 12:35:19 +0200 From: Konstantin Belousov To: Chagin Dmitry Subject: Re: dblfault panic r277611 Message-ID: <20150124103519.GR42409@kib.kiev.ua> References: <20150124094633.GA1804@dchagin.static.corbina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150124094633.GA1804@dchagin.static.corbina.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org, dim@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 10:35:32 -0000 On Sat, Jan 24, 2015 at 12:46:33PM +0300, Chagin Dmitry wrote: > Hi, > > > dchagin.static.corbina.net dumped core - see /var/crash/vmcore.7 > > Sat Jan 24 01:02:20 MSK 2015 > > FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r277611+c41ef74(lemul): Sat Jan 24 00:53:45 MSK 2015 root@dchagin.static.corbina.net:/home/rootobj/home/git/head/sys/YOY amd64 > > panic: double fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > ffs_syncvnode+0x3b0/frame 0xfffffe033c22bd50 > ffs_truncate() at ffs_truncate+0xc6a/frame 0xfffffe033c22c150 > ufs_direnter() at ufs_direnter+0xde5/frame 0xfffffe033c22c280 > ufs_mkdir() at ufs_mkdir+0xb07/frame 0xfffffe033c22c4a0 > > Fatal double fault > rip = 0xffffffff807a8d03 > rsp = 0xfffffe033c228e60 > rbp = 0xfffffe033c229000 > cpuid = 5; apic id = 05 > panic: double fault > cpuid = 5 > KDB: enter: panic > > Reading symbols from /boot/kernel/if_tap.ko.symbols...done. > Loaded symbols for /boot/kernel/if_tap.ko.symbols > Reading symbols from /boot/kernel/if_bridge.ko.symbols...done. > Loaded symbols for /boot/kernel/if_bridge.ko.symbols > Reading symbols from /boot/kernel/bridgestp.ko.symbols...done. > Loaded symbols for /boot/kernel/bridgestp.ko.symbols > Reading symbols from /boot/kernel/usb.ko.symbols...done. > Loaded symbols for /boot/kernel/usb.ko.symbols > Reading symbols from /boot/kernel/xhci.ko.symbols...done. > Loaded symbols for /boot/kernel/xhci.ko.symbols > Reading symbols from /boot/kernel/vmm.ko.symbols...done. > Loaded symbols for /boot/kernel/vmm.ko.symbols > Reading symbols from /boot/kernel/nmdm.ko.symbols...done. > Loaded symbols for /boot/kernel/nmdm.ko.symbols > Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. > Loaded symbols for /boot/kernel/linprocfs.ko.symbols > Reading symbols from /boot/kernel/pseudofs.ko.symbols...done. > Loaded symbols for /boot/kernel/pseudofs.ko.symbols > Reading symbols from /boot/kernel/linux_common.ko.symbols...done. > Loaded symbols for /boot/kernel/linux_common.ko.symbols > Reading symbols from /boot/kernel/procfs.ko.symbols...done. > Loaded symbols for /boot/kernel/procfs.ko.symbols > Reading symbols from /boot/kernel/ukbd.ko.symbols...done. > Loaded symbols for /boot/kernel/ukbd.ko.symbols > Reading symbols from /boot/kernel/ums.ko.symbols...done. > Loaded symbols for /boot/kernel/ums.ko.symbols > #0 doadump (textdump=771179792) > at /home/git/head/sys/kern/kern_shutdown.c:262 > 262 dumptid = curthread->td_tid; > (kgdb) #0 doadump (textdump=771179792) > at /home/git/head/sys/kern/kern_shutdown.c:262 > #1 0xffffffff803c1b08 in db_fncall_generic (addr=-2139713712, > rv=0xfffffe032df744a0, nargs=0, args=0xfffffe032df744b0) > at /home/git/head/sys/ddb/db_command.c:568 > #2 0xffffffff803c17d3 in db_fncall (dummy1=-2185367173664, dummy2=0, > dummy3=0, dummy4=0xfffffe032df745e0 "\n") > at /home/git/head/sys/ddb/db_command.c:616 > #3 0xffffffff803c142b in db_command (last_cmdp=0xffffffff810fd6a8, > cmd_table=0x0, dopager=1) at /home/git/head/sys/ddb/db_command.c:440 > #4 0xffffffff803c0f9d in db_command_loop () > at /home/git/head/sys/ddb/db_command.c:493 > #5 0xffffffff803c58d9 in db_trap (type=3, code=0) > at /home/git/head/sys/ddb/db_main.c:251 > #6 0xffffffff807cc704 in kdb_trap (type=3, code=0, tf=0xfffffe032df74cc0) > at /home/git/head/sys/kern/subr_kdb.c:654 > #7 0xffffffff80c94e1d in trap (frame=0xfffffe032df74cc0) > at /home/git/head/sys/amd64/amd64/trap.c:546 > #8 0xffffffff80c9655f in trap_check (frame=0xfffffe032df74cc0) > at /home/git/head/sys/amd64/amd64/trap.c:645 > #9 0xffffffff80c691a2 in calltrap () > at /home/git/head/sys/amd64/amd64/exception.S:235 > #10 0xffffffff807cbf15 in breakpoint () at cpufunc.h:63 > #11 0xffffffff807cbaff in kdb_enter (why=0xffffffff80dcd635 "panic", > msg=0xffffffff80dcd635 "panic") at /home/git/head/sys/kern/subr_kdb.c:443 > #12 0xffffffff80769768 in vpanic (fmt=0xffffffff80e24597 "double fault", > ap=0xfffffe032df74ec0) at /home/git/head/sys/kern/kern_shutdown.c:740 > #13 0xffffffff80769820 in panic (fmt=0xffffffff80e24597 "double fault") > at /home/git/head/sys/kern/kern_shutdown.c:676 > #14 0xffffffff80c9667d in dblfault_handler (frame=0xfffffe032df74f40) > at /home/git/head/sys/amd64/amd64/trap.c:912 > #15 0xffffffff80c6929c in Xdblfault () > at /home/git/head/sys/amd64/amd64/exception.S:291 > #16 0xffffffff807a8d03 in cpu_search_lowest (cg=Cannot access memory at address 0xfffffe033c228ec8 > ) > at /home/git/head/sys/kern/sched_ule.c:764 > #17 0xffffffff807a9094 in cpu_search_lowest (cg=0xffffffff8128a6e8, > low=0xfffffe033c2292f8) at /home/git/head/sys/kern/sched_ule.c:690 > #18 0xffffffff807a9094 in cpu_search_lowest (cg=0xffffffff8128a6b0, > low=0xfffffe033c229380) at /home/git/head/sys/kern/sched_ule.c:690 > #19 0xffffffff807b0f56 in sched_lowest (cg=0xffffffff8128a6b0, mask= > {__bits = {255, 0, 0, 0}}, pri=121, maxload=2147483647, prefer=5) > at /home/git/head/sys/kern/sched_ule.c:796 > #20 0xffffffff807abcdb in sched_pickcpu (td=0xfffff80009e5a9a0, flags=0) > at /home/git/head/sys/kern/sched_ule.c:1276 > #21 0xffffffff807ace35 in sched_add (td=0xfffff80009e5a9a0, flags=0) > at /home/git/head/sys/kern/sched_ule.c:2395 > #22 0xffffffff807acac9 in sched_wakeup (td=0xfffff80009e5a9a0) > at /home/git/head/sys/kern/sched_ule.c:2029 > #23 0xffffffff8077d6a8 in setrunnable (td=0xfffff80009e5a9a0) > at /home/git/head/sys/kern/kern_synch.c:544 > #24 0xffffffff807e4e98 in sleepq_resume_thread (sq=0xfffff80009e55d80, > td=0xfffff80009e5a9a0, pri=0) > at /home/git/head/sys/kern/subr_sleepqueue.c:776 > #25 0xffffffff807e306a in sleepq_timeout (arg=0xfffff80009e5a9a0) > at /home/git/head/sys/kern/subr_sleepqueue.c:915 > #26 0xffffffff80791b40 in softclock_call_cc (c=0xfffff80009e5ad38, > cc=0xffffffff813a4200, direct=1) > at /home/git/head/sys/kern/kern_timeout.c:724 > #27 0xffffffff807913bd in callout_process (now=740683739317) > at /home/git/head/sys/kern/kern_timeout.c:499 > #28 0xffffffff80ce346a in handleevents (now=740683739317, fake=0) > at /home/git/head/sys/kern/kern_clocksource.c:212 > #29 0xffffffff80ce3fd6 in timercb (et=0xffffffff8137df68, arg=0x0) > at /home/git/head/sys/kern/kern_clocksource.c:345 > #30 0xffffffff80d376e3 in lapic_handle_timer (frame=0xfffffe033c229c50) > at /home/git/head/sys/x86/x86/local_apic.c:883 > #31 0xffffffff80c69cfc in Xtimerint () at apic_vector.S:109 > #32 0xffffffff80c745ef in write_rflags (rf=642) at cpufunc.h:382 > #33 0xffffffff80c6f225 in intr_restore (rflags=642) at cpufunc.h:775 > #34 0xffffffff80c71ce8 in spinlock_exit () > at /home/git/head/sys/amd64/amd64/machdep.c:2177 > #35 0xffffffff8074335c in __mtx_unlock_spin_flags (c=0xffffffff8119ec80, > opts=0, file=0xffffffff80dc3d2b "/home/git/head/sys/kern/kern_cons.c", > line=530) at /home/git/head/sys/kern/kern_mutex.c:305 > #36 0xffffffff806df9fc in cnputs (p=0xfffffe033c22a402 "\"<\003þÿÿ") > at /home/git/head/sys/kern/kern_cons.c:530 > #37 0xffffffff807d76ae in putbuf (c=10, ap=0xfffffe033c22a3b8) > at /home/git/head/sys/kern/subr_prf.c:427 > #38 0xffffffff807d60d6 in putchar (c=10, arg=0xfffffe033c22a3b8) > at /home/git/head/sys/kern/subr_prf.c:471 > #39 0xffffffff807d43e3 in kvprintf (fmt=0xffffffff80d77b33 "", > func=0xffffffff807d6010 , arg=0xfffffe033c22a3b8, radix=10, > ap=0xfffffe033c22a510) at /home/git/head/sys/kern/subr_prf.c:720 > #40 0xffffffff807d6569 in _vprintf (level=-1, flags=5, > fmt=0xffffffff80d77b31 "%c", ap=0xfffffe033c22a510) > at /home/git/head/sys/kern/subr_prf.c:271 > #41 0xffffffff807d68dd in vprintf (fmt=0xffffffff80d77b31 "%c", > ap=0xfffffe033c22a510) at /home/git/head/sys/kern/subr_prf.c:388 > #42 0xffffffff807d689b in printf (fmt=0xffffffff80d77b31 "%c") > at /home/git/head/sys/kern/subr_prf.c:377 > #43 0xffffffff803c5d55 in db_putc (c=10) > at /home/git/head/sys/ddb/db_output.c:156 > #44 0xffffffff803c5b21 in db_putchar (c=10, arg=0xfffffe033c22aad8) > at /home/git/head/sys/ddb/db_output.c:128 > #45 0xffffffff807d3b65 in kvprintf (fmt=0xffffffff80d8090f "", > func=0xffffffff803c5af0 , arg=0xfffffe033c22aad8, radix=16, > ap=0xfffffe033c22aac0) at /home/git/head/sys/kern/subr_prf.c:645 > #46 0xffffffff803c5ad8 in db_printf (fmt=0xffffffff80d8090e "\n") > at /home/git/head/sys/ddb/db_output.c:340 > #47 0xffffffff80c67f73 in db_print_stack_entry ( > name=0xffffffff815c8262 "ufs_mkdir", narg=0, argnp=0x0, > argp=0xfffffe033c22c4b0, callpc=18446744071574694567, > frame=0xfffffe033c22c4a0) at /home/git/head/sys/amd64/amd64/db_trace.c:260 > #48 0xffffffff80c66f3b in db_backtrace (td=0xfffff801ad926000, tf=0x0, > frame=0xfffffe033c22c4a0, pc=18446744071574694567, count=1005) > at /home/git/head/sys/amd64/amd64/db_trace.c:462 > #49 0xffffffff80c66bdf in db_trace_self () > at /home/git/head/sys/amd64/amd64/db_trace.c:498 > #50 0xffffffff803c568e in db_trace_self_wrapper () > at /home/git/head/sys/ddb/db_main.c:268 > #51 0xffffffff807cbcd8 in kdb_backtrace () > at /home/git/head/sys/kern/subr_kdb.c:370 > #52 0xffffffff807fe924 in _witness_debugger (cond=1, > msg=0xffffffff80dd6e29 "witness_checkorder") > at /home/git/head/sys/kern/subr_witness.c:2904 > #53 0xffffffff807fe2de in witness_checkorder (lock=0xfffff80193effd50, > flags=9, file=0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", > line=2164, interlock=0xfffff80193effd80) > at /home/git/head/sys/kern/subr_witness.c:1365 > #54 0xffffffff80730d65 in __lockmgr_args (lk=0xfffff80193effd50, > flags=524544, ilk=0xfffff80193effd80, wmesg=0x0, pri=0, timo=0, > file=0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=2164) > at /home/git/head/sys/kern/kern_lock.c:756 > #55 0xffffffff80bf1438 in _lockmgr_args (lk=0xfffff80193effd50, flags=524544, > ilk=0xfffff80193effd80, wmesg=0x0, prio=0, timo=0, > file=0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=2164) > at lockmgr.h:98 > #56 0xffffffff80bef677 in ffs_lock (ap=0xfffffe033c22b7c8) > at /home/git/head/sys/ufs/ffs/ffs_vnops.c:385 > #57 0xffffffff80d47cd4 in VOP_LOCK1_APV (vop=0xffffffff810cd328, > a=0xfffffe033c22b7c8) at vnode_if.c:2082 > #58 0xffffffff808ac2f3 in VOP_LOCK1 (vp=0xfffff80193effce8, flags=524544, > file=0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=2164) > at vnode_if.h:859 > #59 0xffffffff808aa122 in _vn_lock (vp=0xfffff80193effce8, flags=524544, > file=0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=2164) > at /home/git/head/sys/kern/vfs_vnops.c:1531 > #60 0xffffffff8088d636 in vget (vp=0xfffff80193effce8, flags=524544, > td=0xfffff801ad926000) at /home/git/head/sys/kern/vfs_subr.c:2164 > #61 0xffffffff8087884f in vfs_hash_get (mp=0xfffff80009db2000, hash=71269052, > flags=524288, td=0xfffff801ad926000, vpp=0xfffffe033c22bb40, fn=0, > arg=0x0) at /home/git/head/sys/kern/vfs_hash.c:89 > #62 0xffffffff80be7969 in ffs_vgetf (mp=0xfffff80009db2000, ino=71269052, > flags=524288, vpp=0xfffffe033c22bb40, ffs_flags=1) > at /home/git/head/sys/ufs/ffs/ffs_vfsops.c:1636 > #63 0xffffffff80bd1d02 in flush_pagedep_deps (pvp=0xfffff80193c8d588, > mp=0xfffff80009db2000, diraddhdp=0xfffff80193769b58) > at /home/git/head/sys/ufs/ffs/ffs_softdep.c:12929 > #64 0xffffffff80bd182c in softdep_sync_buf (vp=0xfffff80193c8d588, > bp=0xfffffe02d6a8d6d0, waitfor=1) > at /home/git/head/sys/ufs/ffs/ffs_softdep.c:12621 > #65 0xffffffff80bf0d40 in ffs_syncvnode (vp=0xfffff80193c8d588, waitfor=1, > flags=0) at /home/git/head/sys/ufs/ffs/ffs_vnops.c:280 > #66 0xffffffff80babd9a in ffs_truncate (vp=0xfffff80193c8d588, length=512, > flags=2176, cred=0xfffff80009c52b00) > at /home/git/head/sys/ufs/ffs/ffs_inode.c:339 > #67 0xffffffff80bfd315 in ufs_direnter (dvp=0xfffff80193c8d588, > tvp=0xfffff80193effce8, dirp=0xfffffe033c22c390, cnp=0xfffffe033c22c720, > newdirbp=0xfffffe02d66d7db0, isrename=0) > at /home/git/head/sys/ufs/ufs/ufs_lookup.c:1133 > #68 0xffffffff80c0aaa7 in ufs_mkdir (ap=0xfffffe033c22c558) > at /home/git/head/sys/ufs/ufs/ufs_vnops.c:1963 > #69 0xffffffff80d460fd in VOP_MKDIR_APV (vop=0xffffffff810cddd8, > a=0xfffffe033c22c558) at vnode_if.c:1607 > #70 0xffffffff808a5979 in VOP_MKDIR (dvp=0xfffff80193c8d588, > vpp=0xfffffe033c22c6f8, cnp=0xfffffe033c22c720, vap=0xfffffe033c22c768) > at vnode_if.h:665 > #71 0xffffffff808a585c in kern_mkdirat (td=0xfffff801ad926000, fd=-100, > path=0x7fffffffe949
, > segflg=UIO_USERSPACE, mode=511) > at /home/git/head/sys/kern/vfs_syscalls.c:3747 > #72 0xffffffff808a54c3 in sys_mkdir (td=0xfffff801ad926000, > uap=0xfffffe033c22ca58) at /home/git/head/sys/kern/vfs_syscalls.c:3678 > #73 0xffffffff80c97044 in syscallenter (td=0xfffff801ad926000, > sa=0xfffffe033c22ca48) at subr_syscall.c:133 > #74 0xffffffff80c9694a in amd64_syscall (td=0xfffff801ad926000, traced=0) > at /home/git/head/sys/amd64/amd64/trap.c:986 > #75 0xffffffff80c6948b in Xfast_syscall () > at /home/git/head/sys/amd64/amd64/exception.S:395 > #76 0x0000000800946eca in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > This is fun, for some definition of it. The process was in the guts of VFS from mkdir(2) syscall, witness triggered printing of the warning for dreaded buf->hashdir->buf non-real LOR. From the ddb stack backtrace routine, when cnputs released the console spinlock yet another time, timer interrupt fired and started proceeding callouts. One of the callout triggered and needs to wake up a thread sleeping with timeout. There, inside the scheduler, cpu_search_lowest() was called, recursed twice and finally overflown the stack. Is this yet another clang regression ? The cpu_search_lowest() saga seems to never end. r268211 is uneffective, probably after clang 3.5 import. From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 12:50:13 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB11E3A4 for ; Sat, 24 Jan 2015 12:50:13 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 939B6C7F for ; Sat, 24 Jan 2015 12:50:13 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1YF0A7-003sgr-Me>; Sat, 24 Jan 2015 13:50:03 +0100 Received: from f052130104.adsl.alicedsl.de ([78.52.130.104] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1YF0A7-0029YJ-Jz>; Sat, 24 Jan 2015 13:50:03 +0100 Date: Sat, 24 Jan 2015 13:49:58 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: [CURRENT] r277641 fails to installworld: routing_test: No such file or directory Message-ID: <20150124134958.20f0a70b.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/2UkO1npPCTXQlO95JQKQ92P"; protocol="application/pgp-signature" X-Originating-IP: 78.52.130.104 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 12:50:13 -0000 --Sig_/2UkO1npPCTXQlO95JQKQ92P Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Most recent sources fail to install with the error below. CURRENT is amd64 = and at r277641: =3D=3D=3D> etc/tests/rc.d (install) install -o root -g wheel -m 555 routing_test /usr/tests/etc/rc.d/routing= _test install: /usr/tests/etc/rc.d/routing_test: No such file or directory *** Error code 71 Regards, O. Hartmann --Sig_/2UkO1npPCTXQlO95JQKQ92P Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUw5T2AAoJEOgBcD7A/5N8EIcH/jKMuU9PckjesQ3+pKXZcinz Hmxi2bSHmgH45470DyYu//Vg8UK0FRJ50K4/TTnkdykkvZwcbWHld5t9mXERQMAW RaPHIioyIhq/ROdLA/HMh0vQXLVJT7qpFVxtOx1rZy+wyiP2sEykkXuKn4pyY/ox JLkw5aOHvjqJ+qWJQRmokOEjK29GUCNK+EpYBmruZ8hXMP2V7rnPM+SeuOMJp5xw MC2pgYzvmbdb44B3JTKgqCQl9fPbVzSLM4h4YycsgAvmrvbZSHZndohLmjFnBhQ5 MxvOAnh/XFDK2h7u28EkAsiQczy+GyTmfT3BKutsucr6DdISZmbymBjFxohFnhM= =Mqie -----END PGP SIGNATURE----- --Sig_/2UkO1npPCTXQlO95JQKQ92P-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 12:54:55 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7480B659 for ; Sat, 24 Jan 2015 12:54:55 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 33187D42 for ; Sat, 24 Jan 2015 12:54:54 +0000 (UTC) Received: from [93.104.18.206] (helo=c720-r276659) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YF0Ef-0005nf-Kt; Sat, 24 Jan 2015 13:54:45 +0100 Date: Sat, 24 Jan 2015 13:54:43 +0100 From: Matthias Apitz To: "O. Hartmann" Subject: Re: [CURRENT] r277641 fails to installworld: routing_test: No such file or directory Message-ID: <20150124125443.GA2297@c720-r276659> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , "O. Hartmann" , FreeBSD CURRENT References: <20150124134958.20f0a70b.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150124134958.20f0a70b.ohartman@zedat.fu-berlin.de> X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.18.206 Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 12:54:55 -0000 El día Saturday, January 24, 2015 a las 01:49:58PM +0100, O. Hartmann escribió: > Most recent sources fail to install with the error below. CURRENT is amd64 and at r277641: > > > ===> etc/tests/rc.d (install) > install -o root -g wheel -m 555 routing_test /usr/tests/etc/rc.d/routing_test > install: /usr/tests/etc/rc.d/routing_test: No such file or directory > *** Error code 71 I'm facing right now (13:52 CET) the same with creating the jail for poudriere with poudriere jail -c -j freebsd-head -m svn+http -v head after 2 hours all is rolled back :-( not even the checked out tree is left :-( matthias -- Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 13:20:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9B789C3 for ; Sat, 24 Jan 2015 13:20:12 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63698EFE for ; Sat, 24 Jan 2015 13:20:12 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0ODK6GK019553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jan 2015 15:20:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0ODK6GK019553 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0ODK6LI019550; Sat, 24 Jan 2015 15:20:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 24 Jan 2015 15:20:05 +0200 From: Konstantin Belousov To: Steve Kargl Subject: Re: panic in pmap_remove_pages() Message-ID: <20150124132005.GU42409@kib.kiev.ua> References: <20150121214706.GA912@troutmask.apl.washington.edu> <20150123105100.GH42409@kib.kiev.ua> <20150123155808.GA36783@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150123155808.GA36783@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 13:20:12 -0000 On Fri, Jan 23, 2015 at 07:58:08AM -0800, Steve Kargl wrote: > On Fri, Jan 23, 2015 at 12:51:00PM +0200, Konstantin Belousov wrote: > > On Wed, Jan 21, 2015 at 01:47:06PM -0800, Steve Kargl wrote: > > > Fatal trap 9: general protection fault while in kernel mode > > > cpuid = 3; apic id = 13 > > > instruction pointer = 0x20:0xffffffff8079abf9 > > > stack pointer = 0x28:0xfffffe047325e360 > > > frame pointer = 0x28:0xfffffe047325e440 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 41779 (z) > > > trap number = 9 > > > panic: general protection fault > > > cpuid = 3 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe047325e020 > > > panic() at panic+0x1c1/frame 0xfffffe047325e0e0 > > > trap_fatal() at trap_fatal+0x396/frame 0xfffffe047325e140 > > > trap() at trap+0x6ce/frame 0xfffffe047325e2a0 > > > calltrap() at calltrap+0x8/frame 0xfffffe047325e2a0 > > > --- trap 0x9, rip = 0xffffffff8079abf9, rsp = 0xfffffe047325e360, rbp = 0xfffffe047325e440 --- > > > pmap_remove_pages() at pmap_remove_pages+0x539/frame 0xfffffe047325e440 > > > exec_new_vmspace() at exec_new_vmspace+0x180/frame 0xfffffe047325e4a0 > > > exec_elf64_imgact() at exec_elf64_imgact+0x6c0/frame 0xfffffe047325e570 > > > kern_execve() at kern_execve+0x484/frame 0xfffffe047325e8c0 > > > sys_execve() at sys_execve+0x35/frame 0xfffffe047325e920 > > > amd64_syscall() at amd64_syscall+0x289/frame 0xfffffe047325ea30 > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe047325ea30 > > > --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x4251ba, rsp = 0x7ffffe8ebab8, rbp = 0x7ffffe8ec1c0 --- > > > Uptime: 22d22h22m46s > > > > > > #0 doadump (textdump=1) at pcpu.h:219 > > > 219 pcpu.h: No such file or directory. > > > in pcpu.h > > > (kgdb) #0 doadump (textdump=1) at pcpu.h:219 > > > #1 0xffffffff80555bd7 in kern_reboot (howto=260) > > > at /usr/src/sys/kern/kern_shutdown.c:447 > > > #2 0xffffffff80556040 in panic (fmt=) > > > at /usr/src/sys/kern/kern_shutdown.c:746 > > > #3 0xffffffff807a2986 in trap_fatal (frame=, > > > eva=) at /usr/src/sys/amd64/amd64/trap.c:867 > > > #4 0xffffffff807a25de in trap (frame=) > > > at /usr/src/sys/amd64/amd64/trap.c:201 > > > #5 0xffffffff80787ca3 in calltrap () > > > at /usr/src/sys/amd64/amd64/exception.S:235 > > > #6 0xffffffff8079abf9 in pmap_remove_pages (pmap=0xfffff801c627dec8) > > > at /usr/src/sys/amd64/amd64/pmap.c:5389 > > Please do 'frame 6' and from there, do 'p *m'. Is it reproducable ? > > > > (kgdb) p *m > $9 = {plinks = {q = {tqe_next = 0xfffff804384044c0, > tqe_prev = 0xfffff8042e89eac0}, s = {ss = { > sle_next = 0xfffff804384044c0}, pv = 0xfffff8042e89eac0}, memguard = { > p = 18446735295740134592, v = 18446735295577189056}}, listq = { > tqe_next = 0xfffff8043cddb158, tqe_prev = 0xfffff804335c2358}, > object = 0xfffff801882d5100, pindex = 30, phys_addr = 4352778240, md = { > pv_list = {tqh_first = 0xfffff800bc1d37a8, tqh_last = 0xfefff800bc1d37b0}, The tqh_last has single-bit error, note the 0xf_e_fff8... pattern of the pv_list.tqh_last value. It is consistent with the general protection fault which was reported, amd64 reacts this way to the non-canonical address. It is theoretically possible that some random memory corruption occured, but I tend to believe that hardware bit-flipping took place. > pv_gen = 1012, pat_mode = 6}, wire_count = 0, busy_lock = 1, > hold_count = 0, flags = 0, aflags = 1 '\001', oflags = 0 '\0', > queue = 1 '\001', psind = 0 '\0', segind = 7 '\a', order = 13 '\r', > pool = 0 '\0', act_count = 5 '\005', valid = 255 '?', dirty = 255 '?'} > > It would have been reproducible except that the panic truncated > the program 'z' (which caused the panic) to 0 bytes and took the > source code I was writing. Neither 'z' nor the source code appeared > in /usr/lost+found. Unfortunately, the source code was a quickly > written Fortran program with obviously a programming error, and I > doubt that I'll be able to replicate the program. > > -- > Steve From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 14:04:04 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCA95383 for ; Sat, 24 Jan 2015 14:04:03 +0000 (UTC) Received: from smtpout7.timeweb.ru (smtpout7.timeweb.ru [92.53.117.21]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C1D7395 for ; Sat, 24 Jan 2015 14:04:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=amdmi3.ru; s=dkim; h=Content-Transfer-Encoding:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=6olAYncOC419Jlfsu8wqIG/mNnr9fn1S2jRQx2Umeis=; b=VVOTQxkXhyRVv4MoTjPU8/7KRhwu4hMXrbt1MvC5sQLtQpfivYK0Me60rxS8pTIanmrj406W9qr7fY9Yn363BYxs6AAFTuQwUOy1lgrXkqQ4sJmUbj0d53N9s3ve8UWTh7xtxF+aKkwsmNM1qmJ6jO2w3XrywMJpHBLM10lVsAk=; Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YF1Jf-0000Jo-S3; Sat, 24 Jan 2015 17:03:59 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 8614F56C; Sat, 24 Jan 2015 17:03:24 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 79B2F1283E; Sat, 24 Jan 2015 17:03:40 +0300 (MSK) Date: Sat, 24 Jan 2015 17:03:40 +0300 From: Dmitry Marakasov To: Garrett Cooper Subject: Re: OptionalObsoleteFiles.inc completeness improvement, try 2 Message-ID: <20150124140340.GL1101@hades.panopticon> References: <20150124002956.GI1101@hades.panopticon> <4F0C24D1-9313-49BC-992E-5C31DAC6DADC@gmail.com> <20150124011610.GJ1101@hades.panopticon> <8162C656-E851-492D-840A-27A222E3A7CC@gmail.com> <8D1D9451-B8B1-4121-8F89-E03951DB65BF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8D1D9451-B8B1-4121-8F89-E03951DB65BF@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 14:04:04 -0000 * Garrett Cooper (yaneurabeya@gmail.com) wrote: > >>> Hi Dmitry, > >>> Seems like we=E2=80=99ve duplicated work a bit. Have you looked at= ^/projects/building-blocks yet ? > >>=20 > >> Hm, seems so, partly. How do you gather missing entries? My way is > >> pretty dumb, I just do bunch of installworlds + delete-old's and add > >> diff to the file, you probably do it more cleverly. Will committing > >> my changes interfere with your work? If so, it may be better to dire= ct > >> them to your branch instead. Especially if you are more aware of kno= b > >> combinations and their effects. > >=20 > > I wrote this script to track what files get installed by directories:= =20 > > https://svnweb.freebsd.org/base/projects/building-blocks/tools/add-op= tional-obsolete-files-entries.sh?revision=3D275238&view=3Dmarkup . It=E2=80= =99s not perfect (doesn=E2=80=99t work for =E2=80=9Ckitchen sink=E2=80=9D= directories like etc/ and share/=E2=80=A6), but it=E2=80=99s a reasonabl= e starting point for grabbing all of the files. > >=20 > > I=E2=80=99m going to hold off on the rc.d deletions/rewrites for depe= ndent services after I do more targeted review/testing, as it might screw= up boot order in unexpected ways with services and programs that get run= out of order, but I=E2=80=99m reasonably confident that the contents of = the branch work. > >=20 > > I was going to start cherry-picking changes from the branch this week= end. >=20 > Forgot to respond on one important point: reviewing and committing the = higher-level changes (make remove-old) shouldn=E2=80=99t be a problem, an= d I=E2=80=99ll be sure to commit the overlapping changes with OptionalObs= oleteFiles.inc first to reduce the diff between our branches. > Thanks! Okay, the I'll just go on. Nice to know it's useful. Note that the branch may have bugs as on the first run I just extend it, and it's tested on another run, while run takes couple of days on the box I use. --=20 Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 14:08:36 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80EAC53F for ; Sat, 24 Jan 2015 14:08:36 +0000 (UTC) Received: from smtpout7.timeweb.ru (smtpout7.timeweb.ru [92.53.117.21]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34FFC3DE for ; Sat, 24 Jan 2015 14:08:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=amdmi3.ru; s=dkim; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=SAo1aNiupeVW4wd0rpMchJsMuA/qMbqIgsbLAs/1ZXg=; b=d/LvIKV/UzeHx+HfVNzmVvBfYoLVtwJq8HvDfuGLtXq38PFj5MiK4DI5kzU6Tnu4FT35WpTPsWltcpnFKnCfNi+KnhZbSPQfUvnfdGnA6v+sUcXTaT3KRN6hwZQB1PPRbbnKy3VmzKVoN/oilkPFafwmqn7ejhC7yNl60Mj2M+g=; Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YF1O6-0002p5-59 for freebsd-current@FreeBSD.org; Sat, 24 Jan 2015 17:08:34 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id E4B1A56D for ; Sat, 24 Jan 2015 17:07:58 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id D5FFE12840; Sat, 24 Jan 2015 17:08:14 +0300 (MSK) Date: Sat, 24 Jan 2015 17:08:14 +0300 From: Dmitry Marakasov To: freebsd-current@FreeBSD.org Subject: Re: OptionalObsoleteFiles.inc completeness improvement, try 2 Message-ID: <20150124140814.GM1101@hades.panopticon> References: <20150124002956.GI1101@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150124002956.GI1101@hades.panopticon> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 14:08:36 -0000 * Dmitry Marakasov (amdmi3@hades.panopticon) wrote: > Also there is a question of delete-old-dirs removing directories > which are created by mtree run by installworld unconditionally. > This seems to be incorrect - either directories should be installed > conditionally or not removed by delete-old-dirs. My patch will > address this issue as well, by not remiving unconditionally installed > dirs. I'd really like to hear opinions on this. Another issue is conditional lib32 files: .if ${MK_ATM} == no ... .if ${TARGET_ARCH} == "amd64" || ${TARGET_ARCH} == "powerpc64" ... .endif ... .endif I think that this may be simplified by dropping internal condition - it won't change behavior for end-user. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 14:22:27 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B74D36FD for ; Sat, 24 Jan 2015 14:22:27 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A3715790 for ; Sat, 24 Jan 2015 14:22:27 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8A759185E for ; Sat, 24 Jan 2015 14:22:28 +0000 (UTC) Date: Sat, 24 Jan 2015 14:22:28 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <611660663.2.1422109348533.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #937 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 14:22:27 -0000 See ------------------------------------------ [...truncated 20278 lines...] install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 555 15 install -o root -g wheel -m 555 16 install -o root -g wheel -m 555 17 install -o root -g wheel -m 555 18 install -o root -g wheel -m 555 19 install -o root -g wheel -m 555 20 install -o root -g wheel -m 555 21 install -o root -g wheel -m 555 22 install -o root -g wheel -m 555 23 install -o root -g wheel -m 555 24 ===> tests/sys/pjdfstest/tests/rename (install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 555 15 install -o root -g wheel -m 555 16 install -o root -g wheel -m 555 17 install -o root -g wheel -m 555 18 install -o root -g wheel -m 555 19 install -o root -g wheel -m 555 20 install -o root -g wheel -m 555 21 install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/rename && make -f /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/rename/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 555 15 install -o root -g wheel -m 555 16 install -o root -g wheel -m 555 17 install -o root -g wheel -m 555 18 install -o root -g wheel -m 555 19 install -o root -g wheel -m 555 20 install -o root -g wheel -m 555 21 ===> tests/sys/pjdfstest/tests/rmdir (install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 555 15 install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/rmdir && make -f /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/rmdir/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 555 15 ===> tests/sys/pjdfstest/tests/symlink (install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/symlink && make -f /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/symlink/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 ===> tests/sys/pjdfstest/tests/truncate (install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/truncate && make -f /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/truncate/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 ===> tests/sys/pjdfstest/tests/unlink (install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/unlink && make -f /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/unlink/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/conf misc.sh rm -f install -l s . ===> tests/sys/kern (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/kern && make -f /builds/FreeBSD_HEAD/tests/sys/kern/Makefile _RECURSING_PROGS= SUBDIR= PROG=kern_descrip_test DEPENDFILE=.depend.kern_descrip_test .MAKE.DEPENDFILE=.depend.kern_descrip_test install) install -s -o root -g wheel -m 555 kern_descrip_test (cd /builds/FreeBSD_HEAD/tests/sys/kern && make -f /builds/FreeBSD_HEAD/tests/sys/kern/Makefile _RECURSING_PROGS= SUBDIR= PROG=unix_seqpacket_test DEPENDFILE=.depend.unix_seqpacket_test .MAKE.DEPENDFILE=.depend.unix_seqpacket_test install) install -s -o root -g wheel -m 555 unix_seqpacket_test ===> tests/sys/netinet (install) install -o root -g wheel -m 555 fibs_test install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/netinet && make -f /builds/FreeBSD_HEAD/tests/sys/netinet/Makefile _RECURSING_PROGS= SUBDIR= PROG=udp_dontroute DEPENDFILE=.depend.udp_dontroute .MAKE.DEPENDFILE=.depend.udp_dontroute install) install -s -o root -g wheel -m 555 udp_dontroute install -o root -g wheel -m 555 fibs_test ===> tests/sys/opencrypto (install) install -o root -g wheel -m 555 runtests install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/tests/sys/opencrypto/cryptodev.py /builds/FreeBSD_HEAD/tests/sys/opencrypto/cryptodevh.py /builds/FreeBSD_HEAD/tests/sys/opencrypto/cryptotest.py /builds/FreeBSD_HEAD/tests/sys/opencrypto/dpkt.py (cd /builds/FreeBSD_HEAD/tests/sys/opencrypto && make -f /builds/FreeBSD_HEAD/tests/sys/opencrypto/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 runtests install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/tests/Kyuafile install -l s ../local/tests ===> etc (install) ===> etc/newsyslog.conf.d (install) ===> etc/sendmail (install) ===> etc/tests (install) ===> etc/tests/rc.d (install) install -o root -g wheel -m 555 routing_test install: : No such file or directory *** Error code 71 Stop. make[6]: stopped in /builds/FreeBSD_HEAD/etc/tests/rc.d *** Error code 1 Stop. make[5]: stopped in /builds/FreeBSD_HEAD/etc/tests *** Error code 1 Stop. make[4]: stopped in /builds/FreeBSD_HEAD/etc *** Error code 1 Stop. make[3]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[2]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 16:42:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 240FA2F2 for ; Sat, 24 Jan 2015 16:42:42 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2234399 for ; Sat, 24 Jan 2015 16:42:41 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id hl2so2318686igb.3 for ; Sat, 24 Jan 2015 08:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=bIpHwAlASKPP49DHZowldS9WklA0cp4QbXJU9ED80cI=; b=JOi5Dz1IQHVgarGwRAqPvuN32fSHWIV8+p412xR8qYkgvz2KjPShFvX3uzkLRM0cjD rE4UIW8siwTr4bQTI1ygHFZoKUjcGBO3D8bpDutbquhjlhEDdzSthrFcFo5uPhlVIvaW 9hGAA30aBY9rNdquKipcvLWglEnLFByloskyZrVQpk+PteEa0G0zDS9tjc4llHQW7HBX ou+dFIELVv24tLw2+Ovvk6IBd2duPnLIgi453AZ0vKeUOVAwL3P2yYwAj+S+xTOyduzP /oRZA6rTYVKrsYWnjuC3r/q/Bs0PIgtGWCgGlcrfj36mtWd3/u2GmDfxnmDNlxr83n7J POIw== MIME-Version: 1.0 X-Received: by 10.107.169.222 with SMTP id f91mr9759247ioj.88.1422117761249; Sat, 24 Jan 2015 08:42:41 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Sat, 24 Jan 2015 08:42:41 -0800 (PST) Date: Sat, 24 Jan 2015 08:42:41 -0800 X-Google-Sender-Auth: ANGALuve8rxhBoWUAaJeANBpWQQ Message-ID: Subject: install: /usr/tests/etc/rc.d/routing_test: No such file or directory From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 16:42:42 -0000 I just updated a box: ===> etc/tests/rc.d (install) install -o root -g wheel -m 555 routing_test /usr/tests/etc/rc.d/routing_test install: /usr/tests/etc/rc.d/routing_test: No such file or directory *** Error code 71 .. did someone forget an mtree? -a From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 16:59:24 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BDE5628 for ; Sat, 24 Jan 2015 16:59:24 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7CDFB6A6 for ; Sat, 24 Jan 2015 16:59:24 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id CF0AB1DD6 for ; Sat, 24 Jan 2015 16:59:24 +0000 (UTC) Date: Sat, 24 Jan 2015 16:59:24 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <922776149.3.1422118764819.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <611660663.2.1422109348533.JavaMail.jenkins@jenkins-9.freebsd.org> References: <611660663.2.1422109348533.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #938 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 16:59:24 -0000 See ------------------------------------------ [...truncated 20278 lines...] install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 555 15 install -o root -g wheel -m 555 16 install -o root -g wheel -m 555 17 install -o root -g wheel -m 555 18 install -o root -g wheel -m 555 19 install -o root -g wheel -m 555 20 install -o root -g wheel -m 555 21 install -o root -g wheel -m 555 22 install -o root -g wheel -m 555 23 install -o root -g wheel -m 555 24 ===> tests/sys/pjdfstest/tests/rename (install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 555 15 install -o root -g wheel -m 555 16 install -o root -g wheel -m 555 17 install -o root -g wheel -m 555 18 install -o root -g wheel -m 555 19 install -o root -g wheel -m 555 20 install -o root -g wheel -m 555 21 install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/rename && make -f /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/rename/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 555 15 install -o root -g wheel -m 555 16 install -o root -g wheel -m 555 17 install -o root -g wheel -m 555 18 install -o root -g wheel -m 555 19 install -o root -g wheel -m 555 20 install -o root -g wheel -m 555 21 ===> tests/sys/pjdfstest/tests/rmdir (install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 555 15 install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/rmdir && make -f /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/rmdir/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 555 15 ===> tests/sys/pjdfstest/tests/symlink (install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/symlink && make -f /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/symlink/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 ===> tests/sys/pjdfstest/tests/truncate (install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/truncate && make -f /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/truncate/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 555 14 ===> tests/sys/pjdfstest/tests/unlink (install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/unlink && make -f /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/unlink/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 00 install -o root -g wheel -m 555 01 install -o root -g wheel -m 555 02 install -o root -g wheel -m 555 03 install -o root -g wheel -m 555 04 install -o root -g wheel -m 555 05 install -o root -g wheel -m 555 06 install -o root -g wheel -m 555 07 install -o root -g wheel -m 555 08 install -o root -g wheel -m 555 09 install -o root -g wheel -m 555 10 install -o root -g wheel -m 555 11 install -o root -g wheel -m 555 12 install -o root -g wheel -m 555 13 install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/tests/sys/pjdfstest/tests/conf misc.sh rm -f install -l s . ===> tests/sys/kern (install) install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/kern && make -f /builds/FreeBSD_HEAD/tests/sys/kern/Makefile _RECURSING_PROGS= SUBDIR= PROG=kern_descrip_test DEPENDFILE=.depend.kern_descrip_test .MAKE.DEPENDFILE=.depend.kern_descrip_test install) install -s -o root -g wheel -m 555 kern_descrip_test (cd /builds/FreeBSD_HEAD/tests/sys/kern && make -f /builds/FreeBSD_HEAD/tests/sys/kern/Makefile _RECURSING_PROGS= SUBDIR= PROG=unix_seqpacket_test DEPENDFILE=.depend.unix_seqpacket_test .MAKE.DEPENDFILE=.depend.unix_seqpacket_test install) install -s -o root -g wheel -m 555 unix_seqpacket_test ===> tests/sys/netinet (install) install -o root -g wheel -m 555 fibs_test install -o root -g wheel -m 444 Kyuafile.auto (cd /builds/FreeBSD_HEAD/tests/sys/netinet && make -f /builds/FreeBSD_HEAD/tests/sys/netinet/Makefile _RECURSING_PROGS= SUBDIR= PROG=udp_dontroute DEPENDFILE=.depend.udp_dontroute .MAKE.DEPENDFILE=.depend.udp_dontroute install) install -s -o root -g wheel -m 555 udp_dontroute install -o root -g wheel -m 555 fibs_test ===> tests/sys/opencrypto (install) install -o root -g wheel -m 555 runtests install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/tests/sys/opencrypto/cryptodev.py /builds/FreeBSD_HEAD/tests/sys/opencrypto/cryptodevh.py /builds/FreeBSD_HEAD/tests/sys/opencrypto/cryptotest.py /builds/FreeBSD_HEAD/tests/sys/opencrypto/dpkt.py (cd /builds/FreeBSD_HEAD/tests/sys/opencrypto && make -f /builds/FreeBSD_HEAD/tests/sys/opencrypto/Makefile SUBDIR= _RECURSING_PROGS= install) install -o root -g wheel -m 555 runtests install -o root -g wheel -m 444 Kyuafile.auto install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/tests/Kyuafile install -l s ../local/tests ===> etc (install) ===> etc/newsyslog.conf.d (install) ===> etc/sendmail (install) ===> etc/tests (install) ===> etc/tests/rc.d (install) install -o root -g wheel -m 555 routing_test install: : No such file or directory *** Error code 71 Stop. make[6]: stopped in /builds/FreeBSD_HEAD/etc/tests/rc.d *** Error code 1 Stop. make[5]: stopped in /builds/FreeBSD_HEAD/etc/tests *** Error code 1 Stop. make[4]: stopped in /builds/FreeBSD_HEAD/etc *** Error code 1 Stop. make[3]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[2]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 17:44:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01A51EFA for ; Sat, 24 Jan 2015 17:44:11 +0000 (UTC) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD57EB25 for ; Sat, 24 Jan 2015 17:44:11 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id a13so2467928igq.0 for ; Sat, 24 Jan 2015 09:44:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=gT+ZQninYnFE48FIKjN86KSpPD4JvLFKY9ad4cJKWcc=; b=hsKIcNHJCgCP8HRGTz83Jt1nmIQDKT2jIdg+V1GOGUqWtRyPlfjyHTNycqK8+Kyl79 XBb6n7ICp9o2Chm2m8xE7pGWaEJbdQ96EmkQvQKQcPaSkC8HxEVEs5e75jMcsTD3smUC 7/cHJPi1uj6gMgA9FikbLtrfsKrhxbDv8qxasxNsXRTFuc59NoMRGrTg+BdyVW9HQMlc e0cDiIetQx9PJNTRHBBj+dFuZeYwkwFiVE3npc5MXSOlNQtAE7RyqUZpeeC549ZF9l16 0BKdAFU60UoaiV3H8tJN247nh6w0CQzPJChjx5jS1X/kM30kTI9/0YBVwp4IamLgJpjS +k2A== X-Gm-Message-State: ALoCoQlPXPCEeEcxgeWqizLysvSoyiLSZAWMdSFMHvTFy/adGaa9bOTBJ3kDEnhCQiv7KW44CVwv X-Received: by 10.42.230.67 with SMTP id jl3mr14095051icb.15.1422121444258; Sat, 24 Jan 2015 09:44:04 -0800 (PST) Received: from sol.firepipe.net (c-50-183-92-30.hsd1.co.comcast.net. [50.183.92.30]) by mx.google.com with ESMTPSA id c4sm2740243igt.19.2015.01.24.09.44.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 09:44:03 -0800 (PST) Sender: Will Andrews Date: Sat, 24 Jan 2015 10:44:01 -0700 From: Will Andrews To: Matthias Apitz , "O. Hartmann" , FreeBSD CURRENT Subject: Re: [CURRENT] r277641 fails to installworld: routing_test: No such file or directory Message-ID: <20150124174400.GB57177@sol.firepipe.net> References: <20150124134958.20f0a70b.ohartman@zedat.fu-berlin.de> <20150124125443.GA2297@c720-r276659> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E39vaYmALEf/7YXx" Content-Disposition: inline In-Reply-To: <20150124125443.GA2297@c720-r276659> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 17:44:12 -0000 --E39vaYmALEf/7YXx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 24, 2015 at 01:54:43PM +0100, Matthias Apitz wrote: > El d=EDa Saturday, January 24, 2015 a las 01:49:58PM +0100, O. Hartmann e= scribi=F3: >=20 > > Most recent sources fail to install with the error below. CURRENT is am= d64 and at r277641: > >=20 > >=20 > > =3D=3D=3D> etc/tests/rc.d (install) > > install -o root -g wheel -m 555 routing_test /usr/tests/etc/rc.d/rou= ting_test > > install: /usr/tests/etc/rc.d/routing_test: No such file or directory > > *** Error code 71 >=20 > I'm facing right now (13:52 CET) the same with creating the jail for > poudriere with >=20 > poudriere jail -c -j freebsd-head -m svn+http -v head >=20 > after 2 hours all is rolled back :-( > not even the checked out tree is left :-( This is fixed in r277650. My apologies. --=20 wca --E39vaYmALEf/7YXx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTD2eAACgkQF47idPgWcsViXACeK1j1dKGULfl4SroJaedCFCuj 0OUAoJHBpop6bLaM+A5cKwJzno4TyiV5 =DEOM -----END PGP SIGNATURE----- --E39vaYmALEf/7YXx-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 17:58:11 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2C4B4D2; Sat, 24 Jan 2015 17:58:10 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88E0DC39; Sat, 24 Jan 2015 17:58:10 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id h11so2275548wiw.0; Sat, 24 Jan 2015 09:58:08 -0800 (PST) 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=uulJ4uRZGn8uMzqn8CgR2qIGJnRVqEdzebGdfArCFiA=; b=paburwuR14/Tt1F9T326RzSSeVKgchr3x9CM9dGgRa5iGU/skD67dezPPh/e0S12t0 8db4dRHzJZjPfFx7Ul7MBbwkoaCpsTm7kLXl26R3kXzaumAXziiYr40MfEjRFIFe9BwC RrpOOYurm/X7gVYR/n+luF8dsl/hpKnhAmk6CP6FFYH4Gqe0dZ0CYZH1t7fpdI665Zpm fn57bqTahDQyC/obDNiCQ77ZCizCRGajT/XITe2nvjWcuJ4fQoP4rI1T4zuSPrR6RKxB QPeBAHBTU7GYRODgYPxcQTFlox1JYZdTJu0ehnoxhRvFw0SnHfny+uwPlQd27cWodvSZ 1R4Q== MIME-Version: 1.0 X-Received: by 10.194.108.98 with SMTP id hj2mr27104117wjb.102.1422122288849; Sat, 24 Jan 2015 09:58:08 -0800 (PST) Received: by 10.27.131.166 with HTTP; Sat, 24 Jan 2015 09:58:08 -0800 (PST) In-Reply-To: References: Date: Sat, 24 Jan 2015 11:58:08 -0600 Message-ID: Subject: Re: install: /usr/tests/etc/rc.d/routing_test: No such file or directory From: Scot Hetzel To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 17:58:11 -0000 On Sat, Jan 24, 2015 at 10:42 AM, Adrian Chadd wrote: > I just updated a box: > > ===> etc/tests/rc.d (install) > install -o root -g wheel -m 555 routing_test /usr/tests/etc/rc.d/routing_test > install: /usr/tests/etc/rc.d/routing_test: No such file or directory > *** Error code 71 > > .. did someone forget an mtree? > > Looks like etc/rc.d needs to be added to the BSD.tests.dist. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 18:58:22 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B7FE26A for ; Sat, 24 Jan 2015 18:58:22 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D88E31DD for ; Sat, 24 Jan 2015 18:58:21 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id p6so2293053qcv.1 for ; Sat, 24 Jan 2015 10:58:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=DCAPbrSAaGaOgS+TjwZjWHYQSP/gP5fdJENb61q0RgM=; b=YNOVAPqa95XYYqa4GIqlZ0ZSHUZYjzikBJ/PueqalhMbju52oLW9kcKhzEerLPbkUu Fr0DVoucytseYssWsUyOGFJcFxOqScWd2thpcN7u0OPch2VH5Up1UgZfMkEblcJz9461 ZSKhxrmSaupEo6Eez9+s5khOwQFRwv6/ipHErwsPvy6yyrZ8HAUyl1kZJDZaPqSOaXQ7 Z/mOeK7tdbFUlOuGMdYd4NXZy0GoPw4fQTSMt16kqPDGfFExiE4DP4aFNQaH4Ik6pAFd BseQORVyt5mPDm2rsJIhc9i458+5bNausnCpCAcR4m5mDG7UBeVG81+7a8Dc+ugky1iZ m2aw== X-Received: by 10.224.120.10 with SMTP id b10mr21262396qar.19.1422125900962; Sat, 24 Jan 2015 10:58:20 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.140.39.209 with HTTP; Sat, 24 Jan 2015 10:58:00 -0800 (PST) In-Reply-To: <20150124081101.GA74579@onelab2.iet.unipi.it> References: <20150124081101.GA74579@onelab2.iet.unipi.it> From: Ed Maste Date: Sat, 24 Jan 2015 13:58:00 -0500 X-Google-Sender-Auth: -qye-Bs2EabogCUloL-6unzty1M Message-ID: Subject: Re: elftoolchain version of strip unlinks hard-linked files ? To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 18:58:22 -0000 Hi Luigi, On 24 January 2015 at 03:11, Luigi Rizzo wrote: > I just found that recent versions of 'strip' on head (the change > occurred between svn 276756 and 277633, not in the code but with > the change from GNU binutils to the elf toolchain) when operating > on hard-linked files, creates a new file instead of modifying the > original: > > ... > > I believe the elftoolchain is doing it wrong and should be fixed. I agree that strip ought to leave links intact and will make sure this gets fixed. Fortunately copy_from_tempfile() already has logic to try rename() first and fall back to copying otherwise, so it should be fairly straightforward to add special handling for files with link count > 1. If you need a short term workaround you can set WITHOUT_ELFTOOLCHAIN_TOOLS in src.conf to switch back to the binutils tools. That said, when installworld strips it does so at install time and creates links afterwards. Thus this issue won't happen for those standard targets. Could picobsd make use of that? > It is also weird that the new strip, despite being statically > linked, looks up for helper programs somewhere,because if i copy > it to a different directory it makes the copy but no longer works > correctly: No, it doesn't use any helper programs. It's just that strip and elfcopy are hard-links, and the mode is selected based on argv[0]. This seems reasonable to me, but if there's a need to be able to give it an arbitrary name I'll undo the link and make it always operate as strip. Otherwise, I think a reasonable enhancement would be to check also for *-strip. From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 19:42:50 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF461FC4; Sat, 24 Jan 2015 19:42:50 +0000 (UTC) Received: from dchagin.static.corbina.net (dchagin.static.corbina.ru [78.107.232.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dchagin.static.corbina.net", Issuer "dchagin.static.corbina.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 88030892; Sat, 24 Jan 2015 19:42:49 +0000 (UTC) Received: from dchagin.static.corbina.net (localhost [127.0.0.1]) by dchagin.static.corbina.net (8.14.9/8.14.9) with ESMTP id t0OJgjsQ075758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 24 Jan 2015 22:42:46 +0300 (MSK) (envelope-from dchagin@dchagin.static.corbina.net) Received: (from dchagin@localhost) by dchagin.static.corbina.net (8.14.9/8.14.9/Submit) id t0OJgjDr075757; Sat, 24 Jan 2015 22:42:45 +0300 (MSK) (envelope-from dchagin) Date: Sat, 24 Jan 2015 22:42:45 +0300 From: Chagin Dmitry To: Konstantin Belousov Subject: Re: dblfault panic r277611 Message-ID: <20150124194245.GA72881@dchagin.static.corbina.net> References: <20150124094633.GA1804@dchagin.static.corbina.net> <20150124103519.GR42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150124103519.GR42409@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org, dim@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 19:42:51 -0000 On Sat, Jan 24, 2015 at 12:35:19PM +0200, Konstantin Belousov wrote: > On Sat, Jan 24, 2015 at 12:46:33PM +0300, Chagin Dmitry wrote: > > Hi, > > > > > > dchagin.static.corbina.net dumped core - see /var/crash/vmcore.7 > > > > Sat Jan 24 01:02:20 MSK 2015 > > > > FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r277611+c41ef74(lemul): Sat Jan 24 00:53:45 MSK 2015 root@dchagin.static.corbina.net:/home/rootobj/home/git/head/sys/YOY amd64 > > > > panic: double fault > > > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "amd64-marcel-freebsd"... > > > > Unread portion of the kernel message buffer: > > ffs_syncvnode+0x3b0/frame 0xfffffe033c22bd50 > > ffs_truncate() at ffs_truncate+0xc6a/frame 0xfffffe033c22c150 > > ufs_direnter() at ufs_direnter+0xde5/frame 0xfffffe033c22c280 > > ufs_mkdir() at ufs_mkdir+0xb07/frame 0xfffffe033c22c4a0 > > > > Fatal double fault > > rip = 0xffffffff807a8d03 > > rsp = 0xfffffe033c228e60 > > rbp = 0xfffffe033c229000 > > cpuid = 5; apic id = 05 > > panic: double fault > > cpuid = 5 > > KDB: enter: panic > > > > Reading symbols from /boot/kernel/if_tap.ko.symbols...done. > > Loaded symbols for /boot/kernel/if_tap.ko.symbols > > Reading symbols from /boot/kernel/if_bridge.ko.symbols...done. > > Loaded symbols for /boot/kernel/if_bridge.ko.symbols > > Reading symbols from /boot/kernel/bridgestp.ko.symbols...done. > > Loaded symbols for /boot/kernel/bridgestp.ko.symbols > > Reading symbols from /boot/kernel/usb.ko.symbols...done. > > Loaded symbols for /boot/kernel/usb.ko.symbols > > Reading symbols from /boot/kernel/xhci.ko.symbols...done. > > Loaded symbols for /boot/kernel/xhci.ko.symbols > > Reading symbols from /boot/kernel/vmm.ko.symbols...done. > > Loaded symbols for /boot/kernel/vmm.ko.symbols > > Reading symbols from /boot/kernel/nmdm.ko.symbols...done. > > Loaded symbols for /boot/kernel/nmdm.ko.symbols > > Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. > > Loaded symbols for /boot/kernel/linprocfs.ko.symbols > > Reading symbols from /boot/kernel/pseudofs.ko.symbols...done. > > Loaded symbols for /boot/kernel/pseudofs.ko.symbols > > Reading symbols from /boot/kernel/linux_common.ko.symbols...done. > > Loaded symbols for /boot/kernel/linux_common.ko.symbols > > Reading symbols from /boot/kernel/procfs.ko.symbols...done. > > Loaded symbols for /boot/kernel/procfs.ko.symbols > > Reading symbols from /boot/kernel/ukbd.ko.symbols...done. > > Loaded symbols for /boot/kernel/ukbd.ko.symbols > > Reading symbols from /boot/kernel/ums.ko.symbols...done. > > Loaded symbols for /boot/kernel/ums.ko.symbols > > #0 doadump (textdump=771179792) > > at /home/git/head/sys/kern/kern_shutdown.c:262 > > 262 dumptid = curthread->td_tid; > > (kgdb) #0 doadump (textdump=771179792) > > at /home/git/head/sys/kern/kern_shutdown.c:262 > > #1 0xffffffff803c1b08 in db_fncall_generic (addr=-2139713712, > > rv=0xfffffe032df744a0, nargs=0, args=0xfffffe032df744b0) > > at /home/git/head/sys/ddb/db_command.c:568 > > #2 0xffffffff803c17d3 in db_fncall (dummy1=-2185367173664, dummy2=0, > > dummy3=0, dummy4=0xfffffe032df745e0 "\n") > > at /home/git/head/sys/ddb/db_command.c:616 > > #3 0xffffffff803c142b in db_command (last_cmdp=0xffffffff810fd6a8, > > cmd_table=0x0, dopager=1) at /home/git/head/sys/ddb/db_command.c:440 > > #4 0xffffffff803c0f9d in db_command_loop () > > at /home/git/head/sys/ddb/db_command.c:493 > > #5 0xffffffff803c58d9 in db_trap (type=3, code=0) > > at /home/git/head/sys/ddb/db_main.c:251 > > #6 0xffffffff807cc704 in kdb_trap (type=3, code=0, tf=0xfffffe032df74cc0) > > at /home/git/head/sys/kern/subr_kdb.c:654 > > #7 0xffffffff80c94e1d in trap (frame=0xfffffe032df74cc0) > > at /home/git/head/sys/amd64/amd64/trap.c:546 > > #8 0xffffffff80c9655f in trap_check (frame=0xfffffe032df74cc0) > > at /home/git/head/sys/amd64/amd64/trap.c:645 > > #9 0xffffffff80c691a2 in calltrap () > > at /home/git/head/sys/amd64/amd64/exception.S:235 > > #10 0xffffffff807cbf15 in breakpoint () at cpufunc.h:63 > > #11 0xffffffff807cbaff in kdb_enter (why=0xffffffff80dcd635 "panic", > > msg=0xffffffff80dcd635 "panic") at /home/git/head/sys/kern/subr_kdb.c:443 > > #12 0xffffffff80769768 in vpanic (fmt=0xffffffff80e24597 "double fault", > > ap=0xfffffe032df74ec0) at /home/git/head/sys/kern/kern_shutdown.c:740 > > #13 0xffffffff80769820 in panic (fmt=0xffffffff80e24597 "double fault") > > at /home/git/head/sys/kern/kern_shutdown.c:676 > > #14 0xffffffff80c9667d in dblfault_handler (frame=0xfffffe032df74f40) > > at /home/git/head/sys/amd64/amd64/trap.c:912 > > #15 0xffffffff80c6929c in Xdblfault () > > at /home/git/head/sys/amd64/amd64/exception.S:291 > > #16 0xffffffff807a8d03 in cpu_search_lowest (cg=Cannot access memory at address 0xfffffe033c228ec8 > > ) > > at /home/git/head/sys/kern/sched_ule.c:764 > > #17 0xffffffff807a9094 in cpu_search_lowest (cg=0xffffffff8128a6e8, > > low=0xfffffe033c2292f8) at /home/git/head/sys/kern/sched_ule.c:690 > > #18 0xffffffff807a9094 in cpu_search_lowest (cg=0xffffffff8128a6b0, > > low=0xfffffe033c229380) at /home/git/head/sys/kern/sched_ule.c:690 > > #19 0xffffffff807b0f56 in sched_lowest (cg=0xffffffff8128a6b0, mask= > > {__bits = {255, 0, 0, 0}}, pri=121, maxload=2147483647, prefer=5) > > at /home/git/head/sys/kern/sched_ule.c:796 > > #20 0xffffffff807abcdb in sched_pickcpu (td=0xfffff80009e5a9a0, flags=0) > > at /home/git/head/sys/kern/sched_ule.c:1276 > > #21 0xffffffff807ace35 in sched_add (td=0xfffff80009e5a9a0, flags=0) > > at /home/git/head/sys/kern/sched_ule.c:2395 > > #22 0xffffffff807acac9 in sched_wakeup (td=0xfffff80009e5a9a0) > > at /home/git/head/sys/kern/sched_ule.c:2029 > > #23 0xffffffff8077d6a8 in setrunnable (td=0xfffff80009e5a9a0) > > at /home/git/head/sys/kern/kern_synch.c:544 > > #24 0xffffffff807e4e98 in sleepq_resume_thread (sq=0xfffff80009e55d80, > > td=0xfffff80009e5a9a0, pri=0) > > at /home/git/head/sys/kern/subr_sleepqueue.c:776 > > #25 0xffffffff807e306a in sleepq_timeout (arg=0xfffff80009e5a9a0) > > at /home/git/head/sys/kern/subr_sleepqueue.c:915 > > #26 0xffffffff80791b40 in softclock_call_cc (c=0xfffff80009e5ad38, > > cc=0xffffffff813a4200, direct=1) > > at /home/git/head/sys/kern/kern_timeout.c:724 > > #27 0xffffffff807913bd in callout_process (now=740683739317) > > at /home/git/head/sys/kern/kern_timeout.c:499 > > #28 0xffffffff80ce346a in handleevents (now=740683739317, fake=0) > > at /home/git/head/sys/kern/kern_clocksource.c:212 > > #29 0xffffffff80ce3fd6 in timercb (et=0xffffffff8137df68, arg=0x0) > > at /home/git/head/sys/kern/kern_clocksource.c:345 > > #30 0xffffffff80d376e3 in lapic_handle_timer (frame=0xfffffe033c229c50) > > at /home/git/head/sys/x86/x86/local_apic.c:883 > > #31 0xffffffff80c69cfc in Xtimerint () at apic_vector.S:109 > > #32 0xffffffff80c745ef in write_rflags (rf=642) at cpufunc.h:382 > > #33 0xffffffff80c6f225 in intr_restore (rflags=642) at cpufunc.h:775 > > #34 0xffffffff80c71ce8 in spinlock_exit () > > at /home/git/head/sys/amd64/amd64/machdep.c:2177 > > #35 0xffffffff8074335c in __mtx_unlock_spin_flags (c=0xffffffff8119ec80, > > opts=0, file=0xffffffff80dc3d2b "/home/git/head/sys/kern/kern_cons.c", > > line=530) at /home/git/head/sys/kern/kern_mutex.c:305 > > #36 0xffffffff806df9fc in cnputs (p=0xfffffe033c22a402 "\"<\003ЧЪЪ") > > at /home/git/head/sys/kern/kern_cons.c:530 > > #37 0xffffffff807d76ae in putbuf (c=10, ap=0xfffffe033c22a3b8) > > at /home/git/head/sys/kern/subr_prf.c:427 > > #38 0xffffffff807d60d6 in putchar (c=10, arg=0xfffffe033c22a3b8) > > at /home/git/head/sys/kern/subr_prf.c:471 > > #39 0xffffffff807d43e3 in kvprintf (fmt=0xffffffff80d77b33 "", > > func=0xffffffff807d6010 , arg=0xfffffe033c22a3b8, radix=10, > > ap=0xfffffe033c22a510) at /home/git/head/sys/kern/subr_prf.c:720 > > #40 0xffffffff807d6569 in _vprintf (level=-1, flags=5, > > fmt=0xffffffff80d77b31 "%c", ap=0xfffffe033c22a510) > > at /home/git/head/sys/kern/subr_prf.c:271 > > #41 0xffffffff807d68dd in vprintf (fmt=0xffffffff80d77b31 "%c", > > ap=0xfffffe033c22a510) at /home/git/head/sys/kern/subr_prf.c:388 > > #42 0xffffffff807d689b in printf (fmt=0xffffffff80d77b31 "%c") > > at /home/git/head/sys/kern/subr_prf.c:377 > > #43 0xffffffff803c5d55 in db_putc (c=10) > > at /home/git/head/sys/ddb/db_output.c:156 > > #44 0xffffffff803c5b21 in db_putchar (c=10, arg=0xfffffe033c22aad8) > > at /home/git/head/sys/ddb/db_output.c:128 > > #45 0xffffffff807d3b65 in kvprintf (fmt=0xffffffff80d8090f "", > > func=0xffffffff803c5af0 , arg=0xfffffe033c22aad8, radix=16, > > ap=0xfffffe033c22aac0) at /home/git/head/sys/kern/subr_prf.c:645 > > #46 0xffffffff803c5ad8 in db_printf (fmt=0xffffffff80d8090e "\n") > > at /home/git/head/sys/ddb/db_output.c:340 > > #47 0xffffffff80c67f73 in db_print_stack_entry ( > > name=0xffffffff815c8262 "ufs_mkdir", narg=0, argnp=0x0, > > argp=0xfffffe033c22c4b0, callpc=18446744071574694567, > > frame=0xfffffe033c22c4a0) at /home/git/head/sys/amd64/amd64/db_trace.c:260 > > #48 0xffffffff80c66f3b in db_backtrace (td=0xfffff801ad926000, tf=0x0, > > frame=0xfffffe033c22c4a0, pc=18446744071574694567, count=1005) > > at /home/git/head/sys/amd64/amd64/db_trace.c:462 > > #49 0xffffffff80c66bdf in db_trace_self () > > at /home/git/head/sys/amd64/amd64/db_trace.c:498 > > #50 0xffffffff803c568e in db_trace_self_wrapper () > > at /home/git/head/sys/ddb/db_main.c:268 > > #51 0xffffffff807cbcd8 in kdb_backtrace () > > at /home/git/head/sys/kern/subr_kdb.c:370 > > #52 0xffffffff807fe924 in _witness_debugger (cond=1, > > msg=0xffffffff80dd6e29 "witness_checkorder") > > at /home/git/head/sys/kern/subr_witness.c:2904 > > #53 0xffffffff807fe2de in witness_checkorder (lock=0xfffff80193effd50, > > flags=9, file=0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", > > line=2164, interlock=0xfffff80193effd80) > > at /home/git/head/sys/kern/subr_witness.c:1365 > > #54 0xffffffff80730d65 in __lockmgr_args (lk=0xfffff80193effd50, > > flags=524544, ilk=0xfffff80193effd80, wmesg=0x0, pri=0, timo=0, > > file=0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=2164) > > at /home/git/head/sys/kern/kern_lock.c:756 > > #55 0xffffffff80bf1438 in _lockmgr_args (lk=0xfffff80193effd50, flags=524544, > > ilk=0xfffff80193effd80, wmesg=0x0, prio=0, timo=0, > > file=0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=2164) > > at lockmgr.h:98 > > #56 0xffffffff80bef677 in ffs_lock (ap=0xfffffe033c22b7c8) > > at /home/git/head/sys/ufs/ffs/ffs_vnops.c:385 > > #57 0xffffffff80d47cd4 in VOP_LOCK1_APV (vop=0xffffffff810cd328, > > a=0xfffffe033c22b7c8) at vnode_if.c:2082 > > #58 0xffffffff808ac2f3 in VOP_LOCK1 (vp=0xfffff80193effce8, flags=524544, > > file=0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=2164) > > at vnode_if.h:859 > > #59 0xffffffff808aa122 in _vn_lock (vp=0xfffff80193effce8, flags=524544, > > file=0xffffffff80ddfb99 "/home/git/head/sys/kern/vfs_subr.c", line=2164) > > at /home/git/head/sys/kern/vfs_vnops.c:1531 > > #60 0xffffffff8088d636 in vget (vp=0xfffff80193effce8, flags=524544, > > td=0xfffff801ad926000) at /home/git/head/sys/kern/vfs_subr.c:2164 > > #61 0xffffffff8087884f in vfs_hash_get (mp=0xfffff80009db2000, hash=71269052, > > flags=524288, td=0xfffff801ad926000, vpp=0xfffffe033c22bb40, fn=0, > > arg=0x0) at /home/git/head/sys/kern/vfs_hash.c:89 > > #62 0xffffffff80be7969 in ffs_vgetf (mp=0xfffff80009db2000, ino=71269052, > > flags=524288, vpp=0xfffffe033c22bb40, ffs_flags=1) > > at /home/git/head/sys/ufs/ffs/ffs_vfsops.c:1636 > > #63 0xffffffff80bd1d02 in flush_pagedep_deps (pvp=0xfffff80193c8d588, > > mp=0xfffff80009db2000, diraddhdp=0xfffff80193769b58) > > at /home/git/head/sys/ufs/ffs/ffs_softdep.c:12929 > > #64 0xffffffff80bd182c in softdep_sync_buf (vp=0xfffff80193c8d588, > > bp=0xfffffe02d6a8d6d0, waitfor=1) > > at /home/git/head/sys/ufs/ffs/ffs_softdep.c:12621 > > #65 0xffffffff80bf0d40 in ffs_syncvnode (vp=0xfffff80193c8d588, waitfor=1, > > flags=0) at /home/git/head/sys/ufs/ffs/ffs_vnops.c:280 > > #66 0xffffffff80babd9a in ffs_truncate (vp=0xfffff80193c8d588, length=512, > > flags=2176, cred=0xfffff80009c52b00) > > at /home/git/head/sys/ufs/ffs/ffs_inode.c:339 > > #67 0xffffffff80bfd315 in ufs_direnter (dvp=0xfffff80193c8d588, > > tvp=0xfffff80193effce8, dirp=0xfffffe033c22c390, cnp=0xfffffe033c22c720, > > newdirbp=0xfffffe02d66d7db0, isrename=0) > > at /home/git/head/sys/ufs/ufs/ufs_lookup.c:1133 > > #68 0xffffffff80c0aaa7 in ufs_mkdir (ap=0xfffffe033c22c558) > > at /home/git/head/sys/ufs/ufs/ufs_vnops.c:1963 > > #69 0xffffffff80d460fd in VOP_MKDIR_APV (vop=0xffffffff810cddd8, > > a=0xfffffe033c22c558) at vnode_if.c:1607 > > #70 0xffffffff808a5979 in VOP_MKDIR (dvp=0xfffff80193c8d588, > > vpp=0xfffffe033c22c6f8, cnp=0xfffffe033c22c720, vap=0xfffffe033c22c768) > > at vnode_if.h:665 > > #71 0xffffffff808a585c in kern_mkdirat (td=0xfffff801ad926000, fd=-100, > > path=0x7fffffffe949
, > > segflg=UIO_USERSPACE, mode=511) > > at /home/git/head/sys/kern/vfs_syscalls.c:3747 > > #72 0xffffffff808a54c3 in sys_mkdir (td=0xfffff801ad926000, > > uap=0xfffffe033c22ca58) at /home/git/head/sys/kern/vfs_syscalls.c:3678 > > #73 0xffffffff80c97044 in syscallenter (td=0xfffff801ad926000, > > sa=0xfffffe033c22ca48) at subr_syscall.c:133 > > #74 0xffffffff80c9694a in amd64_syscall (td=0xfffff801ad926000, traced=0) > > at /home/git/head/sys/amd64/amd64/trap.c:986 > > #75 0xffffffff80c6948b in Xfast_syscall () > > at /home/git/head/sys/amd64/amd64/exception.S:395 > > #76 0x0000000800946eca in ?? () > > Previous frame inner to this frame (corrupt stack?) > > Current language: auto; currently minimal > > (kgdb) > > > > > > This is fun, for some definition of it. > > The process was in the guts of VFS from mkdir(2) syscall, witness > triggered printing of the warning for dreaded buf->hashdir->buf non-real > LOR. From the ddb stack backtrace routine, when cnputs released the > console spinlock yet another time, timer interrupt fired and started > proceeding callouts. One of the callout triggered and needs to wake > up a thread sleeping with timeout. There, inside the scheduler, > cpu_search_lowest() was called, recursed twice and finally > overflown the stack. > > Is this yet another clang regression ? The cpu_search_lowest() saga seems > to never end. r268211 is uneffective, probably after clang 3.5 import. yes, you are right. building kernel without SSP fixes the panic. -- Have fun! chd From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 20:07:31 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 730ADAA8 for ; Sat, 24 Jan 2015 20:07:31 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 6128EAAB for ; Sat, 24 Jan 2015 20:07:31 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D22ED6C9 for ; Sat, 24 Jan 2015 20:07:31 +0000 (UTC) Date: Sat, 24 Jan 2015 20:07:31 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1299641134.4.1422130051835.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <922776149.3.1422118764819.JavaMail.jenkins@jenkins-9.freebsd.org> References: <922776149.3.1422118764819.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #939 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 20:07:31 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 22:25:39 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E5D4A31; Sat, 24 Jan 2015 22:25:39 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 382F79BB; Sat, 24 Jan 2015 22:25:39 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id rd18so3133090iec.3; Sat, 24 Jan 2015 14:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=sP435NnwK4eYlgzICbPlLxCOstpfr0Y1jnA4Pvmzh1Y=; b=cYbPEsZ6liCUgw4xXRLsJPgoknuBVZQqo6a8yTc1g1M6N/I+xXho/cWWBqaLu9wWm7 6AGpK8SSjMevt2aji4phjohLYw5ep3Bv+K8FhEBBxXqwlCZCA6vKa3QEhNeZEd9WZS0/ o5wwC+QiabyJ2pK65P8OnVvAYYczkDI317fqI26OO/9wYCc4XxQi9woBmmXOcHaI9Eu/ WFwUXBw0uNbDd67N90Ezch6N0191sZlJhoUvmclYDRXSDmAhU++KyjIhLg+krfLxF73a k640zYDu637BZPxwbiZ741mkqcdcWBqjGRFgHSdQeaFyiS+DKKmTqXZSwObUFEI51v0K 55zA== MIME-Version: 1.0 X-Received: by 10.50.164.227 with SMTP id yt3mr9121431igb.32.1422138338655; Sat, 24 Jan 2015 14:25:38 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Sat, 24 Jan 2015 14:25:38 -0800 (PST) Date: Sat, 24 Jan 2015 14:25:38 -0800 X-Google-Sender-Auth: B-ZlnzWp5w4F2_s7l0z1XP8CRNI Message-ID: Subject: drm2 regression: backlight adjustment on ivybridge no longer works From: Adrian Chadd To: Konstantin Belousov , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 22:25:39 -0000 Hi, I've just found a regression. The backlight adjustment doesn't work on my ivybridge mobile laptop (Lenovo X230) after the dri update. I've added debugging. It's making it all the way to the pch backlight panel update routine in intel_panel.c, but it's not changing the backlight appearance itself. The "intel_backlight" program from intel-gpu-tools" also no longer changes the backlight value. I'm going to finish rebuilding -HEAD on the sandy bridge laptop here and try it out. Thanks, -adrian From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:27:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94969477 for ; Sat, 24 Jan 2015 23:27:53 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 84C8FFBF for ; Sat, 24 Jan 2015 23:27:53 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 0BACBF90 for ; Sat, 24 Jan 2015 23:27:54 +0000 (UTC) Date: Sat, 24 Jan 2015 23:27:54 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <354421615.6.1422142074021.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #587 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Jan 2015 23:27:53 -0000 See