From owner-freebsd-current@freebsd.org Sun Dec 6 00:15:19 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D143A3F905 for ; Sun, 6 Dec 2015 00:15:19 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id E1C291837 for ; Sun, 6 Dec 2015 00:15:18 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 067E1D778 for ; Sun, 6 Dec 2015 00:15:11 +0000 (UTC) Subject: Re: unable to select wireless interface during install time on 11-CURRENT after the wireless subsystem rewrite To: freebsd-current@freebsd.org References: From: Allan Jude Message-ID: <56637E2B.2020509@freebsd.org> Date: Sat, 5 Dec 2015 19:15:39 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NP4DoCGji24RiKnaV931w5XBi4Q0tuXvm" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 00:15:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NP4DoCGji24RiKnaV931w5XBi4Q0tuXvm Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-12-05 17:57, Oliver Pinter wrote: > Hi all! >=20 > After the "recent" wireless rewrite from Gleb, the enumeration of > wireless interfaces has gone from the bsdinstall. >=20 > This line: https://github.com/HardenedBSD/hardenedBSD/blob/hardened/cur= rent/master/usr.sbin/bsdinstall/scripts/netconfig#L52 > return no entry, because the wlan interface not exists. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 This is a known bug, the wifi system changed, and I have not had time to update the installer. I hope to get to it tomorrow afternoon. --=20 Allan Jude --NP4DoCGji24RiKnaV931w5XBi4Q0tuXvm 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) iQIcBAEBAgAGBQJWY34vAAoJEBmVNT4SmAt+ckcQAI7EqwXzehXp9mSjAIobPlFe FkHFutXaA7gR4Ci1u/rjaGx797QlCAwm+Irau7Vg3FaWtWh7y9g9wjhdoAwlfYfq EQXolNTqBZRP+LW6I9KxM+AgMLA71bfrY1Mo3N70Zc2OJBGSPRrBpFwwu5c67hAs k18/mgaKdH3pi3Xi2YdymnGyv+qSBmJ1ndxe0e2Bpwq1YFfNxvLgto9/cQlT+G5O bRVr3BPOXB3dGcZZzeu2ua7RMoI0ZlOHkfjmTioIGq2JsKtV4vjcw5Q2ptgEl+a+ MCgpxjhwanrF+ozIeubSOD84bB1VOJNg7InnPzs+aNlT3kLW9Tvj+WnwHn948Uka NTYISTSt9+JtxTQd5+ngQOUJWpjGhAvyZgRAvmxiQUs4WAY6752tqc1VOR8yo+yZ hoWTim4Mxb5fd9yMfdfvjLjUOe1A7mc9gxU7NIQYYPhRTVYyeHICknrWUMdLwze6 FKOq4Rl92qPJccy8Z1TBhuSbZ2lFF43KTWxyskeElSftyAtBj7dDQwJ/jLUDOsBF E85FK5/VCJsTUItuESj+VW9biw3mDJGI0cO2Vq/kz2sx7XbOr0Yg4TP0L5nOzZY3 gQ6ZDvUBTGRmor63PWZ0ufOeUOvhB7XrdCBSCvLoCtwQCfaz3H2v/CLHvHu5S7rp m8GEFOobvlpEekTA2JuT =SD0u -----END PGP SIGNATURE----- --NP4DoCGji24RiKnaV931w5XBi4Q0tuXvm-- From owner-freebsd-current@freebsd.org Sun Dec 6 00:37:16 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEF0BA40081 for ; Sun, 6 Dec 2015 00:37:16 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 958591578 for ; Sun, 6 Dec 2015 00:37:16 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 93624A4007E; Sun, 6 Dec 2015 00:37:16 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92DB2A4007D; Sun, 6 Dec 2015 00:37:16 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C6991577; Sun, 6 Dec 2015 00:37:16 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tB60LBdR002984 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 5 Dec 2015 16:21:12 -0800 Subject: Re: unable to select wireless interface during install time on 11-CURRENT after the wireless subsystem rewrite To: Oliver Pinter , current@freebsd.org References: Cc: wireless@freebsd.org, Gleb Smirnoff , Adrian Chadd From: Nathan Whitehorn Message-ID: <56637F77.6090809@freebsd.org> Date: Sat, 5 Dec 2015 16:21:11 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbCKJ69lNnQ7KtlVk74wPJmaPIDoqj8MJ/uO4797DeFuzQ4PkrQW+PsOdgzEW0qiymgo7kfHyZwv4n2mIgYlYu+m69LQtrrg3U= X-Sonic-ID: C;XOzkQK+b5RGTYr0U9jFv0A== M;iDouQa+b5RGTYr0U9jFv0A== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 00:37:16 -0000 I just fixed this (r291877). Thanks for the report! -Nathan On 12/05/15 14:57, Oliver Pinter wrote: > Hi all! > > After the "recent" wireless rewrite from Gleb, the enumeration of > wireless interfaces has gone from the bsdinstall. > > This line: https://github.com/HardenedBSD/hardenedBSD/blob/hardened/current/master/usr.sbin/bsdinstall/scripts/netconfig#L52 > return no entry, because the wlan interface not exists. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Sun Dec 6 10:47:22 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9BB27E3C for ; Sun, 6 Dec 2015 10:47:22 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) (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 3A0101A1F for ; Sun, 6 Dec 2015 10:47:21 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.170.80] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1a5Wot-00044R-L8 for freebsd-current@freebsd.org; Sun, 06 Dec 2015 11:45:31 +0100 Date: Sun, 6 Dec 2015 11:45:32 +0100 From: Fabian Keil To: FreeBSD Current Subject: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000 Message-ID: <20151206114532.73b1dac9@fabiankeil.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Flwfw2wi.SSvwY_jLn5vwyU"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 10:47:22 -0000 --Sig_/Flwfw2wi.SSvwY_jLn5vwyU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I got the following panic while trying to import a ZFS pool from a geli-encrypted memory disk backed by a file located on a msdosfs partition: (kgdb) where #0 doadump (textdump=3D0) at pcpu.h:221 #1 0xffffffff80314c1b in db_dump (dummy=3D, dummy2=3D= false, dummy3=3D0, dummy4=3D0x0) at /usr/src/sys/ddb/db_command.c:533 #2 0xffffffff80314a0e in db_command (cmd_table=3D0x0) at /usr/src/sys/ddb/= db_command.c:440 #3 0xffffffff803147a4 in db_command_loop () at /usr/src/sys/ddb/db_command= .c:493 #4 0xffffffff803172ab in db_trap (type=3D, code=3D0) = at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff805dfe33 in kdb_trap (type=3D3, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80879bc7 in trap (frame=3D0xfffffe009444a240) at /usr/src/sys= /amd64/amd64/trap.c:549 #7 0xffffffff8085eb77 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:234 #8 0xffffffff805df51b in kdb_enter (why=3D0xffffffff8096c7fb "panic", msg= =3D0x32
) at cpufunc.h:63 #9 0xffffffff8059bbdf in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:750 #10 0xffffffff8059ba33 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutd= own.c:688 #11 0xffffffff8082ffb5 in vm_fault_hold (map=3D, vaddr= =3D, fault_type=3D, fault_flags= =3D, m_hold=3D) at /usr/src/sys/vm/vm_fault.c:332 #12 0xffffffff8082de18 in vm_fault (map=3D0xfffff80002000000, vaddr=3D, fault_type=3D2 '\002', fault_flags=3D0) at /usr/src/sys/v= m/vm_fault.c:277 #13 0xffffffff8087a33a in trap_pfault (frame=3D0xfffffe009444a8e0, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:734 #14 0xffffffff80879bde in trap (frame=3D0xfffffe009444a8e0) at /usr/src/sys= /amd64/amd64/trap.c:435 #15 0xffffffff8085eb77 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:234 #16 0xffffffff80877d5a in bcopy () at /usr/src/sys/amd64/amd64/support.S:118 #17 0xffffffff805f64e8 in uiomove_faultflag (cp=3D, n= =3D, uio=3D0xfffffe009444aae0, nofault=3D) at /usr/src/sys/kern/subr_uio.c:208 #18 0xffffffff8046236f in msdosfs_read (ap=3D) at /usr= /src/sys/fs/msdosfs/msdosfs_vnops.c:596 #19 0xffffffff808feb20 in VOP_READ_APV (vop=3D, a=3D) at vnode_if.c:930 #20 0xffffffff8039bf3a in mdstart_vnode (sc=3D0xfffff8004c7ce000, bp=3D0xff= fff80028fc81f0) at vnode_if.h:384 #21 0xffffffff8039a3cc in md_kthread (arg=3D0xfffff8004c7ce000) at /usr/src= /sys/dev/md/md.c:979 #22 0xffffffff8055978c in fork_exit (callout=3D0xffffffff8039a1a0 , arg=3D0xfffff8004c7ce000, frame=3D0xfffffe009444ac00) at /usr/src/sys/= kern/kern_fork.c:1011 #23 0xffffffff8085f0ae in fork_trampoline () at /usr/src/sys/amd64/amd64/ex= ception.S:609 #24 0x0000000000000000 in ?? () Current language: auto; currently minimal This is the second time I've seen this, the first time was with a kernel based on r290573 in November, but as I wasn't able to intentionally reprodu= ce it with a more recent kernel my assumption was that the problem had already been fixed. Currently my kernel is based on r291706. Any ideas? Fabian --Sig_/Flwfw2wi.SSvwY_jLn5vwyU Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZkEcwACgkQBYqIVf93VJ20wACfczzFnCw3AMQPohtfgbrYLrM/ W4MAoIcLf41fwMQUNltU4DJ0Ux+GT70s =KnG8 -----END PGP SIGNATURE----- --Sig_/Flwfw2wi.SSvwY_jLn5vwyU-- From owner-freebsd-current@freebsd.org Sun Dec 6 14:14:54 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91E7099A3EE for ; Sun, 6 Dec 2015 14:14:54 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 4FA40109D for ; Sun, 6 Dec 2015 14:14:54 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: by wmec201 with SMTP id c201so120210037wme.1 for ; Sun, 06 Dec 2015 06:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bris-ac-uk.20150623.gappssmtp.com; s=20150623; h=date:from:message-id:to:subject:reply-to; bh=SzPtM+vzbHawvOaYeYZrOxijEUDHLVikDHgQT7lghZU=; b=NIFUcQdOBmD6dc0a3OpkF8lw3MJFPXz4wAieJSR+grS3zcvNvu/6WDY9ARYBK3Upe1 cKX52LomXUR3edxrjlQGsdrx0F8W//eQhdsFJRGNdzPeLBdB2iRopFb/gK0xTh/n91J/ 0+vb26VgKZfLwdeb94GqgTyVJn8y20HqYvPUTh9DTcsDcqMXWkn1CSPLzRZK0hVpZHLr ctvu22K5GyoYcMpCA8EZ5yaMFScZI9RMDTrX28Mmmh1vPuJvt9l90bg9E1Ozady+Hzks n0uWB2Ingl5ajbkFPZX1PpZXA+d5Ztx+/g3Vv+cUocsn+rjH4P1ZN73vr6tX27MFFc0N FYEQ== 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=SzPtM+vzbHawvOaYeYZrOxijEUDHLVikDHgQT7lghZU=; b=FWlLwRpuCOG4NxJnHe6KERAxLOyPCxtUR6BkeGq+bcd//rflJ565NaTZ+ya+8n0ihc BmLXzd2wbAD+WesQSeaepyvPD9cU+WJoHU5aHoEWTWabxtUjV9+CBGqeZ0YkG6LO5TDp gIdBhwUfDeGv5TX0r2lpEFlWakbIQL7pjPmDWfKMLFFs5Mz2dJ7jeKW+uwWKqxz4E01c gGP1xcUiJFUvG9/J33IfPAdcL/OQ1mKHFn0z2Go+FKaJ3eiEKzcpx5c0vMrDnrg4MKMQ 7Wcfm+Cg5XY+0J42BYNVi3J1ksZy9UKEI3knxzOakX3tUKtTSvLrorWgp4kX6/Pj2Bet QovQ== X-Gm-Message-State: ALoCoQkAer/oO6CXrk6k7YfppbM2l4U2j8VdW3hDOupXEVKE/lbiRvM37iz8YFoUkJZo7bA4+2wg X-Received: by 10.194.184.104 with SMTP id et8mr29925513wjc.87.1449411292620; Sun, 06 Dec 2015 06:14:52 -0800 (PST) Received: from mech-as222.men.bris.ac.uk (mech-as222.men.bris.ac.uk. [137.222.170.4]) by smtp.gmail.com with ESMTPSA id w4sm20711161wje.49.2015.12.06.06.14.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Dec 2015 06:14:52 -0800 (PST) Date: Sun, 06 Dec 2015 06:14:52 -0800 (PST) X-Google-Original-Date: Sun, 6 Dec 2015 14:14:51 GMT Received: from mech-as222.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2) with ESMTP id tB6EEpAg041099; Sun, 6 Dec 2015 14:14:51 GMT (envelope-from mexas@mech-as222.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2/Submit) id tB6EEpTY041098; Sun, 6 Dec 2015 14:14:51 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201512061414.tB6EEpTY041098@mech-as222.men.bris.ac.uk> To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: urtwn regression(?) from 10.2 to current r291431 Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 14:14:54 -0000 I posted this about a week ago: http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html The problem is that urtwn stopped working in current r291431. I did more testing with the same revision, and sometimes it would work, but extremely slowly, and sometimes seemingly associate but get an address of 0.0.0.0. I now installed 10.2-RELEASE-p8 and the urtwn works fine, no issues at all. Does this look like a bug at some recent current revision? Should I file a PR? I's just I recall there have been major chages to wlan, so perphaps I'm forgetting to change the config in recent current? Please advise Anton From owner-freebsd-current@freebsd.org Sun Dec 6 14:31:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94C6D99A78F; Sun, 6 Dec 2015 14:31:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 5E93419E1; Sun, 6 Dec 2015 14:31:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (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 18F5D1FE023; Sun, 6 Dec 2015 15:31:29 +0100 (CET) Subject: Re: urtwn regression(?) from 10.2 to current r291431 To: mexas@bris.ac.uk, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Adrian Chadd References: <201512061414.tB6EEpTY041098@mech-as222.men.bris.ac.uk> From: Hans Petter Selasky Message-ID: <5664472E.3090601@selasky.org> Date: Sun, 6 Dec 2015 15:33:18 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <201512061414.tB6EEpTY041098@mech-as222.men.bris.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 14:31:33 -0000 On 12/06/15 15:14, Anton Shterenlikht wrote: > I posted this about a week ago: > > http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html > > The problem is that urtwn stopped > working in current r291431. > > I did more testing with the same revision, > and sometimes it would work, but extremely > slowly, and sometimes seemingly associate > but get an address of 0.0.0.0. > > I now installed 10.2-RELEASE-p8 and > the urtwn works fine, no issues at all. > > Does this look like a bug at some recent > current revision? Should I file a PR? > > I's just I recall there have been major > chages to wlan, so perphaps I'm forgetting > to change the config in recent current? > > Please advise > > Anton Hi, There is work ongoing in the WLAN drivers. Did you try the latest -current? --HPS From owner-freebsd-current@freebsd.org Sun Dec 6 14:44:29 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43A4599ABC7 for ; Sun, 6 Dec 2015 14:44:29 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 CE3D81F9F for ; Sun, 6 Dec 2015 14:44:28 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: by wmec201 with SMTP id c201so120702302wme.1 for ; Sun, 06 Dec 2015 06:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bris-ac-uk.20150623.gappssmtp.com; s=20150623; h=date:from:message-id:to:subject:reply-to:in-reply-to; bh=UoCWsDfWjiZYyf+XxBlbUpvQW0e8m8JGtRiSY/NQVOE=; b=aPorp4p3enkjKyf45unLN1VUOsbmHsz2F5T1yvxKEpxfCtmBkWZBkSRBpVEw2mditJ uE5aMPsNVKqhxwnu7VcRXGOE8TMCmT+d+J8MIFUhS+qVY1L9eq6onB+P083QzPN44dG/ zv+nzjHUPrtHEpXMdoMRUCJgMpNOpudoJBv6n4CZXp0xuSHRvVCx/OV/4lIVkkoOINp8 N/h/a3kSQCBAo3vBSfybJaLL+86TTKlyKUgm5nOOe9WcuU7mn9xEeoQO1s+evYE263kK j6ZMRDjPUJKDBGVQpG3iSeNXQfyECPM89DvsmwsIq+JNDT/5opdTFWMESs9DV1yZO8En yRSg== 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 :in-reply-to; bh=UoCWsDfWjiZYyf+XxBlbUpvQW0e8m8JGtRiSY/NQVOE=; b=ajm+l6bv0DCmg/Xt1K8n17L514v2q4oX5A3fXvx4DifP+SpkcQRH4XhT5ML4eIPkh9 mXJl8SHYt1U9hx7ytiQly3s6c13x8N9jj9zjnaJ3wV/Z0d5Y21CKVQCYq9CF8GlRVMbH emPmHMtcMnhlD0JIZNeogRL7rJY5mtC2peSzEAdQXZgfJDUDwOJAvtTDq5OrWxtfYhMB aIOHU+kRZB9CnAuo9Cg8etzMZiXU15w8d8EAAYESLIvjcXd4ExBzTvFHhwijBBj+NDc2 BeM+gHjWbLBP0kkIJVeNniQLOcSzdyh5IhjIU/CZT4RcwVQkJQCC0JFDHZZNn1ECIz0Q hUFA== X-Gm-Message-State: ALoCoQmNZjofZGx7hkC1yk4qcx+Hw33foQDbsa2rID5oGs3sJJZ/D4aJIGvWbCr3aJPBaC80uVZpV+2NgRRg4TfVSQSo2XYZwg== X-Received: by 10.28.156.75 with SMTP id f72mr16427545wme.91.1449413066792; Sun, 06 Dec 2015 06:44:26 -0800 (PST) Received: from mech-as222.men.bris.ac.uk (mech-as222.men.bris.ac.uk. [137.222.170.4]) by smtp.gmail.com with ESMTPSA id z17sm20945494wjq.1.2015.12.06.06.44.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Dec 2015 06:44:26 -0800 (PST) Date: Sun, 06 Dec 2015 06:44:26 -0800 (PST) X-Google-Original-Date: Sun, 6 Dec 2015 14:44:25 GMT Received: from mech-as222.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2) with ESMTP id tB6EiPlU041205; Sun, 6 Dec 2015 14:44:25 GMT (envelope-from mexas@mech-as222.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2/Submit) id tB6EiPmm041204; Sun, 6 Dec 2015 14:44:25 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201512061444.tB6EiPmm041204@mech-as222.men.bris.ac.uk> To: adrian@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, hps@selasky.org, mexas@bris.ac.uk Subject: Re: urtwn regression(?) from 10.2 to current r291431 Reply-To: mexas@bris.ac.uk In-Reply-To: <5664472E.3090601@selasky.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 14:44:29 -0000 >From hps@selasky.org Sun Dec 6 14:41:27 2015 > >On 12/06/15 15:14, Anton Shterenlikht wrote: >> I posted this about a week ago: >> >> http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html >> >> The problem is that urtwn stopped >> working in current r291431. >> >> I did more testing with the same revision, >> and sometimes it would work, but extremely >> slowly, and sometimes seemingly associate >> but get an address of 0.0.0.0. >> >> I now installed 10.2-RELEASE-p8 and >> the urtwn works fine, no issues at all. >> >> Does this look like a bug at some recent >> current revision? Should I file a PR? >> >> I's just I recall there have been major >> chages to wlan, so perphaps I'm forgetting >> to change the config in recent current? >> >> Please advise >> >> Anton > >Hi, > >There is work ongoing in the WLAN drivers. Did you try the latest -current? > >--HPS r291431 was about a week ago. Will try latest -current later today. Anton From owner-freebsd-current@freebsd.org Sun Dec 6 16:25:07 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B8849A02A8; Sun, 6 Dec 2015 16:25:07 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 73434159D; Sun, 6 Dec 2015 16:25:07 +0000 (UTC) (envelope-from mmitchel@gmail.com) Received: by pacdm15 with SMTP id dm15so111731179pac.3; Sun, 06 Dec 2015 08:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=0xMlNYyMqiiVoFptY2tJMer1QPXmPT5Ff3crm4OcNho=; b=0scztLae/EMh2WTLikQR6adOszPv6lQ1qJzoEI/EZKmm9MYrUCbsKhxlcAyk6Dma3J 2IaerADv8Ig0yAoA/IxgzaCY5GfhGku8SAkw0WKDp99GO3GYJquDFceNakTep1HoI4SM R7cA/IvjEMGw89Ql/uWMaHvWBzQmI7SUvC5hL6MMZWO0ItHSWko8vnhBwuEzE1lQdifs e/41PgsbePk5JuKALL/BVeK9NruAnx9vR8k4MWrG1ujcj5HmhTFI88guZpEXCgPn0s4N 0xmyRO/Xe4iBQYhuhClzZO6KrG8l+WDftAyUmHt6JhGA5xzf3Y95s/lSAwfO8wLqJxZv hBkw== X-Received: by 10.66.149.229 with SMTP id ud5mr36178413pab.83.1449419106969; Sun, 06 Dec 2015 08:25:06 -0800 (PST) Received: from [172.16.0.8] (ip68-8-104-248.sd.sd.cox.net. [68.8.104.248]) by smtp.gmail.com with ESMTPSA id ww5sm22529166pac.35.2015.12.06.08.25.05 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 08:25:06 -0800 (PST) Subject: Re: urtwn regression(?) from 10.2 to current r291431 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Michael Mitchell In-Reply-To: <201512061444.tB6EiPmm041204@mech-as222.men.bris.ac.uk> Date: Sun, 6 Dec 2015 08:25:04 -0800 Cc: adrian@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, hps@selasky.org Message-Id: <77A4DCE9-D720-416A-A7EE-C97EE5195E20@gmail.com> References: <201512061444.tB6EiPmm041204@mech-as222.men.bris.ac.uk> To: mexas@bris.ac.uk X-Mailer: Apple Mail (2.3096.5) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 16:25:07 -0000 i pulled the recent RPI2 r291495 from ftp.freebsd.org, and i also notice = that the urtwn usb dongle i typically use is very flakey with -CURRENT on the Raspberry Pi 2. The = symptoms sound very similar to those described on this thread. : mdm > On Dec 6, 2015, at 6:44 AM, Anton Shterenlikht = wrote: >=20 >> =46rom hps@selasky.org Sun Dec 6 14:41:27 = 2015 >>=20 >> On 12/06/15 15:14, Anton Shterenlikht wrote: >>> I posted this about a week ago: >>>=20 >>> = http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.ht= ml >>>=20 >>> The problem is that urtwn stopped >>> working in current r291431. >>>=20 >>> I did more testing with the same revision, >>> and sometimes it would work, but extremely >>> slowly, and sometimes seemingly associate >>> but get an address of 0.0.0.0. >>>=20 >>> I now installed 10.2-RELEASE-p8 and >>> the urtwn works fine, no issues at all. >>>=20 >>> Does this look like a bug at some recent >>> current revision? Should I file a PR? >>>=20 >>> I's just I recall there have been major >>> chages to wlan, so perphaps I'm forgetting >>> to change the config in recent current? >>>=20 >>> Please advise >>>=20 >>> Anton >>=20 >> Hi, >>=20 >> There is work ongoing in the WLAN drivers. Did you try the latest = -current? >>=20 >> --HPS >=20 > r291431 was about a week ago. > Will try latest -current later today. >=20 > Anton >=20 > _______________________________________________ > freebsd-current@freebsd.org = mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current = > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org = " From owner-freebsd-current@freebsd.org Sun Dec 6 15:21:28 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F71299A10C for ; Sun, 6 Dec 2015 15:21:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 E07AB1F6B for ; Sun, 6 Dec 2015 15:21:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7674 invoked from network); 6 Dec 2015 15:21:20 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 15:21:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 06 Dec 2015 10:21:22 -0500 (EST) Received: (qmail 19599 invoked from network); 6 Dec 2015 15:21:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 15:21:21 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8F3501C43BF; Sun, 6 Dec 2015 07:21:17 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix Message-Id: Date: Sun, 6 Dec 2015 07:21:19 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Mailman-Approved-At: Sun, 06 Dec 2015 16:57:35 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 15:21:28 -0000 After successfully using the likes of: env MAKEOBJDIRPREFIX=3D. . . make . . . from the usual /usr/src starting point. I tried following: > The environment of make(1) for the build can be controlled via the > SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some > examples that may only be set in this file are MAKEOBJDIRPREFIX, > WITH_DIRDEPS_BUILD, and WITH_META_MODE as they are = environment-only > variables. by using env SRC_ENV_CONF=3D. . . make . . . and having the file pointed to contain the MAKEOBJDIRPREFIX=3D. . . . This did not work. Say MAKEOBJDIRPREFIX=3D/usr/obj/xtoolchain then I'd get errors for the = likes of /usr/obj/xtoolchain/legacy/usr/lib/ not existing during an install operation during buildworld. If I forced a such legacy directory tree to exist there by copying the = empty tree from /usr/obj/xtoolchain/usr/src/tmp/legacy/. . . (that it = had created) I continued to have problems elsewhere, such as: --- _libinstall --- sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libctf.a = /usr/obj/xtoolchain/usr/lib/ install: /usr/obj/xtoolchain/usr/lib/: No such file or directory *** [_libinstall] Error code 71 In essence the dynamic, local additions to the path such as usr/src/tmp/ = sometimes end up missing. My guess is that it is picking up the MAKEOBJDIRPREFIX=3D/usr/obj/xtoolchain definition again and so replacing the built-up prefix for the local = context. May be the quoted paragraph from "man src.conf" should not suggest that = MAKEOBJDIRPREFIX is valid in a file to be referenced by SRC_ENV_CONF: > The environment of make(1) for the build can be controlled via the > SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some > examples that may only be set in this file are MAKEOBJDIRPREFIX, > WITH_DIRDEPS_BUILD, and WITH_META_MODE as they are = environment-only > variables. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Dec 6 16:59:21 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AD139A097D for ; Sun, 6 Dec 2015 16:59:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 CFA6A1456 for ; Sun, 6 Dec 2015 16:59:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tB6GxCwH084419 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 6 Dec 2015 18:59:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tB6GxCwH084419 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tB6GxCUq084418; Sun, 6 Dec 2015 18:59:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 6 Dec 2015 18:59:12 +0200 From: Konstantin Belousov To: Fabian Keil Cc: FreeBSD Current Subject: Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000 Message-ID: <20151206165912.GF2202@kib.kiev.ua> References: <20151206114532.73b1dac9@fabiankeil.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151206114532.73b1dac9@fabiankeil.de> User-Agent: Mutt/1.5.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 16:59:21 -0000 On Sun, Dec 06, 2015 at 11:45:32AM +0100, Fabian Keil wrote: > I got the following panic while trying to import a ZFS pool from a > geli-encrypted memory disk backed by a file located on a msdosfs partition: I smiled. > > (kgdb) where > #0 doadump (textdump=0) at pcpu.h:221 > #1 0xffffffff80314c1b in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533 > #2 0xffffffff80314a0e in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 > #3 0xffffffff803147a4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 > #4 0xffffffff803172ab in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:251 > #5 0xffffffff805dfe33 in kdb_trap (type=3, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff80879bc7 in trap (frame=0xfffffe009444a240) at /usr/src/sys/amd64/amd64/trap.c:549 > #7 0xffffffff8085eb77 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:234 > #8 0xffffffff805df51b in kdb_enter (why=0xffffffff8096c7fb "panic", msg=0x32
) at cpufunc.h:63 > #9 0xffffffff8059bbdf in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:750 > #10 0xffffffff8059ba33 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:688 > #11 0xffffffff8082ffb5 in vm_fault_hold (map=, vaddr=, fault_type=, fault_flags=, m_hold=) > at /usr/src/sys/vm/vm_fault.c:332 > #12 0xffffffff8082de18 in vm_fault (map=0xfffff80002000000, vaddr=, fault_type=2 '\002', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:277 > #13 0xffffffff8087a33a in trap_pfault (frame=0xfffffe009444a8e0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:734 > #14 0xffffffff80879bde in trap (frame=0xfffffe009444a8e0) at /usr/src/sys/amd64/amd64/trap.c:435 > #15 0xffffffff8085eb77 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:234 > #16 0xffffffff80877d5a in bcopy () at /usr/src/sys/amd64/amd64/support.S:118 > #17 0xffffffff805f64e8 in uiomove_faultflag (cp=, n=, uio=0xfffffe009444aae0, nofault=) at /usr/src/sys/kern/subr_uio.c:208 > #18 0xffffffff8046236f in msdosfs_read (ap=) at /usr/src/sys/fs/msdosfs/msdosfs_vnops.c:596 > #19 0xffffffff808feb20 in VOP_READ_APV (vop=, a=) at vnode_if.c:930 > #20 0xffffffff8039bf3a in mdstart_vnode (sc=0xfffff8004c7ce000, bp=0xfffff80028fc81f0) at vnode_if.h:384 >From the frame 20, do 'p *bp' in kgdb and mail the result. Do you have any non-standard values for buffer cache knobs, esp. for MAXPHYS ? > #21 0xffffffff8039a3cc in md_kthread (arg=0xfffff8004c7ce000) at /usr/src/sys/dev/md/md.c:979 > #22 0xffffffff8055978c in fork_exit (callout=0xffffffff8039a1a0 , arg=0xfffff8004c7ce000, frame=0xfffffe009444ac00) at /usr/src/sys/kern/kern_fork.c:1011 > #23 0xffffffff8085f0ae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:609 > #24 0x0000000000000000 in ?? () > Current language: auto; currently minimal > > This is the second time I've seen this, the first time was with a kernel > based on r290573 in November, but as I wasn't able to intentionally reproduce > it with a more recent kernel my assumption was that the problem had already > been fixed. > > Currently my kernel is based on r291706. > > Any ideas? > > Fabian From owner-freebsd-current@freebsd.org Sun Dec 6 17:29:44 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 053969A0016; Sun, 6 Dec 2015 17:29:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 CA4E513A6; Sun, 6 Dec 2015 17:29:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioc74 with SMTP id 74so160542707ioc.2; Sun, 06 Dec 2015 09:29:43 -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=B9G0BNAEvWxvSFu49mMWHQo2WFkn7uYQdLBdpN55rik=; b=w7v7rH12e6AslKWzj6KZCFFxGfD5KlrbCsnKPIdLFuXUoOwaxDTcSCDUn3+s6Qy8AQ +wH98Tv/uq0dx81msO4N4RybZMqqZe+McF/KNlBVic4YR0od2ZAK8WyGAE9of15d1boC CtM6zrFJ0GdWr20a6lAedmf9uJZoPUODJJNaCHSVfHncQtfxNSQgLb1ddZsnoJR+KHCy DaCRG7VyQVCMedCZAx7LwZrh2+XXDB0TCaZbhR24rk8vKtvCzLpmkZtH6HpjIT3pSrc3 05lQfILPKpehOP2eouxP0SFh6R126P2luBtdxaCsW2xh5mbOgN4m91QcZXy8xUoVibX9 mxvg== MIME-Version: 1.0 X-Received: by 10.107.10.199 with SMTP id 68mr22102406iok.75.1449422983304; Sun, 06 Dec 2015 09:29:43 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.217.196 with HTTP; Sun, 6 Dec 2015 09:29:43 -0800 (PST) In-Reply-To: <77A4DCE9-D720-416A-A7EE-C97EE5195E20@gmail.com> References: <201512061444.tB6EiPmm041204@mech-as222.men.bris.ac.uk> <77A4DCE9-D720-416A-A7EE-C97EE5195E20@gmail.com> Date: Sun, 6 Dec 2015 09:29:43 -0800 X-Google-Sender-Auth: pDlUHJNcbfD7J5WI4FA9df0jxME Message-ID: Subject: Re: urtwn regression(?) from 10.2 to current r291431 From: Adrian Chadd To: Michael Mitchell , "freebsd-wireless@freebsd.org" , Andriy Voskoboinyk Cc: Anton Shterenlikht , freebsd-current , FreeBSD Stable Mailing List , Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 17:29:44 -0000 hiya, +wireless, +andriy Andriy has been working on adding lots of new things to urtwn and tidying it up. It's possible he's introduced some regressions. Just check in on the wireless list and join #freebsd-wireless on efnet to ask questions. Hopefully it was fixed a couple days ago with the TX fixes he did; otherwise he has more work cut out for him. :) Thanks for reporting the regressions so quickly! -a On 6 December 2015 at 08:25, Michael Mitchell wrote: > i pulled the recent RPI2 r291495 from ftp.freebsd.org, and i also notice > that the urtwn usb dongle > i typically use is very flakey with -CURRENT on the Raspberry Pi 2. The > symptoms sound very > similar to those described on this thread. > > : mdm > > On Dec 6, 2015, at 6:44 AM, Anton Shterenlikht wrote: > > From hps@selasky.org Sun Dec 6 14:41:27 2015 > > On 12/06/15 15:14, Anton Shterenlikht wrote: > > I posted this about a week ago: > > http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html > > The problem is that urtwn stopped > working in current r291431. > > I did more testing with the same revision, > and sometimes it would work, but extremely > slowly, and sometimes seemingly associate > but get an address of 0.0.0.0. > > I now installed 10.2-RELEASE-p8 and > the urtwn works fine, no issues at all. > > Does this look like a bug at some recent > current revision? Should I file a PR? > > I's just I recall there have been major > chages to wlan, so perphaps I'm forgetting > to change the config in recent current? > > Please advise > > Anton > > > Hi, > > There is work ongoing in the WLAN drivers. Did you try the latest -current? > > --HPS > > > r291431 was about a week ago. > Will try latest -current later today. > > Anton > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@freebsd.org Sun Dec 6 16:33:05 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BF099A0539 for ; Sun, 6 Dec 2015 16:33:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (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 31EA31BF1 for ; Sun, 6 Dec 2015 16:33:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4496 invoked from network); 6 Dec 2015 16:32:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 16:32:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 06 Dec 2015 11:32:58 -0500 (EST) Received: (qmail 23724 invoked from network); 6 Dec 2015 16:32:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 16:32:58 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E51061C43BF; Sun, 6 Dec 2015 08:32:54 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT (on powerpc64) WITH_CCACHE_BUILD= : example failure Message-Id: Date: Sun, 6 Dec 2015 08:32:57 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Mailman-Approved-At: Sun, 06 Dec 2015 17:42:57 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 16:33:05 -0000 Mostly just an FYI: This means that for my own purposes I'll tend to = avoid WITH_CCACHE_BUILD=3D for now. . . Context vintage: > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #17 r291745M: Sat = Dec 5 08:20:20 PST 2015 = root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc = 1100091 1100091 I took a working make command for buildworld and added > env CCACHE_DIR=3D/var/tmp/ccache and > WITH_CCACHE_BUILD=3D and then tried to repeat the build. The result was: > --- lib_gen.o --- > /usr/local/bin/ccache /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = -O2 -pipe -isystem /usr/obj/usr/src/tmp/usr/include/. -Wl,-rpath-link = -Wl,/usr/obj/usr/src/tmp/usr/lib/. -Wl,-rpath-link = -Wl,/usr/obj/usr/src/tmp/lib/. -L/usr/obj/usr/src/tmp/usr/lib/. = -L/usr/obj/usr/src/tmp/lib/. -I. = -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include = -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall = -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -MD -MP = -MF.depend.lib_gen.o -MTlib_gen.o -std=3Dgnu99 -fstack-protector-strong = -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c lib_gen.c -o lib_gen.o . . . > --- lib_gen.o --- > _67737.c:754:3: error: "_Bool" after # is not a positive integer > In file included from = /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/curses.priv.= h:313:0, > from lib_gen.c:19: > _67737.c:755:2: error: expected ')' before 'int' The make command was: > env CCACHE_DIR=3D/var/tmp/ccache make -j 6 \ > WITH_FAST_DEPEND=3D WITH_CCACHE_BUILD=3D \ > CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITH_LIBCPLUSPLUS=3D \ > WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D \ > WITHOUT_CLANG_EXTRAS=3D \ > WITH_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 [Yes, I'm using powerpc64-xtoolchain-gcc/powerpc64-gcc on a powerpc64 = machine (PowerMac G5), no gcc 4.2.1 present and clang 3.7 unused for the = build: powerpc64-gcc is also in use as a system tool chain, not just as = the "self hosted" cross toolchain.] Removing > env CCACHE_DIR=3D/var/tmp/ccache and > WITH_CCACHE_BUILD=3D and then repeating went back to working again. I actually went back and = forth more than once and tested with and without WITH_FAST_DEPEND=3D as = I was experimenting with both. The reported behavior was uniform over = this activity. The ports vintage powerpc64-xtoolchain-gcc/powerpc64-gcc and other = things are from: > # svnlite info /usr/ports/ > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 402906 > Node Kind: directory > Schedule: normal > Last Changed Author: wen > Last Changed Rev: 402906 > Last Changed Date: 2015-12-03 18:06:07 -0800 (Thu, 03 Dec 2015) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Dec 6 17:51:52 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CD999A07BE for ; Sun, 6 Dec 2015 17:51:52 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (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 E813818F1 for ; Sun, 6 Dec 2015 17:51:51 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.170.80] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1a5dTK-00018L-40; Sun, 06 Dec 2015 18:51:42 +0100 Date: Sun, 6 Dec 2015 18:51:36 +0100 From: Fabian Keil To: Konstantin Belousov Cc: FreeBSD Current Subject: Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000 Message-ID: <20151206185136.2ff4f519@fabiankeil.de> In-Reply-To: <20151206165912.GF2202@kib.kiev.ua> References: <20151206114532.73b1dac9@fabiankeil.de> <20151206165912.GF2202@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/cH4SBd3I0heENntInHA/Bf1"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 17:51:52 -0000 --Sig_/cH4SBd3I0heENntInHA/Bf1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Konstantin Belousov wrote: > On Sun, Dec 06, 2015 at 11:45:32AM +0100, Fabian Keil wrote: > > I got the following panic while trying to import a ZFS pool from a > > geli-encrypted memory disk backed by a file located on a msdosfs partit= ion: =20 > I smiled. I occasionally use this somewhat non-standard setup to store redundant backups on a media player whose bootloader may not be prepared to deal with multiple partitions ... > > (kgdb) where > > #0 doadump (textdump=3D0) at pcpu.h:221 > > #1 0xffffffff80314c1b in db_dump (dummy=3D, dummy= 2=3Dfalse, dummy3=3D0, dummy4=3D0x0) at /usr/src/sys/ddb/db_command.c:533 > > #2 0xffffffff80314a0e in db_command (cmd_table=3D0x0) at /usr/src/sys/= ddb/db_command.c:440 > > #3 0xffffffff803147a4 in db_command_loop () at /usr/src/sys/ddb/db_com= mand.c:493 > > #4 0xffffffff803172ab in db_trap (type=3D, code= =3D0) at /usr/src/sys/ddb/db_main.c:251 > > #5 0xffffffff805dfe33 in kdb_trap (type=3D3, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 > > #6 0xffffffff80879bc7 in trap (frame=3D0xfffffe009444a240) at /usr/src= /sys/amd64/amd64/trap.c:549 > > #7 0xffffffff8085eb77 in calltrap () at /usr/src/sys/amd64/amd64/excep= tion.S:234 > > #8 0xffffffff805df51b in kdb_enter (why=3D0xffffffff8096c7fb "panic", = msg=3D0x32
) at cpufunc.h:63 > > #9 0xffffffff8059bbdf in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:750 > > #10 0xffffffff8059ba33 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_s= hutdown.c:688 > > #11 0xffffffff8082ffb5 in vm_fault_hold (map=3D, v= addr=3D, fault_type=3D, fault_fla= gs=3D, m_hold=3D) > > at /usr/src/sys/vm/vm_fault.c:332 > > #12 0xffffffff8082de18 in vm_fault (map=3D0xfffff80002000000, vaddr=3D<= value optimized out>, fault_type=3D2 '\002', fault_flags=3D0) at /usr/src/s= ys/vm/vm_fault.c:277 > > #13 0xffffffff8087a33a in trap_pfault (frame=3D0xfffffe009444a8e0, user= mode=3D0) at /usr/src/sys/amd64/amd64/trap.c:734 > > #14 0xffffffff80879bde in trap (frame=3D0xfffffe009444a8e0) at /usr/src= /sys/amd64/amd64/trap.c:435 > > #15 0xffffffff8085eb77 in calltrap () at /usr/src/sys/amd64/amd64/excep= tion.S:234 > > #16 0xffffffff80877d5a in bcopy () at /usr/src/sys/amd64/amd64/support.= S:118 > > #17 0xffffffff805f64e8 in uiomove_faultflag (cp=3D= , n=3D, uio=3D0xfffffe009444aae0, nofault=3D) at /usr/src/sys/kern/subr_uio.c:208 > > #18 0xffffffff8046236f in msdosfs_read (ap=3D) at = /usr/src/sys/fs/msdosfs/msdosfs_vnops.c:596 > > #19 0xffffffff808feb20 in VOP_READ_APV (vop=3D, a= =3D) at vnode_if.c:930 > > #20 0xffffffff8039bf3a in mdstart_vnode (sc=3D0xfffff8004c7ce000, bp=3D= 0xfffff80028fc81f0) at vnode_if.h:384 =20 > From the frame 20, do 'p *bp' in kgdb and mail the result. Do you have > any non-standard values for buffer cache knobs, esp. for MAXPHYS ? (kgdb) p *bp $1 =3D {bio_cmd =3D 1 '\001', bio_flags =3D 16 '\020', bio_cflags =3D 0 '\0= ', bio_pflags =3D 0 '\0', bio_dev =3D 0x0, bio_disk =3D 0x0, bio_offset =3D= 0, bio_bcount =3D 0,=20 bio_data =3D 0xfffffe0077d94000
, bio_ma =3D 0xfffff8000275bc00, bio_ma_offset =3D 960, bio_ma_n =3D 33, b= io_error =3D 0, bio_resid =3D 0,=20 bio_done =3D 0xffffffff804e51d0 , bio_driver1 =3D 0x0, bio_dr= iver2 =3D 0x0, bio_caller1 =3D 0x0, bio_caller2 =3D 0x0, bio_queue =3D {tqe= _next =3D 0x0, tqe_prev =3D 0xfffff8004c7ce018}, bio_attribute =3D 0x0,=20 bio_from =3D 0xfffff80010131d80, bio_to =3D 0xfffff800694f2a00, bio_lengt= h =3D 131072, bio_completed =3D 0, bio_children =3D 0, bio_inbed =3D 0, bio= _parent =3D 0xfffff8000628bd90, bio_t0 =3D {sec =3D 33029,=20 frac =3D 13163670047247984455}, bio_task =3D 0, bio_task_arg =3D 0x0, b= io_classifier1 =3D 0x0, bio_classifier2 =3D 0x0, bio_pblkno =3D 0} =20 I don't use non-standard values for MAXPHYS or other buffer cache settings. Fabian --Sig_/cH4SBd3I0heENntInHA/Bf1 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZkdaoACgkQBYqIVf93VJ30IwCeJdwatpMq5iVJNJZeG1JhlNHH oc8AoLukijIAnW3/j4Ac25lQp5mHRYRC =i0VI -----END PGP SIGNATURE----- --Sig_/cH4SBd3I0heENntInHA/Bf1-- From owner-freebsd-current@freebsd.org Sun Dec 6 18:57:43 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 436499A06F7 for ; Sun, 6 Dec 2015 18:57:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 E20B415EE for ; Sun, 6 Dec 2015 18:57:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tB6IvaNX012913 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 6 Dec 2015 20:57:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tB6IvaNX012913 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tB6Iva9g012912; Sun, 6 Dec 2015 20:57:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 6 Dec 2015 20:57:36 +0200 From: Konstantin Belousov To: Fabian Keil Cc: FreeBSD Current Subject: Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000 Message-ID: <20151206185736.GG2202@kib.kiev.ua> References: <20151206114532.73b1dac9@fabiankeil.de> <20151206165912.GF2202@kib.kiev.ua> <20151206185136.2ff4f519@fabiankeil.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151206185136.2ff4f519@fabiankeil.de> User-Agent: Mutt/1.5.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 18:57:43 -0000 On Sun, Dec 06, 2015 at 06:51:36PM +0100, Fabian Keil wrote: > > > #16 0xffffffff80877d5a in bcopy () at /usr/src/sys/amd64/amd64/support.S:118 > > > #17 0xffffffff805f64e8 in uiomove_faultflag (cp=, n=, uio=0xfffffe009444aae0, nofault=) at /usr/src/sys/kern/subr_uio.c:208 > > > #18 0xffffffff8046236f in msdosfs_read (ap=) at /usr/src/sys/fs/msdosfs/msdosfs_vnops.c:596 > > > #19 0xffffffff808feb20 in VOP_READ_APV (vop=, a=) at vnode_if.c:930 > > > #20 0xffffffff8039bf3a in mdstart_vnode (sc=0xfffff8004c7ce000, bp=0xfffff80028fc81f0) at vnode_if.h:384 > > From the frame 20, do 'p *bp' in kgdb and mail the result. Do you have > > any non-standard values for buffer cache knobs, esp. for MAXPHYS ? > > (kgdb) p *bp > $1 = {bio_cmd = 1 '\001', bio_flags = 16 '\020', bio_cflags = 0 '\0', bio_pflags = 0 '\0', bio_dev = 0x0, bio_disk = 0x0, bio_offset = 0, bio_bcount = 0, > bio_data = 0xfffffe0077d94000
, bio_ma = 0xfffff8000275bc00, bio_ma_offset = 960, bio_ma_n = 33, This is the issue. The upper layer (ZFS ?) passed down the request which is max-sized (see bio_length == 32 pages) but not aligned. The physical buffer used for transient mapping cannot handle this. bio_error = 0, bio_resid = 0, > bio_done = 0xffffffff804e51d0 , bio_driver1 = 0x0, bio_driver2 = 0x0, bio_caller1 = 0x0, bio_caller2 = 0x0, bio_queue = {tqe_next = 0x0, tqe_prev = 0xfffff8004c7ce018}, bio_attribute = 0x0, > bio_from = 0xfffff80010131d80, bio_to = 0xfffff800694f2a00, bio_length = 131072, bio_completed = 0, bio_children = 0, bio_inbed = 0, bio_parent = 0xfffff8000628bd90, bio_t0 = {sec = 33029, > frac = 13163670047247984455}, bio_task = 0, bio_task_arg = 0x0, bio_classifier1 = 0x0, bio_classifier2 = 0x0, bio_pblkno = 0} > > I don't use non-standard values for MAXPHYS or other buffer cache settings. > Try the following patch. diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c index a47066e..52142ed 100644 --- a/sys/dev/md/md.c +++ b/sys/dev/md/md.c @@ -836,8 +836,8 @@ mdstart_vnode(struct md_s *sc, struct bio *bp) struct buf *pb; bus_dma_segment_t *vlist; struct thread *td; - off_t len, zerosize; - int ma_offs; + off_t iolen, len, zerosize; + int ma_offs, npages; switch (bp->bio_cmd) { case BIO_READ: @@ -858,6 +858,7 @@ mdstart_vnode(struct md_s *sc, struct bio *bp) pb = NULL; piov = NULL; ma_offs = bp->bio_ma_offset; + len = bp->bio_length; /* * VNODE I/O @@ -890,7 +891,6 @@ mdstart_vnode(struct md_s *sc, struct bio *bp) auio.uio_iovcnt = howmany(bp->bio_length, zerosize); piov = malloc(sizeof(*piov) * auio.uio_iovcnt, M_MD, M_WAITOK); auio.uio_iov = piov; - len = bp->bio_length; while (len > 0) { piov->iov_base = __DECONST(void *, zero_region); piov->iov_len = len; @@ -904,7 +904,6 @@ mdstart_vnode(struct md_s *sc, struct bio *bp) piov = malloc(sizeof(*piov) * bp->bio_ma_n, M_MD, M_WAITOK); auio.uio_iov = piov; vlist = (bus_dma_segment_t *)bp->bio_data; - len = bp->bio_length; while (len > 0) { piov->iov_base = (void *)(uintptr_t)(vlist->ds_addr + ma_offs); @@ -920,11 +919,20 @@ mdstart_vnode(struct md_s *sc, struct bio *bp) piov = auio.uio_iov; } else if ((bp->bio_flags & BIO_UNMAPPED) != 0) { pb = getpbuf(&md_vnode_pbuf_freecnt); - pmap_qenter((vm_offset_t)pb->b_data, bp->bio_ma, bp->bio_ma_n); - aiov.iov_base = (void *)((vm_offset_t)pb->b_data + ma_offs); - aiov.iov_len = bp->bio_length; + bp->bio_resid = len; +unmapped_step: + npages = min(MAXPHYS, roundup2(len + ma_offs, PAGE_SIZE)) / + PAGE_SIZE; + iolen = min(npages * PAGE_SIZE - ma_offs, len); + KASSERT(iolen > 0, ("zero iolen")); + pmap_qenter((vm_offset_t)pb->b_data, + &bp->bio_ma[ma_offs / PAGE_SIZE], npages); + aiov.iov_base = (void *)((vm_offset_t)pb->b_data + + ma_offs % PAGE_SIZE); + aiov.iov_len = iolen; auio.uio_iov = &aiov; auio.uio_iovcnt = 1; + auio.uio_resid = aiov.iov_len; } else { aiov.iov_base = bp->bio_data; aiov.iov_len = bp->bio_length; @@ -948,15 +956,21 @@ mdstart_vnode(struct md_s *sc, struct bio *bp) vn_finished_write(mp); } - if (pb) { - pmap_qremove((vm_offset_t)pb->b_data, bp->bio_ma_n); + if (pb != NULL) { + pmap_qremove((vm_offset_t)pb->b_data, npages); + if (error == 0) { + len -= iolen; + bp->bio_resid -= iolen; + ma_offs += iolen; + if (len > 0) + goto unmapped_step; + } relpbuf(pb, &md_vnode_pbuf_freecnt); } - if (piov != NULL) - free(piov, M_MD); - - bp->bio_resid = auio.uio_resid; + free(piov, M_MD); + if (pb == NULL) + bp->bio_resid = auio.uio_resid; return (error); } From owner-freebsd-current@freebsd.org Sun Dec 6 16:39:37 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B9DD9A05E7 for ; Sun, 6 Dec 2015 16:39:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 49FCB1CFD for ; Sun, 6 Dec 2015 16:39:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28384 invoked from network); 6 Dec 2015 16:39:39 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 16:39:39 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 06 Dec 2015 11:39:38 -0500 (EST) Received: (qmail 13932 invoked from network); 6 Dec 2015 16:39:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 16:39:38 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C43BC1C43D5; Sun, 6 Dec 2015 08:39:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 11.0-CURRENT (on powerpc64) WITH_CCACHE_BUILD= : example failure From: Mark Millard In-Reply-To: Date: Sun, 6 Dec 2015 08:39:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <24874B49-5D3A-4617-8DDA-B3F25E2419A4@dsl-only.net> References: To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.2104) X-Mailman-Approved-At: Sun, 06 Dec 2015 19:41:28 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 16:39:37 -0000 I'm adding a note about the missing "\" being just an E-mail editing = error, not an original command error. . . On 2015-Dec-6, at 8:32 AM, Mark Millard wrote: > Mostly just an FYI: This means that for my own purposes I'll tend to = avoid WITH_CCACHE_BUILD=3D for now. . . >=20 > Context vintage: >=20 >> # freebsd-version -ku; uname -aKU >> 11.0-CURRENT >> 11.0-CURRENT >> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #17 r291745M: Sat = Dec 5 08:20:20 PST 2015 = root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc = 1100091 1100091 >=20 > I took a working make command for buildworld and added >=20 >> env CCACHE_DIR=3D/var/tmp/ccache >=20 > and >=20 >> WITH_CCACHE_BUILD=3D >=20 > and then tried to repeat the build. The result was: >=20 >> --- lib_gen.o --- >> /usr/local/bin/ccache = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -O2 -pipe -isystem = /usr/obj/usr/src/tmp/usr/include/. -Wl,-rpath-link = -Wl,/usr/obj/usr/src/tmp/usr/lib/. -Wl,-rpath-link = -Wl,/usr/obj/usr/src/tmp/lib/. -L/usr/obj/usr/src/tmp/usr/lib/. = -L/usr/obj/usr/src/tmp/lib/. -I. = -I/usr/obj/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../ncurses = -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include = -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall = -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -MD -MP = -MF.depend.lib_gen.o -MTlib_gen.o -std=3Dgnu99 -fstack-protector-strong = -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c lib_gen.c -o lib_gen.o > . . . >> --- lib_gen.o --- >> _67737.c:754:3: error: "_Bool" after # is not a positive integer >> In file included from = /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/curses.priv.= h:313:0, >> from lib_gen.c:19: >> _67737.c:755:2: error: expected ')' before 'int' >=20 >=20 > The make command was: >=20 >> env CCACHE_DIR=3D/var/tmp/ccache make -j 6 \ >> WITH_FAST_DEPEND=3D WITH_CCACHE_BUILD=3D \ >> CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ >> WITH_LIBCPLUSPLUS=3D \ >> WITHOUT_CLANG_BOOTSTRAP=3D >> WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D \ >> WITHOUT_CLANG_EXTRAS=3D \ >> WITH_LLDB=3D \ >> WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D \ >> WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ >> buildworld buildkernel \ >> KERNCONF=3DGENERIC64vtsc-NODEBUG \ >> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 >=20 Note: The missing \ after ". . . BOOTSTRAP=3D " is my mail-editing = error, not a problem with the original command. > [Yes, I'm using powerpc64-xtoolchain-gcc/powerpc64-gcc on a powerpc64 = machine (PowerMac G5), no gcc 4.2.1 present and clang 3.7 unused for the = build: powerpc64-gcc is also in use as a system tool chain, not just as = the "self hosted" cross toolchain.] >=20 > Removing >=20 >> env CCACHE_DIR=3D/var/tmp/ccache >=20 > and >=20 >> WITH_CCACHE_BUILD=3D >=20 > and then repeating went back to working again. I actually went back = and forth more than once and tested with and without WITH_FAST_DEPEND=3D = as I was experimenting with both. The reported behavior was uniform over = this activity. >=20 > The ports vintage powerpc64-xtoolchain-gcc/powerpc64-gcc and other = things are from: >=20 >> # svnlite info /usr/ports/ >> Path: /usr/ports >> Working Copy Root Path: /usr/ports >> URL: https://svn0.us-west.freebsd.org/ports/head >> Relative URL: ^/head >> Repository Root: https://svn0.us-west.freebsd.org/ports >> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >> Revision: 402906 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: wen >> Last Changed Rev: 402906 >> Last Changed Date: 2015-12-03 18:06:07 -0800 (Thu, 03 Dec 2015) >=20 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Dec 6 21:34:40 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 597799A0DAE for ; Sun, 6 Dec 2015 21:34:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 02B79187F for ; Sun, 6 Dec 2015 21:34:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21533 invoked from network); 6 Dec 2015 21:34:37 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 21:34:37 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 06 Dec 2015 16:34:39 -0500 (EST) Received: (qmail 7146 invoked from network); 6 Dec 2015 21:34:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Dec 2015 21:34:38 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id EE6E01C43AE; Sun, 6 Dec 2015 13:34:32 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling Message-Id: <867D2B14-766D-4104-9A77-C35992C357B8@dsl-only.net> Date: Sun, 6 Dec 2015 13:34:36 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current , freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 21:34:40 -0000 [I picked the lists that I did because powerpc64-gcc is the external = toolchain created to allow modern powerpc64 builds.] For the powerpc64-gcc 5.2 vintages. . . (using my environment's path as = an example) = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config= /rs6000/freebsd64.h has: > /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults = instead. */ > #undef WCHAR_TYPE > #define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 That type in quotes ends up being the base type for L". . ." notation, = for example. Probably the char notation as well (L'?'). For FreeBSD Char compatibility in a powerpc64 lib32 context that "long = int" should effectively instead be "int", making the conditional above = technically unnecessary. This blocks compiling lib32 source code that uses such notations as L". = . .": "long int" is not compatible with FreeBSD's Char in the powerpc64 = environment's 32 bit environment. Some compiler message are explicit = about the base types of pointers that result for the mismatches: that is = how I know that "long int" is in use for L". . ." and "int" is the other = base type involved. (Yes, freebsd64.h appears to be used for lib32, at least on powerpc64. = By contrast freebsd.h agrees for the WCHAR_TYPE_SIZE but only undef's = WCHAR_TYPE, presuming gcc defaults are correct for FreeBSD as far as the = type goes. It might need a more explicit type to be sure of a Char match = for that freebsd.h file's context.) The 4.9 vintages of powerpc64-gcc were messed up the same way, as was = noted at the time. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Dec 6 22:44:16 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C7D29A0C24; Sun, 6 Dec 2015 22:44:16 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (unknown [IPv6:2001:4060:1:1001::14:53]) (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 441F217AE; Sun, 6 Dec 2015 22:44:16 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from [192.168.225.14] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fgznet.ch (Postfix) with ESMTPS id 79AA5CF0E8; Sun, 6 Dec 2015 23:44:02 +0100 (CET) Subject: Re: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling To: Mark Millard , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current , freebsd-ports@freebsd.org References: <867D2B14-766D-4104-9A77-C35992C357B8@dsl-only.net> From: Andreas Tobler Message-ID: <5664BA32.3010306@fgznet.ch> Date: Sun, 6 Dec 2015 23:44:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <867D2B14-766D-4104-9A77-C35992C357B8@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 127.0.1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 22:44:16 -0000 On 06.12.15 22:34, Mark Millard wrote: > [I picked the lists that I did because powerpc64-gcc is the external > toolchain created to allow modern powerpc64 builds.] > > For the powerpc64-gcc 5.2 vintages. . . (using my environment's path > as an example) > > /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config/rs6000/freebsd64.h > has: > >> /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults >> instead. */ #undef WCHAR_TYPE #define WCHAR_TYPE >> (TARGET_64BIT ? "int" : "long int") #undef WCHAR_TYPE_SIZE #define >> WCHAR_TYPE_SIZE 32 > > That type in quotes ends up being the base type for L". . ." > notation, for example. Probably the char notation as well (L'?'). > > For FreeBSD Char compatibility in a powerpc64 lib32 context that > "long int" should effectively instead be "int", making the > conditional above technically unnecessary. > > This blocks compiling lib32 source code that uses such notations as > L". . .": "long int" is not compatible with FreeBSD's Char in the > powerpc64 environment's 32 bit environment. Some compiler message are > explicit about the base types of pointers that result for the > mismatches: that is how I know that "long int" is in use for L". . ." > and "int" is the other base type involved. > > (Yes, freebsd64.h appears to be used for lib32, at least on > powerpc64. By contrast freebsd.h agrees for the WCHAR_TYPE_SIZE but > only undef's WCHAR_TYPE, presuming gcc defaults are correct for > FreeBSD as far as the type goes. It might need a more explicit type > to be sure of a Char match for that freebsd.h file's context.) > > The 4.9 vintages of powerpc64-gcc were messed up the same way, as was > noted at the time. I'll take care. Andreas From owner-freebsd-current@freebsd.org Sun Dec 6 22:58:54 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF3679A00DD for ; Sun, 6 Dec 2015 22:58:54 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 61BCE1DF0 for ; Sun, 6 Dec 2015 22:58:54 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: by wmww144 with SMTP id w144so120152874wmw.1 for ; Sun, 06 Dec 2015 14:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bris-ac-uk.20150623.gappssmtp.com; s=20150623; h=date:from:message-id:to:subject:reply-to; bh=RuzCsIm3z2clB/8C0Lq/rISY5Yfrt2i227OJQAKDLe0=; b=posgYuVQ6JPwVoD20VGzUO7Pdnp3ZeJMTDNkoCK4G5gHYZYJ2212KRzrawfWSUVf+b l4QOg9JVGRYGiMYau4BPU4W+ykwCRySNV+ag8VdmquBCi26LF4FXKrbHaYoY7YySpklU ZUC/D/qd0KzTLQ2OQCULuH5yCdgCMWAgyON0pP0tps9VrKnTxa1wfAI/bIE4oRjrJ2mi 8LEsN1q46rkuioONqQtXkGnY20DzU80G20vk+HHLBm4GYP+g4tbKO8+purNheKVZbtqm vy+qmUemtV3ZFNw5ACqUU0RYU5PHyHULH/sTZcVltCAskOhAMcpj4Z3hA4Td5o+0eiSH VTMw== 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=RuzCsIm3z2clB/8C0Lq/rISY5Yfrt2i227OJQAKDLe0=; b=I6mdIvIEi+J0WsbP5U53HFxiio0dxpeY+bPpmecp4m5X4HK77p8fVq9CvhaxMMcOmL 1KH+m1y5nobTbxSvycT5WK9o/M93b61Cy89gs1/k0rfJp0ETcp5XaVH6RSaiQaoGX6b/ 5/kL31YyLr1U26QNSOvy3BQjYLARZ+6fd3IrJvJYPmH/bXHKhry0S3yVz1mkc19TXWn7 0TsomlZQEx+/z1JjpT4m5bQmak5zV1pl4yA8HPDDXOXJWNKvYjK2QUU2h0UTldtTkx7S poS9ZggoTfsA3C+oHBwYSKPx7F6ROxSjQIhYTOdtCIH7qPascyscYUul4V72UvbvPJ/l sgEA== X-Gm-Message-State: ALoCoQk6YFUPc4ntNI99x/krNgshp2Wq1lfTXVAuKurokYFZESZ4HRfnXWHUczEhTZ4113gl5Ykb X-Received: by 10.194.80.101 with SMTP id q5mr35346790wjx.59.1449442731722; Sun, 06 Dec 2015 14:58:51 -0800 (PST) Received: from mech-as222.men.bris.ac.uk (mech-as222.men.bris.ac.uk. [137.222.170.4]) by smtp.gmail.com with ESMTPSA id d2sm22431482wjy.16.2015.12.06.14.58.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Dec 2015 14:58:51 -0800 (PST) Date: Sun, 06 Dec 2015 14:58:51 -0800 (PST) X-Google-Original-Date: Sun, 6 Dec 2015 22:58:50 GMT Received: from mech-as222.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2) with ESMTP id tB6MwoBv043401; Sun, 6 Dec 2015 22:58:50 GMT (envelope-from mexas@mech-as222.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2/Submit) id tB6MwoAX043400; Sun, 6 Dec 2015 22:58:50 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201512062258.tB6MwoAX043400@mech-as222.men.bris.ac.uk> To: freebsd-current@freebsd.org, freebsd-wireless@freebsd.org Subject: seems to be solved in r291907: WAS: Re: urtwn regression(?) from 10.2 to current r291431 Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 06 Dec 2015 22:58:55 -0000 >From mexas Sun Dec 6 14:44:25 2015 >To: adrian@freebsd.org, freebsd-current@freebsd.org, > freebsd-stable@freebsd.org, hps@selasky.org, mexas@bris.ac.uk >Subject: Re: urtwn regression(?) from 10.2 to current r291431 >Reply-To: mexas@bris.ac.uk >In-Reply-To: <5664472E.3090601@selasky.org> > >>From hps@selasky.org Sun Dec 6 14:41:27 2015 >> >>On 12/06/15 15:14, Anton Shterenlikht wrote: >>> I posted this about a week ago: >>> >>> http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html >>> >>> The problem is that urtwn stopped >>> working in current r291431. >>> >>> I did more testing with the same revision, >>> and sometimes it would work, but extremely >>> slowly, and sometimes seemingly associate >>> but get an address of 0.0.0.0. >>> >>> I now installed 10.2-RELEASE-p8 and >>> the urtwn works fine, no issues at all. >>> >>> Does this look like a bug at some recent >>> current revision? Should I file a PR? >>> >>> I's just I recall there have been major >>> chages to wlan, so perphaps I'm forgetting >>> to change the config in recent current? >>> >>> Please advise >>> >>> Anton >> >>Hi, >> >>There is work ongoing in the WLAN drivers. Did you try the latest -current? >> >>--HPS > >r291431 was about a week ago. >Will try latest -current later today. Seems to be solved in r291907. Can anybody reproduce this? Anton From owner-freebsd-current@freebsd.org Mon Dec 7 08:50:56 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD3959B7A55 for ; Mon, 7 Dec 2015 08:50:56 +0000 (UTC) (envelope-from guru@unixarea.de) 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 93E561B43 for ; Mon, 7 Dec 2015 08:50:56 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [93.104.2.212] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1a5rVN-0001iA-Lf for freebsd-current@freebsd.org; Mon, 07 Dec 2015 09:50:45 +0100 Received: from localhost.my.domain (c720-r285885-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id tB78ohBA003080 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 7 Dec 2015 09:50:44 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id tB78oh9v003079 for freebsd-current@freebsd.org; Mon, 7 Dec 2015 09:50:43 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 7 Dec 2015 09:50:43 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: pkg does not update the repo catalogue Message-ID: <20151207085043.GA3047@c720-r285885-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 11.0-CURRENT r285885 (amd64) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.2.212 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 08:50:56 -0000 Hello, This is with 11-CURRENT and ports from July this year; I have the packages which I build with poudriere on some other host in a dir /usr/PKGDIR.20150726 and added 8 new packages there, the total number is now 1691: # ls *.txz | egrep -v 'packagesite.txz|meta.txz|digests.txz' | wc -l 1691 My repo definition is: # cat /usr/local/etc/pkg/repos/myrepo.conf FreeBSD: { url: "file:/usr/PKGDIR.20150726", enabled: true, } When I now want to update the 8 new packages to the repo catalogue, they are not added (i.e. the number stays with 1683 and I also can not install them with 'pkg instal ...'): # pkg -v 1.5.5 # pkg -R /usr/local/etc/pkg/repos/ update -f Updating FreeBSD repository catalogue... Fetching meta.txz: 100% 260 B 0.3kB/s 00:01 Fetching packagesite.txz: 100% 382 KiB 391.6kB/s 00:01 Processing entries: 100% FreeBSD repository update completed. 1683 packages processed. What I'm missing here? Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, 🌐 http://www.unixarea.de/ ☎ +49-176-38902045 From owner-freebsd-current@freebsd.org Mon Dec 7 09:46:24 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD9F69A0CA1 for ; Mon, 7 Dec 2015 09:46:24 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (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 4498B13B5 for ; Mon, 7 Dec 2015 09:46:24 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.182.168] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1a5sN6-0001YD-Oo; Mon, 07 Dec 2015 10:46:16 +0100 Date: Mon, 7 Dec 2015 10:44:36 +0100 From: Fabian Keil To: Konstantin Belousov Cc: FreeBSD Current Subject: Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000 Message-ID: <20151207104436.44b3ec26@fabiankeil.de> In-Reply-To: <20151206185736.GG2202@kib.kiev.ua> References: <20151206114532.73b1dac9@fabiankeil.de> <20151206165912.GF2202@kib.kiev.ua> <20151206185136.2ff4f519@fabiankeil.de> <20151206185736.GG2202@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/DX2cufYBAYSOEq99V_mNkFc"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 09:46:24 -0000 --Sig_/DX2cufYBAYSOEq99V_mNkFc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Konstantin Belousov wrote: > On Sun, Dec 06, 2015 at 06:51:36PM +0100, Fabian Keil wrote: > > > > #16 0xffffffff80877d5a in bcopy () at /usr/src/sys/amd64/amd64/supp= ort.S:118 > > > > #17 0xffffffff805f64e8 in uiomove_faultflag (cp=3D, n=3D, uio=3D0xfffffe009444aae0, nofault=3D) at /usr/src/sys/kern/subr_uio.c:208 > > > > #18 0xffffffff8046236f in msdosfs_read (ap=3D)= at /usr/src/sys/fs/msdosfs/msdosfs_vnops.c:596 > > > > #19 0xffffffff808feb20 in VOP_READ_APV (vop=3D= , a=3D) at vnode_if.c:930 > > > > #20 0xffffffff8039bf3a in mdstart_vnode (sc=3D0xfffff8004c7ce000, b= p=3D0xfffff80028fc81f0) at vnode_if.h:384 =20 > > > From the frame 20, do 'p *bp' in kgdb and mail the result. Do you ha= ve > > > any non-standard values for buffer cache knobs, esp. for MAXPHYS ? =20 > >=20 > > (kgdb) p *bp > > $1 =3D {bio_cmd =3D 1 '\001', bio_flags =3D 16 '\020', bio_cflags =3D 0= '\0', bio_pflags =3D 0 '\0', bio_dev =3D 0x0, bio_disk =3D 0x0, bio_offset= =3D 0, bio_bcount =3D 0,=20 > > bio_data =3D 0xfffffe0077d94000
, bio_ma =3D 0xfffff8000275bc00, bio_ma_offset =3D 960, =20 >=20 > bio_ma_n =3D 33, > This is the issue. The upper layer (ZFS ?) passed down the request > which is max-sized (see bio_length =3D=3D 32 pages) but not aligned. > The physical buffer used for transient mapping cannot handle this. >=20 > bio_error =3D 0, bio_resid =3D 0,=20 > > bio_done =3D 0xffffffff804e51d0 , bio_driver1 =3D 0x0, bi= o_driver2 =3D 0x0, bio_caller1 =3D 0x0, bio_caller2 =3D 0x0, bio_queue =3D = {tqe_next =3D 0x0, tqe_prev =3D 0xfffff8004c7ce018}, bio_attribute =3D 0x0,= =20 > > bio_from =3D 0xfffff80010131d80, bio_to =3D 0xfffff800694f2a00, bio_l= ength =3D 131072, bio_completed =3D 0, bio_children =3D 0, bio_inbed =3D 0,= bio_parent =3D 0xfffff8000628bd90, bio_t0 =3D {sec =3D 33029,=20 > > frac =3D 13163670047247984455}, bio_task =3D 0, bio_task_arg =3D 0x= 0, bio_classifier1 =3D 0x0, bio_classifier2 =3D 0x0, bio_pblkno =3D 0} > > =20 > > I don't use non-standard values for MAXPHYS or other buffer cache setti= ngs. > > =20 >=20 > Try the following patch. With this patch I got: [400] Fatal trap 9: general protection fault while in kernel mode [400] cpuid =3D 0; apic id =3D 00 [400] instruction pointer =3D 0x20:0xffffffff8086c603 [400] stack pointer =3D 0x28:0xfffffe0094422a60 [400] frame pointer =3D 0x28:0xfffffe0094422a80 [400] code segment =3D base 0x0, limit 0xfffff, type 0x1b [400] =3D DPL 0, pres 1, long 1, def32 0, gran 1 [400] processor eflags =3D interrupt enabled, resume, IOPL =3D 0 [400] current process =3D 34142 (md0) [...] (kgdb) where #0 doadump (textdump=3D0) at pcpu.h:221 #1 0xffffffff80316e5b in db_dump (dummy=3D, dummy2=3D= false, dummy3=3D0, dummy4=3D0x0) at /usr/src/sys/ddb/db_command.c:533 #2 0xffffffff80316c4e in db_command (cmd_table=3D0x0) at /usr/src/sys/ddb/= db_command.c:440 #3 0xffffffff803169e4 in db_command_loop () at /usr/src/sys/ddb/db_command= .c:493 #4 0xffffffff803194eb in db_trap (type=3D, code=3D0) = at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff805e2933 in kdb_trap (type=3D9, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff8087d161 in trap_fatal (frame=3D0xfffffe00944229b0, eva=3D) at /usr/src/sys/amd64/amd64/trap.c:829 #7 0xffffffff8087ce3c in trap (frame=3D) at /usr/src/= sys/amd64/amd64/trap.c:203 #8 0xffffffff80861ae7 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:234 #9 0xffffffff8086c603 in pmap_qenter (sva=3D18446741876956168192, ma=3D, count=3D32) at /usr/src/sys/amd64/amd64/pmap.c:1991 #10 0xffffffff8039e673 in mdstart_vnode (sc=3D0xfffff80029ac7800, bp=3D0xff= fff800270c15d0) at /usr/src/sys/dev/md/md.c:928 #11 0xffffffff8039c73c in md_kthread (arg=3D0xfffff80029ac7800) at /usr/src= /sys/dev/md/md.c:1158 #12 0xffffffff8055c16c in fork_exit (callout=3D0xffffffff8039c510 , arg=3D0xfffff80029ac7800, frame=3D0xfffffe0094422c00) at /usr/src/sys/= kern/kern_fork.c:1011 #13 0xffffffff8086201e in fork_trampoline () at /usr/src/sys/amd64/amd64/ex= ception.S:609 #14 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) f 9 #9 0xffffffff8086c603 in pmap_qenter (sva=3D18446741876956168192, ma=3D, count=3D32) at /usr/src/sys/amd64/amd64/pmap.c:1991 1991 m =3D *ma++; (kgdb) f 10 #10 0xffffffff8039e673 in mdstart_vnode (sc=3D0xfffff80029ac7800, bp=3D0xff= fff800270c15d0) at /usr/src/sys/dev/md/md.c:928 928 pmap_qenter((vm_offset_t)pb->b_data, (kgdb) l 923 unmapped_step: 924 npages =3D min(MAXPHYS, roundup2(len + ma_offs, PAGE_SIZE)) / 925 PAGE_SIZE; 926 iolen =3D min(npages * PAGE_SIZE - ma_offs, len); 927 KASSERT(iolen > 0, ("zero iolen")); 928 pmap_qenter((vm_offset_t)pb->b_data, 929 &bp->bio_ma[ma_offs / PAGE_SIZE], npages); 930 aiov.iov_base =3D (void *)((vm_offset_t)pb->b_data + 931 ma_offs % PAGE_SIZE); 932 aiov.iov_len =3D iolen; [...] (kgdb) p *pb $8 =3D {b_bufobj =3D 0x1001, b_bcount =3D 0, b_caller1 =3D 0x0, b_data =3D = 0x0, b_error =3D 0, b_iocmd =3D 0 '\0', b_ioflags =3D 0 '\0', b_iooffset = =3D -2197012545536, b_resid =3D -8795990460928, b_iodone =3D 0x2100000400,= =20 b_blkno =3D 0, b_offset =3D 1024, b_bobufs =3D {tqe_next =3D 0xffffffff80= 4e7bb0, tqe_prev =3D 0x0}, b_vflags =3D 0, b_qindex =3D 0, b_flags =3D 0, b= _xflags =3D 0 '\0', b_lock =3D {lock_object =3D {lo_name =3D 0x0, lo_flags = =3D 0,=20 lo_data =3D 0, lo_witness =3D 0xfffff80029ac7818}, lk_lock =3D 0, lk_= exslpfail =3D 103222784, lk_timo =3D -2048, lk_pri =3D 655147520}, b_bufsiz= e =3D 131072, b_runningbufspace =3D 0, b_kvasize =3D 0, b_dirtyoff =3D 0,=20 b_dirtyend =3D 0, b_kvabase =3D 0xfffff800062853e0 "\001\020", b_lblkno = =3D 398, b_vp =3D 0xca3691a05b0bac47, b_rcred =3D 0x0, b_wcred =3D 0x0, b_u= nion =3D {bu_freelist =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, bu_pager = =3D { pg_iodone =3D 0, pg_reqpage =3D 0}}, b_cluster =3D {cluster_head =3D = {tqh_first =3D 0x0, tqh_last =3D 0x401}, cluster_entry =3D {tqe_next =3D 0x= 0, tqe_prev =3D 0x401}}, b_pages =3D 0xfffff800270c16d0, b_npages =3D 0,=20 b_dep =3D {lh_first =3D 0xc22730000}, b_fsprivate1 =3D 0x4000, b_fsprivat= e2 =3D 0xfffffe00874b8000, b_fsprivate3 =3D 0x0, b_pin_count =3D 0} Fabian --Sig_/DX2cufYBAYSOEq99V_mNkFc Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZlVQgACgkQBYqIVf93VJ2vWQCfWbOgJCdXLUylihBlDW2A10iz QaAAoJsENCZkBBQyXldMbZ1rnEoNdjcn =2lom -----END PGP SIGNATURE----- --Sig_/DX2cufYBAYSOEq99V_mNkFc-- From owner-freebsd-current@freebsd.org Mon Dec 7 10:14:46 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 067E79B949F for ; Mon, 7 Dec 2015 10:14:46 +0000 (UTC) (envelope-from matthew@freebsd.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A0ACA118C for ; Mon, 7 Dec 2015 10:14:45 +0000 (UTC) (envelope-from matthew@freebsd.org) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.2/8.15.2) with ESMTPSA id tB7AEUsl057688 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 7 Dec 2015 10:14:36 GMT (envelope-from matthew@freebsd.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 smtp.infracaninophile.co.uk tB7AEUsl057688 Authentication-Results: smtp.infracaninophile.co.uk/tB7AEUsl057688; dkim=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Subject: Re: pkg does not update the repo catalogue To: freebsd-current@freebsd.org References: <20151207085043.GA3047@c720-r285885-amd64> From: Matthew Seaman X-Enigmail-Draft-Status: N1110 Message-ID: <56655C00.3000709@freebsd.org> Date: Mon, 7 Dec 2015 10:14:24 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151207085043.GA3047@c720-r285885-amd64> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7H2O8OQ2cJfCVfTXlad6i5nUG0jMqaDGX" X-Virus-Scanned: clamav-milter 0.98.7 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 10:14:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7H2O8OQ2cJfCVfTXlad6i5nUG0jMqaDGX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/07/15 08:50, Matthias Apitz wrote: >=20 > Hello, >=20 > This is with 11-CURRENT and ports from July this year; I have the > packages which I build with poudriere on some other host in a dir > /usr/PKGDIR.20150726 and added 8 new packages there, the total number i= s > now 1691: >=20 > # ls *.txz | egrep -v 'packagesite.txz|meta.txz|digests.txz' | wc -l=20 > 1691 >=20 > My repo definition is: >=20 > # cat /usr/local/etc/pkg/repos/myrepo.conf > FreeBSD: { > url: "file:/usr/PKGDIR.20150726", > enabled: true, > } There's no need to label your custom repo as 'FreeBSD' -- in fact, it's probably better for you to use a distinct name, as the repo.conf files accumulate for the same repo tag. In this case you've possibly inadvertently got pkg checking the pkg signatures against the default FreeBSD repository keys, which isn't going to work for locally built packages. Just change the tag in the repo.conf to 'myrepo' and then check what pkg(8) sees overall by running 'pkg -vv'. You'll need to do a pkg upgrade -f after that. If you don't want to use the standard FreeBSD repo at all then you can add a /usr/local/etc/repos/FreeBSD.conf containing FreeBSD: { enabled: no } > When I now want to update the 8 new packages to the repo catalogue, the= y > are not added (i.e. the number stays with 1683 and I also can not > install them with 'pkg instal ...'): >=20 > # pkg -v > 1.5.5 > # pkg -R /usr/local/etc/pkg/repos/ update -f > Updating FreeBSD repository catalogue... > Fetching meta.txz: 100% 260 B 0.3kB/s 00:01 =20 > Fetching packagesite.txz: 100% 382 KiB 391.6kB/s 00:01 =20 > Processing entries: 100% > FreeBSD repository update completed. 1683 packages processed. >=20 > What I'm missing here? If changing the repo tag doesn't fix the problem, try turning on some debugging output: env DEBUG_LEVEL=3D4 pkg update -f Cheers, Matthew --7H2O8OQ2cJfCVfTXlad6i5nUG0jMqaDGX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWZVwAAAoJEABRPxDgqeTn+IkQAKRCn9yqhJTohWcOJzlCeEf8 Wcztnuo9j+EOen3G8JIXC5wMg0d6No6UH5vdu4BGZRGkyu6n5YVeCFtseCYy02wH bvNxzmDoZC+DYXialuXxnB4tqHW8l1d2pirP/27JQxOOpKZC/4X194SWMn2ohJQQ 61VgeCdoUUrWqanDKKyHzZ0q939cyHu3N/5L/ltDi/AdvfcasYoLt8UxeadsxEA5 ZXwr8QpcHIllGV54GFxQM+elZu72G/aTUFVNN2yj34kXZmXZTfXEdUcE1K18UMFs V7/QG9wXU+R5hBtyYIMRDwikOhQ64OsT+AtNeJKkp61lsnBvUdTFS6DnhR00V3SG J27Sm7kiAyfdcBHDYNZ6bqiNb/cSCz3K3hO+EwK8JQHRC3CrlY+kTNPcxACciJ3q MWDZZX6dVoYEjeWzaQMj8Y+/c7Lh0oWhr6LF0u/lbgxl/PdLzzi/WDYZjFamvGI3 X4HUlUrhcJlcsLEtR9Keir9pjJ13RSAAPTHczAZjcDIL1GPcobYWDJOVf+Ympt1p HeJ5mzq/kldiL5+J8reM4y2Cp+xantgixt/OoDM04r3KWOAtV0gt9dPmsCDZ1oHt KDOpyrmkvv6+upil1s/48AgzHWRIqOMYI1LkUkORtepMGjiu2A9eo9XfnN+mQ60T mxK6Gf0qeYS9TywkhB8s =ZyCO -----END PGP SIGNATURE----- --7H2O8OQ2cJfCVfTXlad6i5nUG0jMqaDGX-- From owner-freebsd-current@freebsd.org Mon Dec 7 11:04:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5367E9B916C for ; Mon, 7 Dec 2015 11:04:33 +0000 (UTC) (envelope-from guru@unixarea.de) 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 17EE91D7B for ; Mon, 7 Dec 2015 11:04:32 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [93.104.2.212] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1a5taf-0002RB-PZ for freebsd-current@freebsd.org; Mon, 07 Dec 2015 12:04:23 +0100 Received: from localhost.my.domain (c720-r285885-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id tB7B4LXg001772 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 7 Dec 2015 12:04:21 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id tB7B4KJu001771 for freebsd-current@freebsd.org; Mon, 7 Dec 2015 12:04:20 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 7 Dec 2015 12:04:20 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: pkg does not update the repo catalogue Message-ID: <20151207110420.GA1590@c720-r285885-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <20151207085043.GA3047@c720-r285885-amd64> <56655C00.3000709@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56655C00.3000709@freebsd.org> X-Operating-System: FreeBSD 11.0-CURRENT r285885 (amd64) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.2.212 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 11:04:33 -0000 El día Monday, December 07, 2015 a las 10:14:24AM +0000, Matthew Seaman escribió: > On 12/07/15 08:50, Matthias Apitz wrote: > > > > Hello, > > > > This is with 11-CURRENT and ports from July this year; I have the > > packages which I build with poudriere on some other host in a dir > > /usr/PKGDIR.20150726 and added 8 new packages there, the total number is > > now 1691: > > > > # ls *.txz | egrep -v 'packagesite.txz|meta.txz|digests.txz' | wc -l > > 1691 > > > > My repo definition is: > > > > # cat /usr/local/etc/pkg/repos/myrepo.conf > > FreeBSD: { > > url: "file:/usr/PKGDIR.20150726", > > enabled: true, > > } > > There's no need to label your custom repo as 'FreeBSD' -- in fact, it's > probably better for you to use a distinct name, as the repo.conf files > accumulate for the same repo tag. In this case you've possibly > inadvertently got pkg checking the pkg signatures against the default > FreeBSD repository keys, which isn't going to work for locally built > packages. > > Just change the tag in the repo.conf to 'myrepo' and then check what > pkg(8) sees overall by running 'pkg -vv'. You'll need to do a pkg > upgrade -f after that. > > If you don't want to use the standard FreeBSD repo at all then you can > add a /usr/local/etc/repos/FreeBSD.conf containing > > FreeBSD: { enabled: no } I did both: renamed the entry to myrepo and added a new file: # ls -l /usr/local/etc/pkg/repos/ total 8 -rw-r--r-- 1 root wheel 26 7 dic 11:30 FreeBSD.conf -rw-r--r-- 1 root wheel 114 7 dic 11:21 myrepo.conf # cat /usr/local/etc/pkg/repos/* FreeBSD: { enabled: no } myrepo: { url: "file:/usr/PKGDIR.20150726", enabled: true, } Now 'pkg -vv' shows only myrepo; the 'pkg upgrade -f' ended up with reinstallation of all ~1000 packages; but all this did not solved the problem; > If changing the repo tag doesn't fix the problem, try turning on some > debugging output: > > env DEBUG_LEVEL=4 pkg update -f The output of STDERR is here: http://www.unixarea.de/pkg-stderr.txt (4 MByte, 100.000 lines) Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, 🌐 http://www.unixarea.de/ ☎ +49-176-38902045 From owner-freebsd-current@freebsd.org Mon Dec 7 11:31:47 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D31F29B9C1B for ; Mon, 7 Dec 2015 11:31:47 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6413014F4 for ; Mon, 7 Dec 2015 11:31:47 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.2/8.15.2) with ESMTPSA id tB7BVefB059088 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 7 Dec 2015 11:31:41 GMT (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=infracaninophile.co.uk DKIM-Filter: OpenDKIM Filter v2.10.3 smtp.infracaninophile.co.uk tB7BVefB059088 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1449487901; bh=5MDZ7gUEh1CamRc0ihEHMvw6XYIezf/9YfWr0Azg7HE=; h=Subject:To:References:From:Date:In-Reply-To; z=Subject:=20Re:=20pkg=20does=20not=20update=20the=20repo=20catalog ue|To:=20freebsd-current@freebsd.org|References:=20<20151207085043 .GA3047@c720-r285885-amd64>=0D=0A=20<56655C00.3000709@freebsd.org> =20<20151207110420.GA1590@c720-r285885-amd64>|From:=20Matthew=20Se aman=20|Date:=20Mon,=207=20Dec=20 2015=2011:31:40=20+0000|In-Reply-To:=20<20151207110420.GA1590@c720 -r285885-amd64>; b=c8q3LaYS3e6ITSq4A3G9SsjQ0icD+bLcQmxub4XobFH5LjoQRcbTSBlWnbNiqnMDb UBbnyr0Br554qH1+3I2ts7NsJ8V2N7tlgAugd1U3McT4Uk5qsivOjVBx6WPrUv7Hp0 X/frTLsuzu7NnQRS8ptW0ufxkUa/rhnTM8e4YIyI= X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Subject: Re: pkg does not update the repo catalogue To: freebsd-current@freebsd.org References: <20151207085043.GA3047@c720-r285885-amd64> <56655C00.3000709@freebsd.org> <20151207110420.GA1590@c720-r285885-amd64> From: Matthew Seaman X-Enigmail-Draft-Status: N1110 Message-ID: <56656E1C.9030905@infracaninophile.co.uk> Date: Mon, 7 Dec 2015 11:31:40 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151207110420.GA1590@c720-r285885-amd64> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J4Va92Moti2FAWGBga5FciHE2cxg9seAb" X-Virus-Scanned: clamav-milter 0.98.7 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 11:31:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J4Va92Moti2FAWGBga5FciHE2cxg9seAb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/07/15 11:04, Matthias Apitz wrote: > Now 'pkg -vv' shows only myrepo; the 'pkg upgrade -f' ended up with > reinstallation of all ~1000 packages; Ooops. 'pkg upgrade -f' says 'reinstall everything' -- which was an error on my part. I meant to type 'pkg update -f' which only refreshes the repo catalogues. Apologies. > but all this did not solved the problem; >=20 >> > If changing the repo tag doesn't fix the problem, try turning on som= e >> > debugging output: >> >=20 >> > env DEBUG_LEVEL=3D4 pkg update -f > The output of STDERR is here: http://www.unixarea.de/pkg-stderr.txt > (4 MByte, 100.000 lines) Hmmmm.... it seems fairly clear to me that the 8 new packages aren't in the repo catalogue that you're downloading. You built the repo using poudriere? Poudriere does some fun'n'games with symbolic links to achieve an atomic repo update, which means there is actually a history of previous versions of the repo kept. You'll see a directory structure like this: % ls -la total 159 drwxr-xr-x 102 root wheel 108 Dec 7 00:19 ./ drwxr-xr-x 9 root wheel 15 Aug 4 11:39 ../ lrwxr-xr-x 1 root wheel 16 Dec 7 00:19 .latest@ -> .real_144944757= 2 [...] drwxr-xr-x 4 root wheel 8 Dec 5 01:27 .real_1449278821/ drwxr-xr-x 4 root wheel 8 Dec 6 00:55 .real_1449363354/ drwxr-xr-x 4 root wheel 8 Dec 7 00:19 .real_1449447572/ lrwxr-xr-x 1 root wheel 11 Dec 19 2014 All@ -> .latest/All lrwxr-xr-x 1 root wheel 14 Dec 19 2014 Latest@ -> .latest/Latest lrwxr-xr-x 1 root wheel 19 Dec 19 2014 digests.txz@ -> =2Elatest/digests.txz lrwxr-xr-x 1 root wheel 16 Dec 19 2014 meta.txz@ -> .latest/meta.t= xz lrwxr-xr-x 1 root wheel 23 Dec 19 2014 packagesite.txz@ -> =2Elatest/packagesite.txz Does the .latest symlink point at the .real_$TIMESTAMP you're expecting? Cheers, Matthew --J4Va92Moti2FAWGBga5FciHE2cxg9seAb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWZW4cAAoJEABRPxDgqeTnYNoP/Ar0Z+FZ1sD1G8qKz0a+COds i97Js7aGDAbTRB9vnc2CKEmLtgVROnDmioFx/zRnA9L+r5sTAyLCUCuRcoNCesv8 ynbAu144sNQreIratDWfICJEhdBZz/05YQAl06Y6SWjfIjCWd2BtmhEaEQSMh8zs YB2GjNInSgyLO1G3cZjJflf0IsOyRghC0KoC7r6CHTgtYw1VyZr76sMqm82fOzOb 0RaRaqVegpU4Uh8i/qv294B9p1diyFx2v0qvhyqXetJZGv26erhZCWMu8n1s4/9x 2Dac3wryLwrDk0u3CR6eCTGlrbvp/f7X8CV2je4XhCkr5Zt0y+84YClcWXOviMAG cHd+vrVF/Pom/+TepC1sCbGN+5ldkoiHo7jE8XTlFl3Rk61FYO4V3+ncdE36/Dcv /c09J7rWpInqyNq+QgiiIV44c8RL9h4pxNPxuhXZWAIrZZZcGmNyASKNH+Y9Nq+E x7+q0TMQT6BihEHTEqS/VFOFsre/0IXrqL40n3Lnev82Emp8FXvR5wEZRytMUZhx a2hSUVV3+h1TsKh9jXKZy3qemPlO7upnKIqh1f5HjELQaKcKe+LIx4Em4u9yN/Vj 8NrJNx49PD7AEB7n7iR1uvaL2TvlW0lD89TlO8xIu4z2JyX4SOzIUd4tbktvmu4P W2nRvceStvycqWT3rHOb =zyKw -----END PGP SIGNATURE----- --J4Va92Moti2FAWGBga5FciHE2cxg9seAb-- From owner-freebsd-current@freebsd.org Mon Dec 7 11:42:32 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B2CF9B9E79 for ; Mon, 7 Dec 2015 11:42:32 +0000 (UTC) (envelope-from guru@unixarea.de) 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 E2FF31BE3 for ; Mon, 7 Dec 2015 11:42:31 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [93.104.2.212] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1a5uBX-0002TR-Mk for freebsd-current@freebsd.org; Mon, 07 Dec 2015 12:42:28 +0100 Received: from localhost.my.domain (c720-r285885-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id tB7BgP3Z041479 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 7 Dec 2015 12:42:26 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id tB7BgPDp041478 for freebsd-current@freebsd.org; Mon, 7 Dec 2015 12:42:25 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 7 Dec 2015 12:42:25 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: pkg does not update the repo catalogue Message-ID: <20151207114225.GA41445@c720-r285885-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <20151207085043.GA3047@c720-r285885-amd64> <56655C00.3000709@freebsd.org> <20151207110420.GA1590@c720-r285885-amd64> <56656E1C.9030905@infracaninophile.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56656E1C.9030905@infracaninophile.co.uk> X-Operating-System: FreeBSD 11.0-CURRENT r285885 (amd64) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.2.212 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 11:42:32 -0000 El día Monday, December 07, 2015 a las 11:31:40AM +0000, Matthew Seaman escribió: > Hmmmm.... it seems fairly clear to me that the 8 new packages aren't in > the repo catalogue that you're downloading. You built the repo using > poudriere? Poudriere does some fun'n'games with symbolic links to > achieve an atomic repo update, which means there is actually a history > of previous versions of the repo kept. You'll see a directory structure > like this: > > ... Maybe I wasn't clear enough. I copied only the packages to the new system (my netbook) some weeks ago, and created the catalogue with # pkg repo /usr/PKGDIR.20150726 and installed the packages; Today I built 8 packages more, copied them over too and was (may be in error) expecting to add these 8 new packages to the catalogue with 'pkg update -f' Seems that I just have to reuse 'pkg repo ....' Thanks for your hints. matthias -- Matthias Apitz, ✉ guru@unixarea.de, 🌐 http://www.unixarea.de/ ☎ +49-176-38902045 From owner-freebsd-current@freebsd.org Mon Dec 7 12:25:19 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAACC99A131 for ; Mon, 7 Dec 2015 12:25:19 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08C0B1A34 for ; Mon, 7 Dec 2015 12:25:18 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from [10.6.25.100] ([213.61.170.110]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LkOeR-1ahiRi3Yfj-00cMNb; Mon, 07 Dec 2015 13:25:09 +0100 Subject: Re: pkg does not update the repo catalogue To: freebsd-current@freebsd.org References: <20151207085043.GA3047@c720-r285885-amd64> From: olli hauer X-Enigmail-Draft-Status: N1110 Cc: Matthias Apitz Message-ID: <56657AA5.1050002@gmx.de> Date: Mon, 7 Dec 2015 13:25:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151207085043.GA3047@c720-r285885-amd64> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:8Tu4cAnSYTBAR8F956xp0SN4foYEKGzzK4qZdEIzOWbaab3fXTi 5pdQfZOiJyUtBr6lI3+WiNIRNLLNViT0U2W2cUj3o83VYge4KoRXz2jX0tW4+ZM7yAKmuav aUxr6Ov+Uy+DNZMCxWKS+td62sHYwUndLYNaHBLqg8EMS0tLIfdFmOHUu5uHq9XOHMoty7v hTrX/hnNMj1n5OdvcPpxQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:V37u9KgO2LU=:kcS9XciBAWoA/JWl/J2QGN bVoVG5TOS6TKBLT/RU+GtI0ALosJ7xjXDVOld6dliLyzf56bVmP3kY5X8/hQLdU75XO64iGmk QXJYiqibvdnj7OGM0GSgI1gxe8SPGDlHNNyNdHj/fsnSeWL7XbpPszUhSKhWTZoeBmj7np8ou SPGOw5CxZ1rtkp/4oOYUB/qSlDQcgXt6tKxcPgAT7l52S0tVUTscslb4WcCN2Fqa03CNaSbbN Pb/yj4AZnpMpMfdNUlWX7dznE9dEGOl2GKJnQAWj2n0QAbgj906Iv4cOPfCkVy0wo/N5Bl13G fLZGgiqR3Zw+zFUL73nI9hFOVCkq+83t+JUz1aQZjIQL94PhCaJgqNEy2h+y/qv6tld+4cqMg zAZ6z1RF8eUwxy0LG8/RVSlXqZZggC80gxXCF7RgCTQk1NEA9fqhFr0Xlc/PBY35ysa38v99L ygekJG15CAhULnHsQdDqYT7EAvfDT8H1bEmpZL/2lFYOg56ucKLqiRzD4fnXgHgvkS45aLsmF Qa2hWu3Tl+I0UQjepJPsI1euSc8fnJNjctEMnMtp/FVDSDEOZ9qgvaemKLP+K0YCTK8SEGsVD afrfSRJhH8NgMI5dV8IQFg7gdPty8Md5lckxXlJjmoWKPvql4OtWPiOf9wf2FFvLQGpjqB9N9 HRu8cnQaPmh8F2BrouArTxCSneQeVmJ0pv6D2hzVU0Qd0uxbiN0H+YBs5FOWudy5SOB/Mo/NA ycsVFnRjFqOw1QW/PVEbcb7rI11CHYUTAaaGjQ/QbvnDQivgd/YVbS9SvWkK87oxE/WdlHvTg qShb0a5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 12:25:19 -0000 On 2015-12-07 09:50, Matthias Apitz wrote: > > Hello, > > This is with 11-CURRENT and ports from July this year; I have the > packages which I build with poudriere on some other host in a dir > /usr/PKGDIR.20150726 and added 8 new packages there, the total number is > now 1691: > > # ls *.txz | egrep -v 'packagesite.txz|meta.txz|digests.txz' | wc -l > 1691 > > My repo definition is: > > # cat /usr/local/etc/pkg/repos/myrepo.conf > FreeBSD: { > url: "file:/usr/PKGDIR.20150726", > enabled: true, > } > > When I now want to update the 8 new packages to the repo catalogue, they > are not added (i.e. the number stays with 1683 and I also can not > install them with 'pkg instal ...'): > > # pkg -v > 1.5.5 > # pkg -R /usr/local/etc/pkg/repos/ update -f > Updating FreeBSD repository catalogue... > Fetching meta.txz: 100% 260 B 0.3kB/s 00:01 > Fetching packagesite.txz: 100% 382 KiB 391.6kB/s 00:01 > Processing entries: 100% > FreeBSD repository update completed. 1683 packages processed. > > What I'm missing here? > > Thanks > > matthias Hi Matthias, I see some possible issues. - repo has same name as the official one (FreeBSD, see `cat /etc/pkg/FreeBSD.conf') - file:/$path should be file:///$path - repo catalog was not updated with command `pkg repo' - REPO_AUTOUPDATE = true/false (in pkg.conf) Does your repo match the output of the command $ pkg -vv (all below Repositories:) -- olli From owner-freebsd-current@freebsd.org Mon Dec 7 12:26:46 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0993699A272 for ; Mon, 7 Dec 2015 12:26:46 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 B456D1BC6 for ; Mon, 7 Dec 2015 12:26:45 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wmww144 with SMTP id w144so147879485wmw.0 for ; Mon, 07 Dec 2015 04:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=qeDUt+trmdERyZ9p4o5oVGwS5oUJbI6+8Ss1CtEIpkE=; b=gwpvfrKZ0hjEPzG+Dm6q68/F1Ax+kMb3rt+0lDScxrZkvyUIHyXp3CxFqSN4KJPK6O vvG8YWgOx11G2uCX7qlwoytESFjPukOi6+Rl+iV+PZaDzSAXGzlcuqbqsxtxfuIXYNYY bjaUl8aqpOZPoKnxER0y6stjrU0rOei4kFUpY1bMDzycrNGy8z9XtPQpmCQH58d5yivd 69UHbILMHV811Lj+YNgLH7TIcXSeOSJAYy07qSjG2+5I9WPpXFOkYKZPyCChlUEnGPtj 1e3sEK426cafWZG7cUcrl4Bd7tzMh12r/09UWfoFhBa7uiZfzAgSC2o1pUnLg1Dpvcjc lFcQ== X-Received: by 10.28.26.78 with SMTP id a75mr20405871wma.13.1449491203539; Mon, 07 Dec 2015 04:26:43 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id w6sm25108945wjy.31.2015.12.07.04.26.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2015 04:26:42 -0800 (PST) Sender: Baptiste Daroussin Date: Mon, 7 Dec 2015 13:26:40 +0100 From: Baptiste Daroussin To: olli hauer Cc: freebsd-current@freebsd.org, Matthias Apitz Subject: Re: pkg does not update the repo catalogue Message-ID: <20151207122640.GL27529@ivaldir.etoilebsd.net> References: <20151207085043.GA3047@c720-r285885-amd64> <56657AA5.1050002@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TnYVF1hk1c8rpHiF" Content-Disposition: inline In-Reply-To: <56657AA5.1050002@gmx.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 12:26:46 -0000 --TnYVF1hk1c8rpHiF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 07, 2015 at 01:25:09PM +0100, olli hauer wrote: > On 2015-12-07 09:50, Matthias Apitz wrote: > >=20 > > Hello, > >=20 > > This is with 11-CURRENT and ports from July this year; I have the > > packages which I build with poudriere on some other host in a dir > > /usr/PKGDIR.20150726 and added 8 new packages there, the total number is > > now 1691: > >=20 > > # ls *.txz | egrep -v 'packagesite.txz|meta.txz|digests.txz' | wc -l=20 > > 1691 > >=20 > > My repo definition is: > >=20 > > # cat /usr/local/etc/pkg/repos/myrepo.conf > > FreeBSD: { > > url: "file:/usr/PKGDIR.20150726", > > enabled: true, > > } > >=20 > > When I now want to update the 8 new packages to the repo catalogue, they > > are not added (i.e. the number stays with 1683 and I also can not > > install them with 'pkg instal ...'): > >=20 > > # pkg -v > > 1.5.5 > > # pkg -R /usr/local/etc/pkg/repos/ update -f > > Updating FreeBSD repository catalogue... > > Fetching meta.txz: 100% 260 B 0.3kB/s 00:01 =20 > > Fetching packagesite.txz: 100% 382 KiB 391.6kB/s 00:01 =20 > > Processing entries: 100% > > FreeBSD repository update completed. 1683 packages processed. > >=20 > > What I'm missing here? > >=20 > > Thanks > >=20 > > matthias >=20 > Hi Matthias, >=20 > I see some possible issues. >=20 > - repo has same name as the official one (FreeBSD, see `cat /etc/pkg/Free= BSD.conf') > - file:/$path should be file:///$path pkg should have yelled about that, I will fix that. > - repo catalog was not updated with command `pkg repo' > - REPO_AUTOUPDATE =3D true/false (in pkg.conf) >=20 > Does your repo match the output of the command > $ pkg -vv (all below Repositories:) >=20 >=20 Best regards, Bapt --TnYVF1hk1c8rpHiF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZlewAACgkQ8kTtMUmk6Ez4BACgiODeddGgMTJyHXom+RaMcIK4 hX0An0DvJukBr0JaifxAAziU/X6pytZ1 =gzav -----END PGP SIGNATURE----- --TnYVF1hk1c8rpHiF-- From owner-freebsd-current@freebsd.org Mon Dec 7 13:17:59 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85F6699AD73 for ; Mon, 7 Dec 2015 13:17:59 +0000 (UTC) (envelope-from matthew@freebsd.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F80B1A43 for ; Mon, 7 Dec 2015 13:17:59 +0000 (UTC) (envelope-from matthew@freebsd.org) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.2/8.15.2) with ESMTPSA id tB7DHi5n061143 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 7 Dec 2015 13:17:45 GMT (envelope-from matthew@freebsd.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 smtp.infracaninophile.co.uk tB7DHi5n061143 Authentication-Results: smtp.infracaninophile.co.uk/tB7DHi5n061143; dkim=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Subject: Re: pkg does not update the repo catalogue To: freebsd-current@freebsd.org References: <20151207085043.GA3047@c720-r285885-amd64> <56655C00.3000709@freebsd.org> <20151207110420.GA1590@c720-r285885-amd64> <56656E1C.9030905@infracaninophile.co.uk> <20151207114225.GA41445@c720-r285885-amd64> From: Matthew Seaman X-Enigmail-Draft-Status: N1110 Message-ID: <566586F2.907@freebsd.org> Date: Mon, 7 Dec 2015 13:17:38 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151207114225.GA41445@c720-r285885-amd64> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oOB47dvTTjCNMG8vegsU2bVMLpFW2cgBD" X-Virus-Scanned: clamav-milter 0.98.7 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 13:17:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oOB47dvTTjCNMG8vegsU2bVMLpFW2cgBD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/07/15 11:42, Matthias Apitz wrote: > Maybe I wasn't clear enough. I copied only the packages to the new > system (my netbook) some weeks ago, and created the catalogue with >=20 > # pkg repo /usr/PKGDIR.20150726 >=20 > and installed the packages; Today I built 8 packages more, copied them > over too and was (may be in error) expecting to add these 8 new package= s to > the catalogue with 'pkg update -f' >=20 > Seems that I just have to reuse 'pkg repo ....' Yeah. That would explain what you were seeing. Yes, you do have to rebuild the repo catalogue on your repo server when you change the repo contents. Running 'pkg update -f' or similar won't cause pkg(8) to be run on the repo side -- the repo is a read-only source of static content[*] as far as the client pkg(8) can interact with it. Cheers, Matthew [*] Well, except possibly for the repo.conf HTTP mirroring scheme which is intended to allow load balancing amongst a set of repo servers by -- possibly dynamically -- generating a list of the available servers in preference order. --oOB47dvTTjCNMG8vegsU2bVMLpFW2cgBD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWZYbyAAoJEABRPxDgqeTnc2QP/2YSdsvS3ZnXdYTc2mxHCGTY FCGHhjiFOzp1buME+UjVRmiCsp9zp01yZ5H8g4z8aKvqZGNk0dq9m58LrnkTURxC 2bfho8aKDTeyUIWPcobur/eqns9HGm+wXJxJP9I/tyQNXKG+S9MB9FpEI4lLzIQT dJE8mh004a9GzXWMox+WHoatxR+nxRnOtqPxSvZl57jx7I7xglnPtKMABJlatXVi F/y0msqT9Ydh/PqQvFm2feTqzESgu2mWPeD1Fn8MZuoI7GLK6JZU3ohdb/VQswEe EmObGpNQX5ZjghIE8fBuGjr16aCbhE9XHpSqyqVsOzHmji/uk6RU9L0FRy3Qpcr0 ojL80tE8vYKpWQCPqKClEbrRGJgML2e2v7JmPEWMnPyQ6ovs8elhHip4R33f14+e OoJZeTkxZYwOyFBF8s/lCQVmHG8bBzRdPriAdsi1NAfCJaM9yrWlBSCrhirQXq3u piJlaxwQ6X6GfnvzMLKaYiVy2ghh+/AzGI1d9I0x7LoDWB+8LHZ/HDUTh0JIyD4n e1wH2xenbStCN6oXtEVhR0B6oY5Rhbt50UivFcjKJq0XX9/VWxj6GkMoFBLYVfMV Tpxj5xYHdpv3eiF9QJ+UU9ykqlSCNzryDWY2sdYo4Ba/Yhy7nT0ejnxjLsu1KkNK vWHOzd85MiYd3H5ovX1N =qGZn -----END PGP SIGNATURE----- --oOB47dvTTjCNMG8vegsU2bVMLpFW2cgBD-- From owner-freebsd-current@freebsd.org Mon Dec 7 13:49:45 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 652639A0579 for ; Mon, 7 Dec 2015 13:49:45 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) (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 EEC271A15 for ; Mon, 7 Dec 2015 13:49:44 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.182.168] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1a5w53-0001sL-Ro for freebsd-current@FreeBSD.org; Mon, 07 Dec 2015 14:43:54 +0100 Date: Mon, 7 Dec 2015 14:43:53 +0100 From: Fabian Keil To: freebsd-current@FreeBSD.org Subject: panic: devfs_fsync: vop_stdfsync failed. Message-ID: <20151207144353.6fd09a40@fabiankeil.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/AhYOJ/WbpzKFYrDJerPGVHC"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 13:49:45 -0000 --Sig_/AhYOJ/WbpzKFYrDJerPGVHC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I got the following panic by impatiently unplugging a device while a msdosfs partition on it was in the process of getting unmounted: Unread portion of the kernel message buffer: [368] Device IPOD went missing before all of the data could be written to i= t; expect data loss. [368] fsync: giving up on dirty [368] 0xfffff80011b24760: tag devfs, type VCHR [368] usecount 1, writecount 0, refcount 4770 mountedhere 0xfffff800061= eb200 [368] flags (VI_DOOMED|VI_ACTIVE) [368] v_object 0xfffff80011a4c500 ref 0 pages 4782 cleanbuf 4766 dirtyb= uf 1 [368] lock type devfs: EXCL by thread 0xfffff80010c424d0 (pid 40394, su= do, tid 101528) [368] dev msdosfs/IPOD [368] panic: devfs_fsync: vop_stdfsync failed. [...] (kgdb) where #0 doadump (textdump=3D0) at pcpu.h:221 #1 0xffffffff80316e5b in db_dump (dummy=3D, dummy2=3D= false, dummy3=3D0, dummy4=3D0x0) at /usr/src/sys/ddb/db_command.c:533 #2 0xffffffff80316c4e in db_command (cmd_table=3D0x0) at /usr/src/sys/ddb/= db_command.c:440 #3 0xffffffff803169e4 in db_command_loop () at /usr/src/sys/ddb/db_command= .c:493 #4 0xffffffff803194eb in db_trap (type=3D, code=3D0) = at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff805e2923 in kdb_trap (type=3D3, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff8087cb27 in trap (frame=3D0xfffffe009464a0b0) at /usr/src/sys= /amd64/amd64/trap.c:549 #7 0xffffffff80861ad7 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:234 #8 0xffffffff805e200b in kdb_enter (why=3D0xffffffff8096fb7b "panic", msg= =3D0x32
) at cpufunc.h:63 #9 0xffffffff8059e5af in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:750 #10 0xffffffff8059e403 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutd= own.c:688 #11 0xffffffff80459e1f in devfs_fsync (ap=3D) at /usr/= src/sys/fs/devfs/devfs_vnops.c:688 #12 0xffffffff80902206 in VOP_FSYNC_APV (vop=3D, a=3D<= value optimized out>) at vnode_if.c:1328 #13 0xffffffff8063dba5 in bufsync (bo=3D, waitfor=3D) at vnode_if.h:549 #14 0xffffffff8065bc3c in bufobj_invalbuf (bo=3D0xfffff80011b24830, flags= =3D1, slpflag=3D0, slptimeo=3D0) at /usr/src/sys/kern/vfs_subr.c:1517 #15 0xffffffff8065f23e in vgonel (vp=3D) at /usr/src/s= ys/kern/vfs_subr.c:1595 #16 0xffffffff8065f8e7 in vgone (vp=3D0xfffff80011b24760) at /usr/src/sys/k= ern/vfs_subr.c:3006 #17 0xffffffff80453152 in devfs_delete (dm=3D0xfffff80002428080, de=3D0xfff= ff800062d2d00, flags=3D0) at /usr/src/sys/fs/devfs/devfs_devs.c:390 #18 0xffffffff80453663 in devfs_populate_loop (dm=3D0xfffff80002428080, cle= anup=3D) at /usr/src/sys/fs/devfs/devfs_devs.c:528 #19 0xffffffff8045344a in devfs_populate (dm=3D0xfffff80002428080) at /usr/= src/sys/fs/devfs/devfs_devs.c:655 #20 0xffffffff8045914e in devfs_populate_vp (vp=3D0xfffff80006130588) at /u= sr/src/sys/fs/devfs/devfs_vnops.c:239 #21 0xffffffff80456c4c in devfs_lookup (ap=3D0xfffffe009464a6d8) at /usr/sr= c/sys/fs/devfs/devfs_vnops.c:1042 #22 0xffffffff80900e90 in VOP_LOOKUP_APV (vop=3D, a=3D= ) at vnode_if.c:127 #23 0xffffffff8065131e in lookup (ndp=3D0xfffffe009464a9b0) at vnode_if.h:54 #24 0xffffffff806509f1 in namei (ndp=3D) at /usr/src/s= ys/kern/vfs_lookup.c:306 #25 0xffffffff8066ed7c in vn_open_cred (ndp=3D0xfffffe009464a9b0, flagp=3D0= xfffffe009464aa8c, cmode=3D0, vn_open_flags=3D0, cred=3D0xfffff80010467400,= fp=3D0xfffff8000633c780) at /usr/src/sys/kern/vfs_vnops.c:277 #26 0xffffffff80667eef in kern_openat (td=3D0xfffff80010c424d0, fd=3D-100, = path=3D0x41527f
, pathseg=3DUIO_USERSPACE, = flags=3DCannot access memory at address 0x32 ) at /usr/src/sys/kern/vfs_syscalls.c:1005 #27 0xffffffff8087db2b in amd64_syscall (td=3D0xfffff80010c424d0, traced=3D= 0) at subr_syscall.c:140 #28 0xffffffff80861dbb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:394 #29 0x0000000800f4d7aa in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) f 11 #11 0xffffffff80459e1f in devfs_fsync (ap=3D) at /usr/= src/sys/fs/devfs/devfs_vnops.c:688 688 panic("devfs_fsync: vop_stdfsync failed."); (kgdb) l - 678 if (!vn_isdisk(ap->a_vp, &error)) { 679 bo =3D &ap->a_vp->v_bufobj; 680 de =3D ap->a_vp->v_data; 681 if (error =3D=3D ENXIO && bo->bo_dirty.bv_cnt > 0) { 682 printf("Device %s went missing before all of the data " 683 "could be written to it; expect data loss.\n", 684 de->de_dirent->d_name); 685=09 686 error =3D vop_stdfsync(ap); 687 if (bo->bo_dirty.bv_cnt !=3D 0 || error !=3D 0) (kgdb) l 688 panic("devfs_fsync: vop_stdfsync failed."); Shouldn't vop_stdfsync() be expected to fail if the device went missing? My kernel is based on r291864 but the printf+panic code was added years ago in r186911 and the commit message suggests that it prevents a different panic: commit d72b8ba20f3993d4517a73171cb5e4a269b103a6 Author: trasz Date: Thu Jan 8 19:13:34 2009 +0000 Don't panic with "vinvalbuf: dirty bufs" when the mounted device that w= as being written to goes away. Fabian --Sig_/AhYOJ/WbpzKFYrDJerPGVHC Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZljRoACgkQBYqIVf93VJ3+hQCfa+v/+eoT7EUPWP1zu2juBRa3 /cgAnjkvjeuZn62G+dBJQw28bhceoDDq =QjKs -----END PGP SIGNATURE----- --Sig_/AhYOJ/WbpzKFYrDJerPGVHC-- From owner-freebsd-current@freebsd.org Mon Dec 7 14:02:47 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E09D9A08ED for ; Mon, 7 Dec 2015 14:02:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C3675102A for ; Mon, 7 Dec 2015 14:02:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:szfbgRZe9p08DpxGsierCIT/LSx+4OfEezUN459isYplN5qZpcS6bnLW6fgltlLVR4KTs6sC0LqI9fi4EUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35rxj7j60qaQSjsLrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGx48sgs/M9YUKj8Y79wDfkBVGxnYCgJ45jFrxTOZzCjrlABSH8blAYAVwbf4RzwRZu0uTbgrOd7xAGUJ8D7R6s4HzO44PE4ZgXvjXI9NjU6uETegc90gacT9Aikrhd8x4PRSJySO+dzervdO9gTEzkSFv1NXjBMV9vvJ7AECPAMaKMB99Hw X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DMAQBvkGVW/61jaINehQG9KgENgW6GDoF4FAEBAQEBAQEBgQmCLYIOI2gBIgINGQJbBIhCnxKPcJBGAQoBAQEfgQGFU4x0gUQFjh+IQqonAh8BAUKEIiCFHIEHAQEB X-IronPort-AV: E=Sophos;i="5.20,395,1444708800"; d="scan'208";a="254618616" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 07 Dec 2015 09:02:35 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id D4A7915F56D for ; Mon, 7 Dec 2015 09:02:35 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id yb1RNB1F7loJ for ; Mon, 7 Dec 2015 09:02:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 80D9115F56E for ; Mon, 7 Dec 2015 09:02:35 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Gcs463xnVaUO for ; Mon, 7 Dec 2015 09:02:35 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 659DE15F56D for ; Mon, 7 Dec 2015 09:02:35 -0500 (EST) Date: Mon, 7 Dec 2015 09:02:35 -0500 (EST) From: Rick Macklem To: FreeBSD Current Message-ID: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> Subject: slow screen updates on laptop console (i386) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: slow screen updates on laptop console (i386) Thread-Index: xlx/xjZeDfPKB7dWw8yBR1kX4H2Zzw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 14:02:47 -0000 Hi, When running FreeBSD-current on an old i386 laptop, the console screen is intermittently slow to display output. The hesitations can be several seconds. Sometimes it shows up when I'm typing such that it takes seconds for the characters to echo. I think it is the display/output side, since I've seen it happen when doing "more ", where the screen is stuck half way through displaying the page for a few seconds. I don't see any problem when going into the machine remotely and I don't see the problem on the other laptop I have running FreeBSD/amd64. It has been happening for a while. It occurs on the oldest kernel I have lying around (r287930, Sep. 17, 2015). I've tried the old "sc" driver and it seems to happen less with it, but it still occurs. I'll admit I have no idea what drives doing output for the display screen. Anyone have ideas w.r.t. this? Thanks in advance, rick From owner-freebsd-current@freebsd.org Mon Dec 7 14:18:22 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58A259B710B for ; Mon, 7 Dec 2015 14:18:22 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (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 18FCB19FA for ; Mon, 7 Dec 2015 14:18:22 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qgea14 with SMTP id a14so143752517qge.0 for ; Mon, 07 Dec 2015 06:18:21 -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:in-reply-to:references :mime-version:content-type; bh=Em4x5Y/QnoObsNpk/FPDb16Sd6pqlRARlVM43ReaLYs=; b=rGK8DJvZYqCPeeFlv5qnpp++ybfutIYexe8sCWlwJOn5ClSobkLxJKNTjceZ/TFLfz 3JOPWYqmT8P8gAazyJnFvu2c4X3FETOoo40nM0iZg65dToX1f+DtVoeAi9R8ANFR4mGX fvuzJoqT0LEvWoGgwCycsH/gCeUTePqoPyD48dOrK9Zusbx84RfAdTraJ7jafbXK+H2h M2cAYWpRznec75pfVzd4P7GOAJfgJeEAo7Jg/OgNtZDiEh4QHc8IY1S7whqoMm4Aq8R/ Ng++eNP9QtA/+mKZYSpzLdOx7s3gpHtG3yHheQlUoz2v8zj2cunmSNjWfTP3NIHBMqix 8eUg== X-Received: by 10.140.23.83 with SMTP id 77mr36183486qgo.58.1449497901286; Mon, 07 Dec 2015 06:18:21 -0800 (PST) Received: from kan ([2601:18f:802:4680:226:18ff:fe00:232e]) by smtp.gmail.com with ESMTPSA id b108sm11646797qgf.20.2015.12.07.06.18.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Dec 2015 06:18:20 -0800 (PST) Date: Mon, 7 Dec 2015 09:18:15 -0500 From: Alexander Kabaev To: FreeBSD Current Cc: Rick Macklem Subject: Re: slow screen updates on laptop console (i386) Message-ID: <20151207091815.16e11a13@kan> In-Reply-To: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> References: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/.IAaOqOvyaq1OWjKN_Ci73t"; protocol="application/pgp-signature" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 14:18:22 -0000 --Sig_/.IAaOqOvyaq1OWjKN_Ci73t Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 7 Dec 2015 09:02:35 -0500 (EST) Rick Macklem wrote: > Hi, >=20 > When running FreeBSD-current on an old i386 laptop, the console > screen is intermittently slow to display output. The hesitations > can be several seconds. > Sometimes it shows up when I'm typing such that it takes seconds > for the characters to echo. > I think it is the display/output side, since I've seen it happen when > doing "more ", where the screen is stuck half way through > displaying the page for a few seconds. >=20 > I don't see any problem when going into the machine remotely and > I don't see the problem on the other laptop I have running > FreeBSD/amd64. >=20 > It has been happening for a while. It occurs on the oldest kernel > I have lying around (r287930, Sep. 17, 2015). >=20 > I've tried the old "sc" driver and it seems to happen less with it, > but it still occurs. >=20 > I'll admit I have no idea what drives doing output for the display > screen. >=20 > Anyone have ideas w.r.t. this? >=20 > Thanks in advance, rick Hi, maybe a stretch, but I would try selecting different eventtimer, if available. Say, I had to select HPET on my old i7 920 to make timeouts run reliably. sysctl kern.eventtimer.timer=3DHPET =20 --=20 Alexander Kabaev --Sig_/.IAaOqOvyaq1OWjKN_Ci73t Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWZZUnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDNUY3RDk5NTk5QjY0MUUxM0M1MTU2OTEw NzEzMjI5OTkyNzkyRTdFAAoJEAcTIpmSeS5+s78P/0j1V52UVyidKGs0G7IkZRAj KPNiwSW8T6T2afPlAlJ+lGwMkqzpW2Ek+TrYRv0KqkrjeFCIhgEJFyGJhgSjlbPy 1uhx7uL8oq4NN73rdzq7CVOmboYZY2zUcZ5Y3dqEE25+32p8j7SH15CdTxtzWceH Svdt1xqlLa4Imzj7bvwJeeqxvGQDnfyp+6WUNjuJiI9ukBgMV7o+gVWTl2lKJPKS nQ5TdlRmDOWI8KbKMJFK6wSGV+Xa7qCR/vfkBI29y4k2UnfrCa0udkZVvADS4YmE +WdTG24Y88KmaLZCirsQ4HsfBgV2X4r/PrH7YhxzD0zX3kcQ93cmMkSPluBaGpQc p5vAsu36AXKlTU/QHLUN8DxriGFk1AOUxTpFNpqExDc2n0lpKQ/RN1EZAF0UaSwM TvR7vY/gSYkP62GBf2ln8+KpI4/vDf8s4hipC03qcAr4kNqdrmTv5eIbqmbdaty7 H2m1WDiaRUlRU3+kL4ugKUZ/TFhEE5PEuD4llXF1hGmqTvUNiJeY0aBkmbKSiC0p ZKjMui/ldUpnirVc8sirpFq9tCtkL2ND+IuQSk+i0L5oXbp5wLGogU/SmthzcdEl eeZSnhf/Gb3qadrhJGwU0PJ51X+tXWDsgubs2LvWCVXScpYaGlcz9Kl1s+2z9ca/ CYxEe/4Rh2e5X6LzOz3K =fw4E -----END PGP SIGNATURE----- --Sig_/.IAaOqOvyaq1OWjKN_Ci73t-- From owner-freebsd-current@freebsd.org Mon Dec 7 15:10:53 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 683CD9A062B for ; Mon, 7 Dec 2015 15:10:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2A53310F2 for ; Mon, 7 Dec 2015 15:10:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:x6ieMxAVoJtx1tATwLMzUyQJP3N1i/DPJgcQr6AfoPdwSP78p8bcNUDSrc9gkEXOFd2CrakU1ayO6+jJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6MyZzvn8mJuLTtICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJcekFjUlhJFaUggqurpzopM0r221qtvkg789NV7nhN+R9FOQATWduD2dgzcnmpRDFQQaVrlgVWGwbjFIcAAHP5Rzkdpj0uyr+8OF63X/JE9fxSOUOWD+hp4JiQxzshSJPYyQ8+WrUjsF1pL9crw+sowR/hYXdNtLGfMFid7/QKItJDVFKWdxcAmkYWtux X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DOAQCgoGVW/61jaINehHsGvSsBDYFuhg4CgXYUAQEBAQEBAQGBCYItgggBAQQjBFIQAgEIGAICDRkCAlcCBBOIL69AkEsBAQEBAQEBAwEBAQEBAQEcgQGFU4R9h3eBRAWOH4hCqicCHwEBQoQiIDSEaIEHAQEB X-IronPort-AV: E=Sophos;i="5.20,395,1444708800"; d="scan'208";a="256152551" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 07 Dec 2015 10:09:43 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 56B3C15F56D; Mon, 7 Dec 2015 10:09:43 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id UrwDnXQYhHR3; Mon, 7 Dec 2015 10:09:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id D513515F56E; Mon, 7 Dec 2015 10:09:42 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9kb5QmOQ_07T; Mon, 7 Dec 2015 10:09:42 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id BD0B715F56D; Mon, 7 Dec 2015 10:09:42 -0500 (EST) Date: Mon, 7 Dec 2015 10:09:42 -0500 (EST) From: Rick Macklem To: Alexander Kabaev Cc: FreeBSD Current Message-ID: <697195597.121770130.1449500982738.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20151207091815.16e11a13@kan> References: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> <20151207091815.16e11a13@kan> Subject: Re: slow screen updates on laptop console (i386) 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 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: slow screen updates on laptop console (i386) Thread-Index: 5S5CoSZer2HpEixfh0NPn91cyrovRA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 15:10:53 -0000 Alexander Kabaev wrote: > On Mon, 7 Dec 2015 09:02:35 -0500 (EST) > Rick Macklem wrote: > > > Hi, > > > > When running FreeBSD-current on an old i386 laptop, the console > > screen is intermittently slow to display output. The hesitations > > can be several seconds. > > Sometimes it shows up when I'm typing such that it takes seconds > > for the characters to echo. > > I think it is the display/output side, since I've seen it happen when > > doing "more ", where the screen is stuck half way through > > displaying the page for a few seconds. > > > > I don't see any problem when going into the machine remotely and > > I don't see the problem on the other laptop I have running > > FreeBSD/amd64. > > > > It has been happening for a while. It occurs on the oldest kernel > > I have lying around (r287930, Sep. 17, 2015). > > > > I've tried the old "sc" driver and it seems to happen less with it, > > but it still occurs. > > > > I'll admit I have no idea what drives doing output for the display > > screen. > > > > Anyone have ideas w.r.t. this? > > > > Thanks in advance, rick > > Hi, > > maybe a stretch, but I would try selecting different eventtimer, if > available. Say, I had to select HPET on my old i7 920 to make timeouts > run reliably. > > sysctl kern.eventtimer.timer=HPET > Great guess! Actually this old laptop doesn't have HPET, but switching it from LAPIC->RTC seems to have fixed the problem. (I had a hunch it was something timer/interrupt related, but I don't know that part of the system.) --> Just fyi, my other laptop that works fine defaulted to HPET. It looks like HPET rates higher than LAPIC. Thanks a lot, rick > -- > Alexander Kabaev > From owner-freebsd-current@freebsd.org Mon Dec 7 16:11:29 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 755079A0C21 for ; Mon, 7 Dec 2015 16:11:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 660BD17F8 for ; Mon, 7 Dec 2015 16:11:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 5E4A21E21 for ; Mon, 7 Dec 2015 16:11:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id EB42C1932A for ; Mon, 7 Dec 2015 16:11:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id LN1un5QqHmZG for ; Mon, 7 Dec 2015 16:11:22 +0000 (UTC) Subject: Re: [CFT] build: WITH_FAST_DEPEND and WITH_CCACHE_BUILD DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 43A4219314 To: freebsd-current@freebsd.org References: <5644CF1C.9020709@FreeBSD.org> <565E4F29.4030702@FreeBSD.org> From: Bryan Drewery Organization: FreeBSD Message-ID: <5665AF99.1060605@FreeBSD.org> Date: Mon, 7 Dec 2015 08:11:05 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565E4F29.4030702@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 16:11:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12/1/15 5:53 PM, Bryan Drewery wrote: > On 11/12/2015 9:40 AM, Bryan Drewery wrote: >> Hi, >> >> Recently I have introduced two new features into the build. These >> apply to anything using /usr/share/mk including buildworld, >> buildkernel, universe, etc. >> >> - The first is WITH_FAST_DEPEND. Please see the commit for its >> full > > > FYI there is a known issue with FAST_DEPEND with all of the csu > directories and libgcov. Apparently I never thought to do a full > build with having .depend files but no objects. Just today some > thing changes to cause the .depend files for csu to rebuild hitting > the issue. I'll be addressing it soon. The workaround is 'make > cleandepend' before building anything that is failing with > 'multiple targets' errors. > > The issues I know about are all fixed after r291945. You may need to run 'make cleandepend' or do a build without -DNO_CLEAN if you run into "cc: error: cannot specify -o when generating multiple output files ". - -- Regards, Bryan Drewery -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWZa+ZAAoJEDXXcbtuRpfPu+MIAKzhoNKoHfzdpAVz2lZGeH4Y tgh4iMt/zbAp8C4g6P4JpP5Yn4sdF/Kibuq6779z9gxYRQIk069YgeejoP9Ekp59 4k88lesY+6yHueuNN5oomRucvOXvHPVyuVTyNboFq7IiZB5wEt/iXyDQw41fDHGI hw8FFebKtvdFUtdz3Vz39wOKzhGtOGzy9sxvcnAgwo+FCR9Jx/LI8bMJbMWvVxjd N08188KJFwITwRfT41CeiAS3Cfx9soNUbwob/QZeavrosMlRQpio0cgJ72mMS07y kse5wHvO9VedpFkZ0nexIums5pmKr+ZSTFZ63TOrQN7nHs2Pb7laqUvg9+/En8c= =PgTt -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Mon Dec 7 16:18:32 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D76BF9B94BF for ; Mon, 7 Dec 2015 16:18:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 A98401E2B for ; Mon, 7 Dec 2015 16:18:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcmv3 with SMTP id mv3so81895934igc.0 for ; Mon, 07 Dec 2015 08:18:32 -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=a63lVFfJTPVwFB5pVR63PJk1TMGTSW5bCD46KIEez+4=; b=jSt3Qp+chFUNJ+mGCBZ1Eef43JooZ5DgJ/l3u2v7qruqbliK1XwSEk1wcypC0ZX6fN sMz2qat86Gptxugrytba1xRgGaU8dMEhaSnwzOHJkSbNoXPOJyH5RDvms31QSmrfGC+N 8mpLEAgy+5fM0T7R8yRwzvAHGIxkWajhcPay7Mix6PCb0ksKKypPmuhOq2wxWpD/yI3E WQuEQxIrGfVQySPnsumhnVkse/Z6aIaLp6rwSKXKe2rwJqFtkg5oxY4plGd74Sv3AMmP 2mGOInlUze/X1uj8rnTZoBmiK9J8Dsx/IE3D/fsui79WPqt94eEm2aE1kEaBhb2xFB4U N1Kg== MIME-Version: 1.0 X-Received: by 10.50.65.74 with SMTP id v10mr15868140igs.61.1449505112151; Mon, 07 Dec 2015 08:18:32 -0800 (PST) Received: by 10.36.217.196 with HTTP; Mon, 7 Dec 2015 08:18:32 -0800 (PST) In-Reply-To: <697195597.121770130.1449500982738.JavaMail.zimbra@uoguelph.ca> References: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> <20151207091815.16e11a13@kan> <697195597.121770130.1449500982738.JavaMail.zimbra@uoguelph.ca> Date: Mon, 7 Dec 2015 08:18:32 -0800 Message-ID: Subject: Re: slow screen updates on laptop console (i386) From: Adrian Chadd To: Rick Macklem Cc: Alexander Kabaev , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 16:18:32 -0000 Hi, ok. please file a bug for that. It may be something to do with the hardware and sleep states and skipping wakeups/interrupts or something. Please try using the default again (LAPIC?) and set kern.eventtimer.periodic=1. See if that fixes it. (i've had to debug this a few times before.) -a From owner-freebsd-current@freebsd.org Mon Dec 7 20:49:07 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DB629C1C69; Mon, 7 Dec 2015 20:49:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0132.outbound.protection.outlook.com [157.56.110.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 789671470; Mon, 7 Dec 2015 20:49:06 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BL2PR05CA0050.namprd05.prod.outlook.com (10.255.226.50) by BLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) with Microsoft SMTP Server (TLS) id 15.1.337.19; Mon, 7 Dec 2015 20:48:58 +0000 Received: from BL2FFO11FD056.protection.gbl (2a01:111:f400:7c09::104) by BL2PR05CA0050.outlook.office365.com (2a01:111:e400:c04::50) with Microsoft SMTP Server (TLS) id 15.1.337.19 via Frontend Transport; Mon, 7 Dec 2015 20:48:58 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BL2FFO11FD056.mail.protection.outlook.com (10.173.161.184) with Microsoft SMTP Server (TLS) id 15.1.337.8 via Frontend Transport; Mon, 7 Dec 2015 20:48:58 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Dec 2015 12:48:56 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tB7KmuD62668; Mon, 7 Dec 2015 12:48:56 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id DA928580A9; Mon, 7 Dec 2015 12:48:55 -0800 (PST) To: Mark Millard CC: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current , Subject: Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix In-Reply-To: References: Comments: In-reply-to: Mark Millard message dated "Sun, 06 Dec 2015 07:21:19 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16607.1449521335.1@chaos> Date: Mon, 7 Dec 2015 12:48:55 -0800 Message-ID: <2426.1449521335@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD056; 1:HjEwlq3Hf8YvmAWgvsgmuN04IZLOmIt3w8aizVaaTB4eSsyEt2+utTmn0ZK6tjkQb5H3urbhAKK3u38ZDfGwX/DJ9b24/ZrwN4pfHURV7e5gXcsNkIeNAMgfNv2LHlOADpm9qR7oT/S5kf2PbHGDvHLdw0r/LZWIuzXblkATvy+HaSMXeSWRB7jB5Fjojbc24YHzoqrzR9i9QE5jY+VJ4Ed0GVTKzTME1NBdW68DS4R3G/ynmdpV8TgDOJn5PhM8b0ZMvRSAO/SBG94fQBDOOoGKYFeaZIL+M25OjM5O/4/4QiIve9fbbSgvEzjnCDVwE4RnOCYamUoDlTSF+ZRpF6C7o+jy/jIqSdikFDo/5S5WyQoqS6zQsx4UNWn1nz9R2gA8Tz9QFPFN5rohWjnX5Q== X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(199003)(24454002)(69596002)(586003)(86362001)(6806005)(81156007)(57986006)(23726003)(11100500001)(33716001)(50226001)(76506005)(19580395003)(19580405001)(1096002)(105596002)(106466001)(5008740100001)(1220700001)(4001430100002)(110136002)(189998001)(76176999)(50986999)(50466002)(97736004)(5001960100002)(107886002)(47776003)(87936001)(46406003)(117636001)(77096005)(97756001)(2950100001)(92566002)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB053; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB053; 2:Bre35UskhoEgBghVtCIJfTSeFPsyq6L2GiSTxOsA+THDK9ghdfbWfY8rVUxyroT7P2RM23aM3EphfgOJ3Ny0Z56jWCF+VQXNqEMcdgreZ6K8VE5MoKBzWn7IhjhNkVBikMmNreJwpzzGfmIkbzDwNQ==; 3:DbfiA4rQdaT0QX9BDm5bGFOItJSMD6Vx0vwTOT0mEolnANwKkQY0STdpyDzwpamcJVZfaFp4mY7kxA8afHXUOwe/pGEX2uUuyOXWwMWcrO1alPjn4J66I3hWLXqWpN40lpJpzhUn+51CM/mcqrI5G3ysU739c9AtnYZMlPCeaIsbUIjPwn7D3lzvpuG1NrDGszXYORj7n8T3BKbdKwoS+jtkBF4rE11r6/qBC2iUkLQ=; 25:EQNOxZh0J1Xw1nFNxRw02BvCpem+8mNiSyKkil2Xgg13x/qE5jwbYFHcMi6vRi+1ce1tGIqNv/gkZdqOGVBKhLZn9PDVf1jNDK5Wp5gsV+AiOvUCPyBOsynWh6KbxUggzcQ8vf+ZyOdMxV4swnjbOP6nDPLj48tq7U5Y+leO1M4OWtVh63GO+N/DKEjSfNJPdf3WYJgsESqlizVtEDmgMiAJ5gLUC/36BFY9EgcbD6QGl3glvi/5f+FRGBmmfmGq/JtMesY2LUr1uuZYnPlGDQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB053; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB053; 20:VzYHxABT14qW/oPfMDVv79V1a1uo+x+oGKBP2NPOCuU1CgQfj70ABSAOwuimtFa3ysmAI+isJGlc83zIVfI3WuJgybADSr9csLF7hWMB+RoQ9vUOeLNIqVUHNg2iwl6p7B1zVfShGH79wW1Ya6BodIIbZMoqkSrJaJan7pzW7JyykgDLcSlmclWwsVNVgztq8AsiGMfiqbwPvxO8ArdjHG+w6PD0EupIljOR6UZyOgcYOTe4vwCOV9jZdFdeXydbQ/GGr03vA4mEpaXno+BtUwGBdQcStGiNftY7n7NdRIcdK/csJPNRpmefqwV7bVLRr2Du1oxiVElGUUxshwic2qwFzkqAvkh6atpAySThH62rsLcIl6LDMNfW3QEMZCkxEm0dMhdPCtByja93NAibEMto42IsbahjHgwXzETtevdGrCoL1GE8PMmsIi1GWb5jD8SxJQQ7pnVJ7SYt7A+YBioWFqHrPteRlpv3GxRrOgyLymdgQepd0m+stX57kfV9; 4:zLN7mkfhdTZjZAZWKB50qimi55+8kVmdBuy2weEW/aZG2/deg0gh/UdnKphx0OZ7dF+jmxcgDtdFiyZOJoFHd/lPqSO550dW8YRnvR9QNOc1Hm89YrkRZF0/KuV4DaYoDQHRy/O9FDmYoji1WPLQHgW9XrzULnd0vcr9WLMgrFfoG0WbiPhloHLDO9p4NiAGvorxTwRq+xw8u0gsZRZT2i6J0H8rwtvf/QPXI/NMc5mz/4ntoP8aESuF8TKv4xv8BcqFNDhktxpK0BQ7j16kHmhB6EQmLSLY6PPBXVDqcuPXBRKBFBEEbPy5V0xdgJ2BvNkCUFf+eFpyhIMg1acZtJguML5teihvmf0c5fRi2KpezAUEGMZzFtZZ1ld+XZVR X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BLUPR05MB053; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB053; X-Forefront-PRVS: 078310077C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB053; 23:HZ73pB51Xv0nO1Op6i9ESeLr+v827xjZBnnrYwkjpH?= =?us-ascii?Q?PmpNmTn6RWJPL87rJcHXki2V8vA9ENSTCs6Ei+4ODRxzeDWGWQFXwYNN638U?= =?us-ascii?Q?nG0NMOZeervMqK5+dL7TvKfIMYGKeGB517g/3qqb1VXJ09CCgNokoMomX9JR?= =?us-ascii?Q?6KfFIPHrTIfTp5meT6CPl7w2HLjPu7xgUArGZXINFqdNRIqWnTd/NkJqwjpk?= =?us-ascii?Q?+NN5oexiPlQjTz97wffMKE6cmMVt5RkQu2R1MsgUZKUdn8MZR4OwZf/ctOTn?= =?us-ascii?Q?jeZ4mhJyuNfgOJAcbxskdkVQwR9uS59Rw9YY0iKfu8bS3m/oNzU4jI88n3jw?= =?us-ascii?Q?QuEOFTWJRQyOHDhGD6Aq7TqZT+RHb8acxARhq2oXwFVZFhF610PSfp4dYZPb?= =?us-ascii?Q?jqLAIoBV1+UjT3zBHYXCpBN7FhuhqVW/ZKqZ1jVLg1ZHxcMaFP46wNinxFsB?= =?us-ascii?Q?iQJ9TrhHEStJOTPrmTZDNlpfmrhrKL93X1k3Lx4yQFKKa6jRI0STOOhzyqpZ?= =?us-ascii?Q?5A8YWIvx8+Tff8qfUf9QEgIrLe+B0DwZbzjeQpK1y8fnQq9bWl+NEusJoDu0?= =?us-ascii?Q?uRrF2pPGwIY21+Jy/0QgCBBuN437soxOLSt/pVb+TlzjpSa9HCKnaCkBu+Pb?= =?us-ascii?Q?97+Y1AaJBCZp4Happux7CYowk0S51R48sLesNwBkOR4DOkB6rjUVkuUVj5/d?= =?us-ascii?Q?rm7oOOucHhpqA24ANWIaIjoI3WOQtZ/5ao0le2x7PvGrmz4qL2JdJvrYJLXi?= =?us-ascii?Q?QOjlQ1EPeumfuUcdBiN45r0tWBOMcQfSUrrjloa63+X+ZZgyOTefCLY3GOVT?= =?us-ascii?Q?U4JYZFuHIPBaXB4IPntLwS/GAOR55fURoSfuz4Vk6HTrfP43xAYbwDyi7/tU?= =?us-ascii?Q?elJF8r/Wk632POWsXD5SuN1OIwVkeFBfZwuxnSyRnvpBI+f4mRoc4SheRHeN?= =?us-ascii?Q?F16qFz1KWwlOm1PP3s3EB+TwZwTz1jH7HGHY349dJ6k3Pj5EIkQ78xB07bnJ?= =?us-ascii?Q?xOAjZ+QUWK+baPqvevYf1ldmHJa09Fhe3KAytAKt5l30dG/+WpuQ0zqtogin?= =?us-ascii?Q?fsgS7WOuHPBBbiCdcd9E0/y5bVkprw41IAKC5T70h8aQdzfOZIXzb2Y/TGHh?= =?us-ascii?Q?uEmnjTFKA=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB053; 5:CRpju4AnzHujn3WiOnIUkQYXqmBuhLGlFKHSg8yBJT/DzOTj7dCLgfB2Zypa4S8iLChDHaZ3zSqJin+w0F0TOj8VbrktRhS8EKHJPRsvYwXmz2AsTrI+kNagOgaKflagihAcAXqm5rWdhTh35iUjgA==; 24:HnfwEEhWX2gekZIg8WlOxpdg4fS6e1DmPPgUBaNg2h2mjgNxzNiYKP6l5nzUf3v5dcbdnmENwzgGqB5wBsTilpBieZkgcUvP8WFKRAlAW9Y= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2015 20:48:58.1220 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB053 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 20:49:07 -0000 Mark Millard wrote: > My guess is that it is picking up the > > MAKEOBJDIRPREFIX=/usr/obj/xtoolchain You should use ?= if you want this to work. There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked in the environment of a sub-make. By using = above, you break that. From owner-freebsd-current@freebsd.org Mon Dec 7 21:33:14 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0EAB9B7248 for ; Mon, 7 Dec 2015 21:33:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 A430411B8 for ; Mon, 7 Dec 2015 21:33:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25146 invoked from network); 7 Dec 2015 21:33:06 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 Dec 2015 21:33:06 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 07 Dec 2015 16:33:06 -0500 (EST) Received: (qmail 716 invoked from network); 7 Dec 2015 21:33:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 7 Dec 2015 21:33:06 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2EA0B1C43C4; Mon, 7 Dec 2015 13:33:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix From: Mark Millard In-Reply-To: <2426.1449521335@chaos> Date: Mon, 7 Dec 2015 13:33:05 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <2426.1449521335@chaos> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 21:33:15 -0000 > On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty wrote: >=20 > Mark Millard wrote: >> My guess is that it is picking up the >>=20 >> MAKEOBJDIRPREFIX=3D/usr/obj/xtoolchain >=20 > You should use ?=3D if you want this to work. > There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is = tweaked > in the environment of a sub-make. >=20 > By using =3D above, you break that. That presumes that MAKEOBJDIRPREFIX has not been assigned a default = value before the SRC_ENV_CONF file has been included the first time. If = MAKEOBJDIRPREFIX had been defined already then the ?=3D would do nothing = and the wrong value would be used. I believe that the following trace shows that such an assignment of a = default value does happen first, making ?=3D not work either. /usr/src/Makefile (head/Makefile 29160) has > MAKEOBJDIRPREFIX?=3D /usr/obj at line 145 (used when it is not using targets/Makefile from the = relevant .if/.else/.endif). Line 105 has .include and there no others before the = above assignment. bsd.compiler.mk in turn includes bsd.opt.mk (only), = which in turns includes bsd.mkopt.mk (only). That in turn includes = nothing else. So these files and only these files are the involved files = before that assignment as far as I can tell. None of these get to src.sys.env.mk and so SRC_ENV_CONF use has not = happened yet when=20 > MAKEOBJDIRPREFIX?=3D /usr/obj is executed. So, if I understand right, MAKEOBJDIRPREFIX is already defined before = the code > SRC_ENV_CONF?=3D /etc/src-env.conf > .if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_) > .-include "${SRC_ENV_CONF}" > _src_env_conf_included_: .NOTMAIN > .endif is executed and so using ?=3D would not be effective in the included = file. Did I miss something? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Dec 7 22:33:39 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABA419D3B32; Mon, 7 Dec 2015 22:33:39 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C188A1D96; Mon, 7 Dec 2015 22:33:38 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BL2PR05CA0030.namprd05.prod.outlook.com (10.255.226.30) by BY2PR05MB062.namprd05.prod.outlook.com (10.242.34.147) with Microsoft SMTP Server (TLS) id 15.1.331.20; Mon, 7 Dec 2015 22:19:11 +0000 Received: from BL2FFO11FD026.protection.gbl (2a01:111:f400:7c09::136) by BL2PR05CA0030.outlook.office365.com (2a01:111:e400:c04::30) with Microsoft SMTP Server (TLS) id 15.1.337.19 via Frontend Transport; Mon, 7 Dec 2015 22:19:10 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BL2FFO11FD026.mail.protection.outlook.com (10.173.161.105) with Microsoft SMTP Server (TLS) id 15.1.337.8 via Frontend Transport; Mon, 7 Dec 2015 22:19:10 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Dec 2015 14:15:47 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tB7MFjD38615; Mon, 7 Dec 2015 14:15:45 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id 6D014580A9; Mon, 7 Dec 2015 14:15:45 -0800 (PST) To: Mark Millard CC: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current , Subject: Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix In-Reply-To: References: <2426.1449521335@chaos> Comments: In-reply-to: Mark Millard message dated "Mon, 07 Dec 2015 13:33:05 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22804.1449526545.1@chaos> Date: Mon, 7 Dec 2015 14:15:45 -0800 Message-ID: <2852.1449526545@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD026; 1:w4tRoobhgrEMUPWc3GhBrXtKDkc2CxaP8VskuHdmos/BNWzxSFn3JMSIIs6/z1mVMXp5eWRLALUI3AZUss3oIf6zyQ86y8yaDaCewJXvqhkI2KGZxNua7eYrMquMB08qR4Mv8kO8c+xHON8aqgg9rCn/kKh9XfTp3j62IvJ+KeP4EFSkirtbTNocfvW4Py5ghlBoMveqtdmbe9sYzp/V4glBbxRp5nRqD0TzKGRb1WLGfbNRyjytf4Ys7MH6Gh7ArNewa28VWzBgYx0bZx+axrp1crNccK/kqUHxgnBMhcSs1Kv30YDAYxMgBkwb7JuMZPHArKFO+PxHnqRc35/jmLMv9Vm4o8BqyL/V/hfKgyGMIabses/gmPpe4j4j24tfAw0kcpBXE+6ntug7149TWA== X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(199003)(24454002)(5008740100001)(97736004)(81156007)(50986999)(1220700001)(97756001)(76176999)(46406003)(50226001)(4001430100002)(19580395003)(189998001)(19580405001)(69596002)(57986006)(76506005)(105596002)(1096002)(92566002)(586003)(87936001)(23726003)(11100500001)(86362001)(2950100001)(47776003)(5001960100002)(107886002)(77096005)(117636001)(50466002)(6806005)(33716001)(110136002)(106466001)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB062; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB062; 2:k/Nu/wzCtz6ii9eWRStFsYwljxT57TCIko5IWZChGZ5D67dJ+gc+usqtbFFw7FADC1DGH8Bc1HUofkkwmPp1EpLozrLqDeYSplwXHpmM3GNud6rCX7+GQcIJBKhFrIU/vxbAHKwgiJ1/wx/Orye/Pg==; 3:AfHU6ONU/uMStbrAZfdydGz7NAgg29LKyHZsTYIkq7lXw/Iyjv7sZgW61rcDFN3yNtODhReUruWlarkHP3BEdaJMktXSe26WBa/pt/HwyndGrY+dYl08+Sfrex9PmdVgkBjHq30yy4G5cGa8dqBNiQJa7vecEgGKD9uSWVB/EkiR77KPBniEW49XzCqsu/pU82wmIWxDVCBK3XflNeOHVhS9RGGJTQShyqoo1q9zrWQ=; 25:wT8z9YKfQxHvZusXCHI7I3N/cGQK20SThztL2HhASpHFnFlCZNhdMSVt9pUZugiAboyysouVzi3joiVBdQ5UfAPNFdL/aioUBQ0f9QJnRgi4lIppJiHh8blkSF0WpOcfWX+OOvHYUUVjDjDUYUhaGun92WOdNGl1gAFMI/l8Sri47Np7qO32Sh+EDWHeCGfx4u+W+qd+rRcjPrQd9YPjY0z+RWwbx+emFcIkmlOElYjbSUHPyepgB2Evz12NlVyfobNfnkxG/WUPU+VRdskw4w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB062; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB062; 20:6qkhkl+f4+EDN5stQUaSIzuTIdHPa0pc/NV1AXA+CzQYFX4sDAHAwhw+A3LDWNfp5cLOTlmGrvIFHBQCTO67o5gSB4hlUr5CJbQyLqWqG7h6ejtrfYV+OA/4VYET3IAejMyU5HBDCWFYlBXys6QaIDLlbucyJzMe/g9nM64FzHmqUwvoCDksBRnwvvDXkYejBsHuUiDkcOaj1+Hbhg/UMTwYQ2jjsKZJ+X0fsp/Zqwlr0lwPowlGGmMdsufj4XLGNlTbWbfWdRBOGIVcg+1kJ0stojhdVtLKnF0bi0BRYfY2JHNobzFElSb7gWV6u3pqSplh0Fuxz4hUpKVZ4X8tnhQW450c4+ZcHjl5YkliU4hC4Q3MFQEHQHJW+QflQvClPkclOw5vgJkRfxuEPomq3PuHtKWv/e1jsbTIwSdmWQ6KD6cJx0FdTbQqHGwK0iYKiyeHklkfbWnezG7DaVK17wKHMCuCndWgJ7Eu/riDfbQmjaYXiIB5xLOOMwPgByeY; 4:S+G3ikOQ5QRDrgByqF4XnDe4/LIWwO4gjhwQk1dHC1366DxDciAk+Dp7jsWtn7h93OV//C1XnuUvM9b2i5CdydeZ4H+cY9+sxkYjCGBd4WuNVeo1F1CRJinPT/1qY1lJ//lQKQq6xDgCKLGwb5ouaVjAj3/O18WDdqmPGO6OO9kterDYD5tTSWX43IsA+pS0h76SqYUAiJCKZj1QKYRdBAus/ohgQifsZFzgiDte2LLl2hA6CP79yNceFmTpl4Jat07fRlJot30GakXBJdUwTKGVziSeMW1Gru9XjRx3HK7CW2KT31rpcwOiYEAxKGQeObuqiQVOWYd6jPo99/hejcJoFBczFv08Iteoo7xBNEESy2Kt1v7x3OgG4WBYoLUw X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR05MB062; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB062; X-Forefront-PRVS: 078310077C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB062; 23:z1fcTy2fI9dWS3Dm/jX2CflvOk5aUyHWDFhI+NtPhK?= =?us-ascii?Q?g+0RPrbqRmGsQcL3q7CGXpa5dkUvDm6Ec9qQvDxyUsC08bwHkBW07Ll5Ftnr?= =?us-ascii?Q?bJZt+j/sIwmoEZKlowOOvmmQRHjf831xxsKy7hgkGoiP+tQ7JbMQxsCDwy04?= =?us-ascii?Q?z7E5SFUR0s3tVFUd1L6c3OfB4hjvzdQhwXA/ezOMxQBLk1QQ/wSQ1Q5oruC0?= =?us-ascii?Q?Kudy7dwly7PakoTY2OR7o6x4hEVz7sCJ7lP1CxMan6WV3zKde0nP3DflgRLz?= =?us-ascii?Q?IeDnfUUd2o54/Gn+DqMVWuBt2WZij38m1fGS2dYvwZaMaUNaStZmbHAhOMAF?= =?us-ascii?Q?d8T63aKr0XlFrGA3tQFd2biLgRUxxPyaAi/Z6WT87z/w0/sgtmq/EqWreUWV?= =?us-ascii?Q?9Bkjev0GOCNgSAt2CM/kiHkzYwcZC03HMS6uw5ZR38Oxzt6c3vYuRQVQMh4t?= =?us-ascii?Q?9PoG2Iw7yHuHchMHkHTwDmWDVidod+KFmIoudF1H+OWHgCBsXzHc3j3/5gCb?= =?us-ascii?Q?CpO21Qvjuvw9WbP6SQs0AC/j2Gp4vonfPcgHgdWcRwzJxxInHq4XwZUBhg+7?= =?us-ascii?Q?O12tnESPG9oYqisS8I9lAX4FX53zTAZ62kKfmc1Kudf/We4jsfsavmh2ddJe?= =?us-ascii?Q?za+tXji+Hl/qzLEeEzpARI6c7GKnYXhYaKfL20uOHuSMLPnecdo1rH5k0K5v?= =?us-ascii?Q?8T/PMCxuXZMy0DPp4ADvzih3KazRkGc1szrlcK9MR+ejToU6avpenqiY14VP?= =?us-ascii?Q?rDIZnO/RRzOD1cTVdPWTCvAsPvrvXHUemSOuQ0n72kKLK7TUSO1abg0IQUla?= =?us-ascii?Q?tEPDqWHO/Xejm5hoGmzgZFvByu8PdMjK0lq/0CktsMCmZIh27Y/l5x4NyKFf?= =?us-ascii?Q?bZN1+L8w4pMpQePvpopIWC6H/K+luwjXRW29p5ay/JYG6MFQDepU6LLM+oFL?= =?us-ascii?Q?3wCvCzjdu44d6twZLqiLmYpwL4CKI/VVgxLDrofw4LPrlaSAMOobDO3ExrsV?= =?us-ascii?Q?+POjRwsmbfDmKW2HKzPoUBvsi9qW8Hao+ZqVOFDSFIrpH2jlLF2zxkIs6/G/?= =?us-ascii?Q?NEJxQ+GIVf99PkHZARUlHJZ+1r2oOKl1+9kBgjogdX3WrqLw0/hp2Rtm2i9O?= =?us-ascii?Q?oP8yeCOjc=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB062; 5:+++UgpfV3dFXdBOAQ0NXRIO8XXh1lAzPN73OIZ0VdIKxGWpfNkbQMA5oBgpvEdk5Q/Uzjx1uPSEtAbMu2fn90mLZMCZ77SEyKntH6fnnmz5ZeNEoB4ohzsh/1zhF13NEU2D3D2pgzwVgWUbIPxzmkg==; 24:wfbghy9nz1hQyNtvbsV5sthw5tjQxYAOeUEJBACNce20dY02Kpawr+BCb6y5iyp0H0T1QyiEkPdsfjefm8V1aawOtxpZa2clQBG2zvd1lfo= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2015 22:19:10.3948 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB062 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 22:33:39 -0000 Mark Millard wrote: > >> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain > > > > You should use ?= if you want this to work. > > There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked > > in the environment of a sub-make. > > > > By using = above, you break that. > > That presumes that MAKEOBJDIRPREFIX has not been assigned a default > value before the SRC_ENV_CONF file has been included the first > time. Yes. If that's a concern: .if ${.MAKE.LEVEL} == 0 MAKEOBJDIRPREFIX= /usr/obj/xtoolchain .export MAKEOBJDIRPREFIX .endif will do what you want. From owner-freebsd-current@freebsd.org Mon Dec 7 23:01:11 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9ED1D9B9325 for ; Mon, 7 Dec 2015 23:01:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 604EB1BC8 for ; Mon, 7 Dec 2015 23:01:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:AuB06h3so8YiFUv+smDT+DRfVm0co7zxezQtwd8ZsegRIvad9pjvdHbS+e9qxAeQG96LtbQd0aGP6+jJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6MyZ3tnLnqs7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjN92Mq+nBXZTAKJrlAcW2ka2k5BDxLE5Re8VZf4vifSue902S3cNsrzG+MaQzOnup1qQxygrS4MNDo09SmDkMl5h6FfrReJuhtw3oPQeIHTP/MoLfCVRs8TWWcUBpUZbCdGGI7pKtJXV+c= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BNBQCYDmZW/61jaINehQG9OFqBFIYOAoIAEwEBAQEBAQEBgQmCLYIIAQEEI1YQAgEIGAICDRkCAlcCBIhCsCmQZAEBAQEBAQQBAQEBAQEBARuBAYVThH2Hd4FEBY4fiEKPF4RDlk0CIwI+hCIghRyBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,396,1444708800"; d="scan'208";a="254738081" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 07 Dec 2015 18:01:09 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 0054815F55D; Mon, 7 Dec 2015 18:01:08 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0v3x9rQsSypy; Mon, 7 Dec 2015 18:01:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id A7E6815F565; Mon, 7 Dec 2015 18:01:08 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nWNfHRhHfC5X; Mon, 7 Dec 2015 18:01:08 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 8E55415F55D; Mon, 7 Dec 2015 18:01:08 -0500 (EST) Date: Mon, 7 Dec 2015 18:01:08 -0500 (EST) From: Rick Macklem To: Adrian Chadd Cc: Alexander Kabaev , FreeBSD Current Message-ID: <387840531.122544462.1449529268528.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> <20151207091815.16e11a13@kan> <697195597.121770130.1449500982738.JavaMail.zimbra@uoguelph.ca> Subject: Re: slow screen updates on laptop console (i386) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: slow screen updates on laptop console (i386) Thread-Index: wiNXC/ioRwiW0wz0M2NuCdmwjcpnkQ== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 07 Dec 2015 23:01:11 -0000 Adrian Chadd wrote: > Hi, > > ok. please file a bug for that. It may be something to do with the > hardware and sleep states and skipping wakeups/interrupts or > something. > > Please try using the default again (LAPIC?) and set > kern.eventtimer.periodic=1. See if that fixes it. > Actually made it worse. Instead of being intermittently slow, it was almost constantly slow. I have no idea if these sysctl #s are useful: kern.eventtimer.et.LAPIC.frequency: 49876422 kern.eventtimer.et.LAPIC.flags: 15 rick > (i've had to debug this a few times before.) > > > > -a > From owner-freebsd-current@freebsd.org Tue Dec 8 03:23:42 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1BA19D374A for ; Tue, 8 Dec 2015 03:23:42 +0000 (UTC) (envelope-from mmcco@mykolab.com) Received: from mx-out02.mykolab.com (mx01.mykolab.com [95.128.36.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 BFFAE11A7 for ; Tue, 8 Dec 2015 03:23:42 +0000 (UTC) (envelope-from mmcco@mykolab.com) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-10 required=6.31 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, FREEMAIL_FROM=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102]) by mx-out02.mykolab.com (Postfix) with ESMTPS id 484206140C for ; Tue, 8 Dec 2015 04:13:30 +0100 (CET) Date: Mon, 7 Dec 2015 22:13:27 -0500 From: Michael McConville To: freebsd-current@freebsd.org Subject: [PATCH] XOR uses Message-ID: <20151208031327.GA17554@thinkpad.swarthmore.edu> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Mailman-Approved-At: Tue, 08 Dec 2015 04:34:36 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 03:23:43 -0000 A minor simplification patch: Index: sys/arm/allwinner/a10_gpio.c =================================================================== --- sys/arm/allwinner/a10_gpio.c (revision 291978) +++ sys/arm/allwinner/a10_gpio.c (working copy) @@ -356,10 +356,7 @@ sc = device_get_softc(dev); A10_GPIO_LOCK(sc); data = A10_GPIO_READ(sc, A10_GPIO_GP_DAT(bank)); - if (data & (1 << pin)) - data &= ~(1 << pin); - else - data |= (1 << pin); + data ^= (1 << pin); A10_GPIO_WRITE(sc, A10_GPIO_GP_DAT(bank), data); A10_GPIO_UNLOCK(sc); Index: sys/arm/altera/socfpga/socfpga_gpio.c =================================================================== --- sys/arm/altera/socfpga/socfpga_gpio.c (revision 291978) +++ sys/arm/altera/socfpga/socfpga_gpio.c (working copy) @@ -336,10 +336,7 @@ GPIO_LOCK(sc); reg = READ4(sc, GPIO_SWPORTA_DR); - if (reg & (1 << i)) - reg &= ~(1 << i); - else - reg |= (1 << i); + reg ^= (1 << i); WRITE4(sc, GPIO_SWPORTA_DR, reg); GPIO_UNLOCK(sc); Index: sys/arm/rockchip/rk30xx_gpio.c =================================================================== --- sys/arm/rockchip/rk30xx_gpio.c (revision 291978) +++ sys/arm/rockchip/rk30xx_gpio.c (working copy) @@ -375,10 +375,7 @@ return (EINVAL); RK30_GPIO_LOCK(sc); data = RK30_GPIO_READ(sc, RK30_GPIO_SWPORT_DR); - if (data & (1U << pin)) - data &= ~(1U << pin); - else - data |= (1U << pin); + data ^= (1U << pin); RK30_GPIO_WRITE(sc, RK30_GPIO_SWPORT_DR, data); RK30_GPIO_UNLOCK(sc); Index: sys/arm/samsung/exynos/exynos5_pad.c =================================================================== --- sys/arm/samsung/exynos/exynos5_pad.c (revision 291978) +++ sys/arm/samsung/exynos/exynos5_pad.c (working copy) @@ -722,10 +722,7 @@ GPIO_LOCK(sc); reg = READ4(sc, bank.port, bank.con + 0x4); - if (reg & (1 << pin_shift)) - reg &= ~(1 << pin_shift); - else - reg |= (1 << pin_shift); + reg ^= (1 << pin_shift); WRITE4(sc, bank.port, bank.con + 0x4, reg); GPIO_UNLOCK(sc); Index: sys/dev/nand/nandsim_ctrl.c =================================================================== --- sys/dev/nand/nandsim_ctrl.c (revision 291978) +++ sys/dev/nand/nandsim_ctrl.c (working copy) @@ -388,9 +388,6 @@ rand = random(); if ((rand % 1000000) < chip->error_ratio) { bit = rand % 8; - if (*byte & (1 << bit)) - *byte &= ~(1 << bit); - else - *byte |= (1 << bit); + *byte ^= (1 << bit); } } From owner-freebsd-current@freebsd.org Tue Dec 8 04:40:26 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8918B9D385D for ; Tue, 8 Dec 2015 04:40:26 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::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 566461C13 for ; Tue, 8 Dec 2015 04:40:26 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by obcse5 with SMTP id se5so5856975obc.3 for ; Mon, 07 Dec 2015 20:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=E7y+m0FHNzQTqjRWcDxEJqkVL8dL3Gbz5QVSZv234Z0=; b=DAYBLoboJNThKUDbhLYGOR8XPkSyVIKviCAm5XxN9bL/v7S1E1ZST+m4bVqXfwyXgX wBqSyYYiAk0RO6StfCswEtK7vKkR2DURI6D/QzCp7E4Eo6HMhqPqP9Wpsto6oIl/j0oK fuHTeKkckQ2/+rOl5Hf5aF349wG7VQpWa0DdTcYj58c9pT8Wcwu4ou5ineF+soGl2wbG EXy/qeLCygypMfE2HcV89NT7m+ma36+hw4Kj2RXX2JZaFis8qgri7q9XnWaGdjwuMKxH vqVOQZdt8m0DNsusWe9sFnbJmsbkjQtaWUXufrhQJ3PCUCqav3mOA0QOk/b+zLjPyC57 cQKg== MIME-Version: 1.0 X-Received: by 10.60.39.200 with SMTP id r8mr751547oek.81.1449549625535; Mon, 07 Dec 2015 20:40:25 -0800 (PST) Received: by 10.182.241.201 with HTTP; Mon, 7 Dec 2015 20:40:25 -0800 (PST) Reply-To: araujo@FreeBSD.org In-Reply-To: <20151208031327.GA17554@thinkpad.swarthmore.edu> References: <20151208031327.GA17554@thinkpad.swarthmore.edu> Date: Tue, 8 Dec 2015 12:40:25 +0800 Message-ID: Subject: Re: [PATCH] XOR uses From: Marcelo Araujo To: Michael McConville Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 04:40:26 -0000 Hi Michael, What would be the advantage of it? I still prefer explicit than implicit. The current code is much more readable. Best, 2015-12-08 11:13 GMT+08:00 Michael McConville : > A minor simplification patch: > > > Index: sys/arm/allwinner/a10_gpio.c > =================================================================== > --- sys/arm/allwinner/a10_gpio.c (revision 291978) > +++ sys/arm/allwinner/a10_gpio.c (working copy) > @@ -356,10 +356,7 @@ > sc = device_get_softc(dev); > A10_GPIO_LOCK(sc); > data = A10_GPIO_READ(sc, A10_GPIO_GP_DAT(bank)); > - if (data & (1 << pin)) > - data &= ~(1 << pin); > - else > - data |= (1 << pin); > + data ^= (1 << pin); > A10_GPIO_WRITE(sc, A10_GPIO_GP_DAT(bank), data); > A10_GPIO_UNLOCK(sc); > > Index: sys/arm/altera/socfpga/socfpga_gpio.c > =================================================================== > --- sys/arm/altera/socfpga/socfpga_gpio.c (revision 291978) > +++ sys/arm/altera/socfpga/socfpga_gpio.c (working copy) > @@ -336,10 +336,7 @@ > > GPIO_LOCK(sc); > reg = READ4(sc, GPIO_SWPORTA_DR); > - if (reg & (1 << i)) > - reg &= ~(1 << i); > - else > - reg |= (1 << i); > + reg ^= (1 << i); > WRITE4(sc, GPIO_SWPORTA_DR, reg); > GPIO_UNLOCK(sc); > > Index: sys/arm/rockchip/rk30xx_gpio.c > =================================================================== > --- sys/arm/rockchip/rk30xx_gpio.c (revision 291978) > +++ sys/arm/rockchip/rk30xx_gpio.c (working copy) > @@ -375,10 +375,7 @@ > return (EINVAL); > RK30_GPIO_LOCK(sc); > data = RK30_GPIO_READ(sc, RK30_GPIO_SWPORT_DR); > - if (data & (1U << pin)) > - data &= ~(1U << pin); > - else > - data |= (1U << pin); > + data ^= (1U << pin); > RK30_GPIO_WRITE(sc, RK30_GPIO_SWPORT_DR, data); > RK30_GPIO_UNLOCK(sc); > > Index: sys/arm/samsung/exynos/exynos5_pad.c > =================================================================== > --- sys/arm/samsung/exynos/exynos5_pad.c (revision 291978) > +++ sys/arm/samsung/exynos/exynos5_pad.c (working copy) > @@ -722,10 +722,7 @@ > > GPIO_LOCK(sc); > reg = READ4(sc, bank.port, bank.con + 0x4); > - if (reg & (1 << pin_shift)) > - reg &= ~(1 << pin_shift); > - else > - reg |= (1 << pin_shift); > + reg ^= (1 << pin_shift); > WRITE4(sc, bank.port, bank.con + 0x4, reg); > GPIO_UNLOCK(sc); > > Index: sys/dev/nand/nandsim_ctrl.c > =================================================================== > --- sys/dev/nand/nandsim_ctrl.c (revision 291978) > +++ sys/dev/nand/nandsim_ctrl.c (working copy) > @@ -388,9 +388,6 @@ > rand = random(); > if ((rand % 1000000) < chip->error_ratio) { > bit = rand % 8; > - if (*byte & (1 << bit)) > - *byte &= ~(1 << bit); > - else > - *byte |= (1 << bit); > + *byte ^= (1 << bit); > } > } > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-current@freebsd.org Tue Dec 8 06:10:59 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8852D9D34BE for ; Tue, 8 Dec 2015 06:10:59 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D9041F3F; Tue, 8 Dec 2015 06:10:59 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id tB86Apx0000899; Mon, 7 Dec 2015 22:10:55 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201512080610.tB86Apx0000899@gw.catspoiler.org> Date: Mon, 7 Dec 2015 22:10:51 -0800 (PST) From: Don Lewis Subject: Re: panic: sbuf_vprintf called with a NULL sbuf pointer To: jhb@freebsd.org cc: freebsd-current@freebsd.org In-Reply-To: <483094235.OWQWKtkdYD@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 06:10:59 -0000 On 2 Dec, John Baldwin wrote: > On Wednesday, December 02, 2015 01:25:56 PM Don Lewis wrote: >> > If you want to look at this further, try going to frame 16 and dissassembling the >> > instructions before the call to see if you can spot which register the first >> > parameter (saved in %rdi IIRC) comes from. >> >> Dump of assembler code for function sbuf_printf: >> 0xffffffff80a673e0 <+0>: push %rbp >> 0xffffffff80a673e1 <+1>: mov %rsp,%rbp >> 0xffffffff80a673e4 <+4>: push %r14 >> 0xffffffff80a673e6 <+6>: push %rbx >> 0xffffffff80a673e7 <+7>: sub $0x50,%rsp >> 0xffffffff80a673eb <+11>: mov %rsi,%r14 >> 0xffffffff80a673ee <+14>: mov %rdi,%rbx >> 0xffffffff80a673f1 <+17>: mov %r9,-0x38(%rbp) >> 0xffffffff80a673f5 <+21>: mov %r8,-0x40(%rbp) >> 0xffffffff80a673f9 <+25>: mov %rcx,-0x48(%rbp) >> 0xffffffff80a673fd <+29>: mov %rdx,-0x50(%rbp) >> 0xffffffff80a67401 <+33>: lea -0x60(%rbp),%rax >> 0xffffffff80a67405 <+37>: mov %rax,-0x20(%rbp) >> 0xffffffff80a67409 <+41>: lea 0x10(%rbp),%rax >> 0xffffffff80a6740d <+45>: mov %rax,-0x28(%rbp) >> 0xffffffff80a67411 <+49>: movl $0x30,-0x2c(%rbp) >> 0xffffffff80a67418 <+56>: movl $0x10,-0x30(%rbp) >> 0xffffffff80a6741f <+63>: mov $0xffffffff8137bdf8,%rdi >> 0xffffffff80a67426 <+70>: mov %rbx,%rsi >> 0xffffffff80a67429 <+73>: callq 0xffffffff80a66c00 <_assert_sbuf_integrity> >> >> >> 0xffffffff80a237b9 <+825>: jmpq 0xffffffff80a236fd >> 0xffffffff80a237be <+830>: mov $0xffffffff80fd8ad3,%rsi >> 0xffffffff80a237c5 <+837>: xor %eax,%eax >> 0xffffffff80a237c7 <+839>: mov %r12,%rdi >> 0xffffffff80a237ca <+842>: mov -0x228(%rbp),%rdx >> 0xffffffff80a237d1 <+849>: callq 0xffffffff80a673e0 >> => 0xffffffff80a237d6 <+854>: inc %r14d >> 0xffffffff80a237d9 <+857>: jmpq 0xffffffff80a236fd > > So maybe try 'p $r12' in the corefile_open() frame. #17 0xffffffff80a237d6 in corefile_open (compress=0, comm=, uid=, pid=, td=, vpp=, namep=) at /usr/src/sys/kern/kern_sig.c:3188 3188 sbuf_printf(&sb, "%s", comm); (kgdb) p $r12 $1 = 0 From owner-freebsd-current@freebsd.org Tue Dec 8 07:57:05 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F287E9D3B10 for ; Tue, 8 Dec 2015 07:57:04 +0000 (UTC) (envelope-from 214748mv@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 C4A601AB0; Tue, 8 Dec 2015 07:57:04 +0000 (UTC) (envelope-from 214748mv@gmail.com) Received: by igvg19 with SMTP id g19so96446601igv.1; Mon, 07 Dec 2015 23:57:04 -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=0xOVny4SfRdS0Y/3gAuBVFGcrVi13A/1fWoMvOKXyrQ=; b=TvK+Zw7zY+mDOiRSJm9uk9u0vNUtnuDYd29XMMGVs+6X6VcewdXQUs7hVfbUTE+QjL BgZ1WLOC7jP+maZd7DLSRK/MDc3aCjpJcYyLwbIzblmQpcyWwHhu/HybwrVY7j+fosl4 UnzmOpODg2hzz8YHb5ngili+uLD0ZdAt6arriur5KXZDPBaOQy4bHk9TzUNK6T3FMMrF jM6+I7J9hgQJxP0+Nn/vYYiUMjErkKuZkLV9RbAtmRsecHKAtkXhN7XnrQr4s9NQy0BB rQ17+I6ajla1R5WmAs38VcOrgBCN/6fazy3ke+Iq/A+7EMEHb3B1titB5VzzN4pcmnb6 c0ig== MIME-Version: 1.0 X-Received: by 10.50.27.38 with SMTP id q6mr19421290igg.70.1449561424134; Mon, 07 Dec 2015 23:57:04 -0800 (PST) Received: by 10.79.111.199 with HTTP; Mon, 7 Dec 2015 23:57:04 -0800 (PST) In-Reply-To: References: <20151208031327.GA17554@thinkpad.swarthmore.edu> Date: Tue, 8 Dec 2015 08:57:04 +0100 Message-ID: Subject: Re: [PATCH] XOR uses From: "Ranjan1018 ." <214748mv@gmail.com> To: araujo@freebsd.org Cc: Michael McConville , freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 07:57:05 -0000 2015-12-08 5:40 GMT+01:00 Marcelo Araujo : > Hi Michael, > > What would be the advantage of it? > I still prefer explicit than implicit. The current code is much more > readable. > > Best, > > 2015-12-08 11:13 GMT+08:00 Michael McConville : > > > A minor simplification patch: > > > > > > Index: sys/arm/allwinner/a10_gpio.c > > =================================================================== > > --- sys/arm/allwinner/a10_gpio.c (revision 291978) > > +++ sys/arm/allwinner/a10_gpio.c (working copy) > > @@ -356,10 +356,7 @@ > > sc = device_get_softc(dev); > > A10_GPIO_LOCK(sc); > > data = A10_GPIO_READ(sc, A10_GPIO_GP_DAT(bank)); > > - if (data & (1 << pin)) > > - data &= ~(1 << pin); > > - else > > - data |= (1 << pin); > > + data ^= (1 << pin); > > A10_GPIO_WRITE(sc, A10_GPIO_GP_DAT(bank), data); > > A10_GPIO_UNLOCK(sc); > > > > Index: sys/arm/altera/socfpga/socfpga_gpio.c > > =================================================================== > > --- sys/arm/altera/socfpga/socfpga_gpio.c (revision 291978) > > +++ sys/arm/altera/socfpga/socfpga_gpio.c (working copy) > > @@ -336,10 +336,7 @@ > > > > GPIO_LOCK(sc); > > reg = READ4(sc, GPIO_SWPORTA_DR); > > - if (reg & (1 << i)) > > - reg &= ~(1 << i); > > - else > > - reg |= (1 << i); > > + reg ^= (1 << i); > > WRITE4(sc, GPIO_SWPORTA_DR, reg); > > GPIO_UNLOCK(sc); > > > > Index: sys/arm/rockchip/rk30xx_gpio.c > > =================================================================== > > --- sys/arm/rockchip/rk30xx_gpio.c (revision 291978) > > +++ sys/arm/rockchip/rk30xx_gpio.c (working copy) > > @@ -375,10 +375,7 @@ > > return (EINVAL); > > RK30_GPIO_LOCK(sc); > > data = RK30_GPIO_READ(sc, RK30_GPIO_SWPORT_DR); > > - if (data & (1U << pin)) > > - data &= ~(1U << pin); > > - else > > - data |= (1U << pin); > > + data ^= (1U << pin); > > RK30_GPIO_WRITE(sc, RK30_GPIO_SWPORT_DR, data); > > RK30_GPIO_UNLOCK(sc); > > > > Index: sys/arm/samsung/exynos/exynos5_pad.c > > =================================================================== > > --- sys/arm/samsung/exynos/exynos5_pad.c (revision 291978) > > +++ sys/arm/samsung/exynos/exynos5_pad.c (working copy) > > @@ -722,10 +722,7 @@ > > > > GPIO_LOCK(sc); > > reg = READ4(sc, bank.port, bank.con + 0x4); > > - if (reg & (1 << pin_shift)) > > - reg &= ~(1 << pin_shift); > > - else > > - reg |= (1 << pin_shift); > > + reg ^= (1 << pin_shift); > > WRITE4(sc, bank.port, bank.con + 0x4, reg); > > GPIO_UNLOCK(sc); > > > > Index: sys/dev/nand/nandsim_ctrl.c > > =================================================================== > > --- sys/dev/nand/nandsim_ctrl.c (revision 291978) > > +++ sys/dev/nand/nandsim_ctrl.c (working copy) > > @@ -388,9 +388,6 @@ > > rand = random(); > > if ((rand % 1000000) < chip->error_ratio) { > > bit = rand % 8; > > - if (*byte & (1 << bit)) > > - *byte &= ~(1 << bit); > > - else > > - *byte |= (1 << bit); > > + *byte ^= (1 << bit); > > } > > } > > > Hi, I prefer the syntax in the patch: - the semantic is more clear for me: if you want to flip a bit you should use xor - it saves, probably, some bytes of assembly code Regards Maurizio From owner-freebsd-current@freebsd.org Tue Dec 8 09:35:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8B0F9D4E18 for ; Tue, 8 Dec 2015 09:35:33 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 808581D7E for ; Tue, 8 Dec 2015 09:35:33 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by wmww144 with SMTP id w144so21934732wmw.0 for ; Tue, 08 Dec 2015 01:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=uWVUNsO9fQOhywnJRteV1Fp3z0rXOKPNynYP70LqNtA=; b=DnugOvXbLv2+3nDiUIMvtFWn7gNg9mac1B+4qwCzCYbyPQdRHlTlqZnjr0smwMN4jm IUqiUb0yb82P700WiH5OTaZU1e0Br0ZJCld/caWWKEUB9R+UHx2ZEVEv4aoTw7xk6Ttp 5QbLIDBJ/tDxsE3RKLsTa+h7q77HtzYYOotxzhaoSvU+EXqKshdPnYEv06l4JBFMub41 NwDb7Y4FVRsNpTb1hGuK2ARXnNYCDMm9+UA7rqfwUKPRPpnaptx4lzVot3jBMNFSwzxm T8s7HmED9m9/+cqFwAufjY/uaZM9lirko6sqsGDgTD7GazSNWNNZ/Lxd4zI1mbRjJW7E q9Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc:content-type; bh=uWVUNsO9fQOhywnJRteV1Fp3z0rXOKPNynYP70LqNtA=; b=A6tHVC63eIKThyYT8ieNrCawItiD7HUfzhEu6BXMqeZYisKxDZkTpAse60eYbHbRm1 eFrgCtw5ltNbjPGhjNK6WhJ1BMdOSWvH6nV1jxYWx1+xUKxC9eX++NTb6jD1+yaKTVxM phq+BEz73HbXDFjpmT5kfPCJVmG0JOKKtgBIOmUoCkh5b2kuQ6obBerQtEb74xeSQAMK pXxPUwfr/5VPb6yljN1eZ1u80Ce2nOtDNMV27oWipnsiMNczojPKNEnowt1V5Ys1oDFp ap+5zbzP8AYaIBetQN3vZWrKYyUtqiftX+EI/3diS7oOyoNSDs81RjroAnsZ+G/b9iMP BMFg== X-Gm-Message-State: ALoCoQlRIKVvZ6PGicbgR0duTpcGnFIEda9T/LTXRcdHVFEEBRSNUn6AF6za3EJXcjgHMBP37UBtkgkKKjCkExVIRrLzMT1mBo3M/6++nA0dQGHiIoVSefM= MIME-Version: 1.0 X-Received: by 10.194.172.2 with SMTP id ay2mr2557252wjc.137.1449567331781; Tue, 08 Dec 2015 01:35:31 -0800 (PST) Sender: sobomax@sippysoft.com Received: by 10.27.39.135 with HTTP; Tue, 8 Dec 2015 01:35:31 -0800 (PST) Date: Tue, 8 Dec 2015 01:35:31 -0800 X-Google-Sender-Auth: EqyANEPP8GE7pEsueXqy4Kn3ZZM Message-ID: Subject: posix_fallocate(2) && posix_fadvise(2) are somewhat broken From: Maxim Sobolev To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Cc: kib@freebsd.org, Kirk McKusick Content-Type: multipart/mixed; boundary=089e013c6214e43b4c05265fb14e X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 09:35:34 -0000 --089e013c6214e43b4c05265fb14e Content-Type: text/plain; charset=UTF-8 Hi, while working on some unrelated feature I've noticed that at least those two system calls are not returning proper value (-1) on error. Instead actual errno value is returned from the syscall verbatim, i.e. posix_fadvise() returns 22 on EINVAL. Attached patch fixes that problem, however I am not sure if I need to assign td->td_retval[0] at all, those two operations by design never return anything but -1 on error and 0 on success. Can someone comment on this? Thanks! --089e013c6214e43b4c05265fb14e Content-Type: text/plain; charset=US-ASCII; name="vfs_syscalls.diff" Content-Disposition: attachment; filename="vfs_syscalls.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ihx6qlod0 ZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3Zmc19zeXNjYWxscy5jIGIvc3lzL2tlcm4vdmZzX3N5c2Nh bGxzLmMKaW5kZXggZTY3NWIwOS4uYmRiMTYzOSAxMDA2NDQKLS0tIGEvc3lzL2tlcm4vdmZzX3N5 c2NhbGxzLmMKKysrIGIvc3lzL2tlcm4vdmZzX3N5c2NhbGxzLmMKQEAgLTQ1MjgsNyArNDUyOCw3 IEBAIHN5c19wb3NpeF9mYWxsb2NhdGUoc3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCBwb3NpeF9m YWxsb2NhdGVfYXJncyAqdWFwKQogCiAJdGQtPnRkX3JldHZhbFswXSA9IGtlcm5fcG9zaXhfZmFs bG9jYXRlKHRkLCB1YXAtPmZkLCB1YXAtPm9mZnNldCwKIAkgICAgdWFwLT5sZW4pOwotCXJldHVy biAoMCk7CisJcmV0dXJuICh0ZC0+dGRfcmV0dmFsWzBdKTsKIH0KIAogLyoKQEAgLTQ2NjUsNSAr NDY2NSw1IEBAIHN5c19wb3NpeF9mYWR2aXNlKHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3QgcG9z aXhfZmFkdmlzZV9hcmdzICp1YXApCiAKIAl0ZC0+dGRfcmV0dmFsWzBdID0ga2Vybl9wb3NpeF9m YWR2aXNlKHRkLCB1YXAtPmZkLCB1YXAtPm9mZnNldCwKIAkgICAgdWFwLT5sZW4sIHVhcC0+YWR2 aWNlKTsKLQlyZXR1cm4gKDApOworCXJldHVybiAodGQtPnRkX3JldHZhbFswXSk7CiB9Cg== --089e013c6214e43b4c05265fb14e-- From owner-freebsd-current@freebsd.org Tue Dec 8 04:50:34 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EECE9C118C for ; Tue, 8 Dec 2015 04:50:34 +0000 (UTC) (envelope-from mmcco@mykolab.com) Received: from mx-out02.mykolab.com (mx01.mykolab.com [95.128.36.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 395A7123A; Tue, 8 Dec 2015 04:50:33 +0000 (UTC) (envelope-from mmcco@mykolab.com) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-10 required=6.31 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, FREEMAIL_FROM=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102]) by mx-out02.mykolab.com (Postfix) with ESMTPS id F3EAE601B0; Tue, 8 Dec 2015 05:50:29 +0100 (CET) Date: Mon, 7 Dec 2015 23:50:25 -0500 From: Michael McConville To: araujo@FreeBSD.org Cc: freebsd-current Subject: Re: [PATCH] XOR uses Message-ID: <20151208045025.GA17698@thinkpad.swarthmore.edu> References: <20151208031327.GA17554@thinkpad.swarthmore.edu> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Tue, 08 Dec 2015 12:16:26 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 04:50:34 -0000 Marcelo Araujo wrote: > What would be the advantage of it? Just clarity and readability. > I still prefer explicit than implicit. The current code is much more > readable. I very much disagree. XOR is a basic binary operation, like AND and OR. I don't understand what's more explicit about using 4x the code to reimplement it every time. I don't feel strongly about the patches fate, though. > 2015-12-08 11:13 GMT+08:00 Michael McConville : > > > A minor simplification patch: > > > > > > Index: sys/arm/allwinner/a10_gpio.c > > =================================================================== > > --- sys/arm/allwinner/a10_gpio.c (revision 291978) > > +++ sys/arm/allwinner/a10_gpio.c (working copy) > > @@ -356,10 +356,7 @@ > > sc = device_get_softc(dev); > > A10_GPIO_LOCK(sc); > > data = A10_GPIO_READ(sc, A10_GPIO_GP_DAT(bank)); > > - if (data & (1 << pin)) > > - data &= ~(1 << pin); > > - else > > - data |= (1 << pin); > > + data ^= (1 << pin); > > A10_GPIO_WRITE(sc, A10_GPIO_GP_DAT(bank), data); > > A10_GPIO_UNLOCK(sc); > > > > Index: sys/arm/altera/socfpga/socfpga_gpio.c > > =================================================================== > > --- sys/arm/altera/socfpga/socfpga_gpio.c (revision 291978) > > +++ sys/arm/altera/socfpga/socfpga_gpio.c (working copy) > > @@ -336,10 +336,7 @@ > > > > GPIO_LOCK(sc); > > reg = READ4(sc, GPIO_SWPORTA_DR); > > - if (reg & (1 << i)) > > - reg &= ~(1 << i); > > - else > > - reg |= (1 << i); > > + reg ^= (1 << i); > > WRITE4(sc, GPIO_SWPORTA_DR, reg); > > GPIO_UNLOCK(sc); > > > > Index: sys/arm/rockchip/rk30xx_gpio.c > > =================================================================== > > --- sys/arm/rockchip/rk30xx_gpio.c (revision 291978) > > +++ sys/arm/rockchip/rk30xx_gpio.c (working copy) > > @@ -375,10 +375,7 @@ > > return (EINVAL); > > RK30_GPIO_LOCK(sc); > > data = RK30_GPIO_READ(sc, RK30_GPIO_SWPORT_DR); > > - if (data & (1U << pin)) > > - data &= ~(1U << pin); > > - else > > - data |= (1U << pin); > > + data ^= (1U << pin); > > RK30_GPIO_WRITE(sc, RK30_GPIO_SWPORT_DR, data); > > RK30_GPIO_UNLOCK(sc); > > > > Index: sys/arm/samsung/exynos/exynos5_pad.c > > =================================================================== > > --- sys/arm/samsung/exynos/exynos5_pad.c (revision 291978) > > +++ sys/arm/samsung/exynos/exynos5_pad.c (working copy) > > @@ -722,10 +722,7 @@ > > > > GPIO_LOCK(sc); > > reg = READ4(sc, bank.port, bank.con + 0x4); > > - if (reg & (1 << pin_shift)) > > - reg &= ~(1 << pin_shift); > > - else > > - reg |= (1 << pin_shift); > > + reg ^= (1 << pin_shift); > > WRITE4(sc, bank.port, bank.con + 0x4, reg); > > GPIO_UNLOCK(sc); > > > > Index: sys/dev/nand/nandsim_ctrl.c > > =================================================================== > > --- sys/dev/nand/nandsim_ctrl.c (revision 291978) > > +++ sys/dev/nand/nandsim_ctrl.c (working copy) > > @@ -388,9 +388,6 @@ > > rand = random(); > > if ((rand % 1000000) < chip->error_ratio) { > > bit = rand % 8; > > - if (*byte & (1 << bit)) > > - *byte &= ~(1 << bit); > > - else > > - *byte |= (1 << bit); > > + *byte ^= (1 << bit); > > } > > } From owner-freebsd-current@freebsd.org Tue Dec 8 09:02:38 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14E159D3590 for ; Tue, 8 Dec 2015 09:02:38 +0000 (UTC) (envelope-from ray@woopwoop.com) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 E45591B08 for ; Tue, 8 Dec 2015 09:02:34 +0000 (UTC) (envelope-from ray@woopwoop.com) Received: by pfnn128 with SMTP id n128so9142593pfn.0 for ; Tue, 08 Dec 2015 01:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=woopwoop-com.20150623.gappssmtp.com; s=20150623; h=from:content-type:subject:date:message-id:to:mime-version; bh=3mernD//TMkpqEy2zPFPRMFskdPDTPp2euZIVbVKy9Y=; b=NwhN29dJAqQKpOjHjtoOzY10pxNni99tl9QJBc4jYmCM76zAm6pEBkxBGYHcU4tYDi 7lSppqNI3Lp5i7XR5ca0Q+VD7+KBW94AeHsXd3lgk5L16lZpW3Oy061UFC6g6WYon3zl XYPXjWa+R52pBMIbY2U68oiLyt5r3MYoJxvBQlHvjedHNXpFwS1atyC7wkOBP3iUhuWj WSADTVzV14UxVfJkyxQCfq1izY3kRZV4OJklVFj2Cubmw2PDnLxIYsQ2A4ZgfgeZwNNM Dp7GaKPAkIa6+LXTwViKUKCrTNuuqJ2+CJs39u2udf7ODCCW3Y0vJwBgZ6RzqxWSgdHB jc0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:to :mime-version; bh=3mernD//TMkpqEy2zPFPRMFskdPDTPp2euZIVbVKy9Y=; b=LRagOOpMuOqmy+y6tAAauBgiQTcDv07C8TeoliEfX6eRV6NLLym/9/I2fxckEGduKz lZU7rUuY5VaLBPNpfn+T5l/fr3X0wmg3VxMv3Esg18zvZNVm+n7Om7bIQoOYZeSNXezA fx84mEt93tOPAXC3nFRHOANaq9EEIExoK0NvfNpKuTQW7/2HyDocSJ8szoae5zWhqayT T5mPVGYhWh71zKpyIJTZmJ5IwL79WGq+DR+SwJZ2mstWK/JYZhtUoHSzUA4v+uA0pr+X vL3/T/JmYQsoSgPBQWR8NjbleTATZUlqUnnhCITwkrCv05gqVAx1uIq8nfz0wexDLeGF k3EQ== X-Gm-Message-State: ALoCoQkzMGurizyFxQ8tOPfxc3Hyy23aOq/4VjPQ0m7qKEZ2C1FRBGsZFwlT2gC8Q3JIXCyfM8p5tRPqHwe6cbQmDmEF8nkREw== X-Received: by 10.98.68.8 with SMTP id r8mr2822006pfa.159.1449565354167; Tue, 08 Dec 2015 01:02:34 -0800 (PST) Received: from [10.0.10.26] ([220.240.231.173]) by smtp.gmail.com with ESMTPSA id h28sm3134596pfd.70.2015.12.08.01.02.31 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Dec 2015 01:02:33 -0800 (PST) From: Ray Newman X-Pgp-Agent: GPGMail 2.5.1 Content-Type: multipart/signed; boundary="Apple-Mail=_43150F39-17E1-460B-BFDB-DECAA397B788"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Dwarf problem with gcc and gdb Date: Tue, 8 Dec 2015 19:02:26 +1000 Message-Id: To: FreeBSD-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Tue, 08 Dec 2015 12:22:04 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 09:02:38 -0000 --Apple-Mail=_43150F39-17E1-460B-BFDB-DECAA397B788 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Compiled using gcc (FreeBSD Ports Collection) 4.8.5 on arm (Raspberry Pi = - several versions); BSDmakefile attached (make test used). gdb gives: 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 "armv6-marcel-freebsd"...Dwarf Error: wrong = version in compilation unit header (is 4, should be 2) [in module = /home/ray/mumps/mumps] I need to fix this to find the *real* problem. Thanks, Ray # Makefile for MUMPS BSD # Copyright (c) Raymond Douglas Newman, 1999 - 2014 # with help from Sam Habiel CC =3D gcc LIBS =3D -lm -lcrypt EXTRA =3D -O -Wall -Iinclude .ifmake test EXTRA =3D -O0 -g -gdwarf-2 -gstrict-dwarf -ggdb -Wall -Iinclude .endif SUBDIRS=3Dcompile database init runtime seqio symbol util xcall RM=3Drm -f PROG =3D mumps OBJS =3D compile/dollar.o \ compile/eval.o \ compile/localvar.o \ compile/parse.o \ compile/routine.o \ database/db_buffer.o \ database/db_daemon.o \ database/db_get.o \ database/db_ic.o \ database/db_kill.o \ database/db_locate.o \ database/db_main.o \ database/db_rekey.o \ database/db_set.o \ database/db_uci.o \ database/db_util.o \ database/db_view.o \ init/init_create.o \ init/init_run.o \ init/init_start.o \ init/mumps.o \ runtime/runtime_attn.o \ runtime/runtime_buildmvar.o \ runtime/runtime_debug.o \ runtime/runtime_func.o \ runtime/runtime_math.o \ runtime/runtime_pattern.o \ runtime/runtime_run.o \ runtime/runtime_ssvn.o \ runtime/runtime_util.o \ runtime/runtime_vars.o \ seqio/SQ_Util.o \ seqio/SQ_Signal.o \ seqio/SQ_Device.o \ seqio/SQ_File.o \ seqio/SQ_Pipe.o \ seqio/SQ_Seqio.o \ seqio/SQ_Socket.o \ seqio/SQ_Tcpip.o \ symbol/symbol_new.o \ symbol/symbol_util.o \ util/util_key.o \ util/util_lock.o \ util/util_memory.o \ util/util_routine.o \ util/util_share.o \ util/util_strerror.o \ xcall/xcall.o .c.o: ${CC} ${EXTRA} -c $< -o $@ all: ${OBJS} ${CC} ${EXTRA} -o ${PROG} ${OBJS} ${LIBS} test: ${OBJS} ${CC} ${EXTRA} -o ${PROG} ${OBJS} ${LIBS} clean: rm -f ${OBJS} ${PROG} ${PROG}.core --Apple-Mail=_43150F39-17E1-460B-BFDB-DECAA397B788 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 iQEcBAEBCgAGBQJWZpyiAAoJELNPlXuPO1O+eWsH/j5FZB7rvhOLOHnzKZtvi4Je wbjvld/BS/sg4IbIz0wkOaPeRBF4U60JaYMd6nU2LTN8GhkNyrqbpXqEtUsbzmI5 p8Fn8UE9ftS9beoSmJn4lkl/dbJTphVdVbXbGkpqiIrTkVXIuHTYcMbkIhZiYoXn Sj/U7CZTmgZ9xjGBXLkLEpGkIj+LxVlh7k2aEcZhNA/pwrtQUd8ly+1Ug5JBMXhh ZAOrDnKfgo01+yh44kkUfHDIjZJRWVGsEdYT04/sx1EFvzCVigi+/rU1oaDVFCem R3MTspAxJYWvDjN+VwIKXIj9PL1LXYgAmpXmETy7Jb06wcnu/TSyePDyG94g5sk= =Xsu1 -----END PGP SIGNATURE----- --Apple-Mail=_43150F39-17E1-460B-BFDB-DECAA397B788-- From owner-freebsd-current@freebsd.org Tue Dec 8 12:28:06 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED0AE9C1616 for ; Tue, 8 Dec 2015 12:28:06 +0000 (UTC) (envelope-from hps@selasky.org) 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 B68971D0F; Tue, 8 Dec 2015 12:28:06 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (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 14BCE1FE023; Tue, 8 Dec 2015 13:28:03 +0100 (CET) Subject: Re: [PATCH] XOR uses To: "Ranjan1018 ." <214748mv@gmail.com>, araujo@freebsd.org References: <20151208031327.GA17554@thinkpad.swarthmore.edu> Cc: Michael McConville , freebsd-current From: Hans Petter Selasky Message-ID: <5666CD40.8080700@selasky.org> Date: Tue, 8 Dec 2015 13:29:52 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 12:28:07 -0000 On 12/08/15 08:57, Ranjan1018 . wrote: > Hi, > > I prefer the syntax in the patch: > - the semantic is more clear for me: if you want to flip a bit you should > use xor > - it saves, probably, some bytes of assembly code > > Regards > Maurizio +1 And it is unconditional. --HPS From owner-freebsd-current@freebsd.org Tue Dec 8 12:31:24 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0A7F9C19B6 for ; Tue, 8 Dec 2015 12:31:24 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 85CA01F09 for ; Tue, 8 Dec 2015 12:31:20 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id tB8CVHXx068260 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2015 12:31:18 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Dwarf problem with gcc and gdb From: David Chisnall In-Reply-To: Date: Tue, 8 Dec 2015 12:31:11 +0000 Cc: FreeBSD-current@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <259B859F-93DD-4989-8E0C-2B7635966F0F@FreeBSD.org> References: To: Ray Newman X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 12:31:24 -0000 The gdb in the base system doesn=E2=80=99t support DWARF4. Use gdb791 = or lldb-devel from ports (I believe gdb791 is probably a better bet on = ARM, currently). David > On 8 Dec 2015, at 09:02, Ray Newman wrote: >=20 > Hi, >=20 > Compiled using gcc (FreeBSD Ports Collection) 4.8.5 on arm (Raspberry = Pi - several versions); BSDmakefile attached (make test used). > gdb gives: > 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 "armv6-marcel-freebsd"...Dwarf Error: wrong = version in compilation unit header (is 4, should be 2) [in module = /home/ray/mumps/mumps] >=20 > I need to fix this to find the *real* problem. >=20 > Thanks, Ray >=20 >=20 > # Makefile for MUMPS BSD > # Copyright (c) Raymond Douglas Newman, 1999 - 2014 > # with help from Sam Habiel >=20 > CC =3D gcc > LIBS =3D -lm -lcrypt > EXTRA =3D -O -Wall -Iinclude >=20 > .ifmake test > EXTRA =3D -O0 -g -gdwarf-2 -gstrict-dwarf -ggdb -Wall -Iinclude > .endif >=20 > SUBDIRS=3Dcompile database init runtime seqio symbol util xcall >=20 > RM=3Drm -f >=20 > PROG =3D mumps >=20 > OBJS =3D compile/dollar.o \ > compile/eval.o \ > compile/localvar.o \ > compile/parse.o \ > compile/routine.o \ > database/db_buffer.o \ > database/db_daemon.o \ > database/db_get.o \ > database/db_ic.o \ > database/db_kill.o \ > database/db_locate.o \ > database/db_main.o \ > database/db_rekey.o \ > database/db_set.o \ > database/db_uci.o \ > database/db_util.o \ > database/db_view.o \ > init/init_create.o \ > init/init_run.o \ > init/init_start.o \ > init/mumps.o \ > runtime/runtime_attn.o \ > runtime/runtime_buildmvar.o \ > runtime/runtime_debug.o \ > runtime/runtime_func.o \ > runtime/runtime_math.o \ > runtime/runtime_pattern.o \ > runtime/runtime_run.o \ > runtime/runtime_ssvn.o \ > runtime/runtime_util.o \ > runtime/runtime_vars.o \ > seqio/SQ_Util.o \ > seqio/SQ_Signal.o \ > seqio/SQ_Device.o \ > seqio/SQ_File.o \ > seqio/SQ_Pipe.o \ > seqio/SQ_Seqio.o \ > seqio/SQ_Socket.o \ > seqio/SQ_Tcpip.o \ > symbol/symbol_new.o \ > symbol/symbol_util.o \ > util/util_key.o \ > util/util_lock.o \ > util/util_memory.o \ > util/util_routine.o \ > util/util_share.o \ > util/util_strerror.o \ > xcall/xcall.o >=20 > .c.o: > ${CC} ${EXTRA} -c $< -o $@ >=20 > all: ${OBJS} > ${CC} ${EXTRA} -o ${PROG} ${OBJS} ${LIBS} >=20 > test: ${OBJS} > ${CC} ${EXTRA} -o ${PROG} ${OBJS} ${LIBS} >=20 > clean: > rm -f ${OBJS} ${PROG} ${PROG}.core >=20 From owner-freebsd-current@freebsd.org Tue Dec 8 15:28:04 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C04C9D39E9 for ; Tue, 8 Dec 2015 15:28:04 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 4F4F21AB8 for ; Tue, 8 Dec 2015 15:28:04 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by igcmv3 with SMTP id mv3so103443607igc.0 for ; Tue, 08 Dec 2015 07:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=TgbdYiae4nGZr+Mr/8KR2+7Hy/aW5YEAYBVmdw2p68w=; b=Eq2IvZsByL9c/Cw0TbAJDXBSK5zpNMCWNnZbSzUTRVIOJfU1bpLp9b4MIaNuBefHdu 9L88yEdJ3mUK1s0Hp6UdSZziPZyDJkVek7f7EItAkdCeJdFTD6UdKU+aUp9T11/y/9/I gMeUs5l4tvU1fr/mOhpCMgFAw5hlNme5wjQ0K24N91ZDGPOv6a5bF+dp+FjRHnD2z7/f TaqDKKYUxNxg1jfdv6Tjdcx2JgSlZQTO+c5y2fvD3JyQf0Ut4Y0QPGsU+KJ9hcl263x6 AHmlugHE9vlzjdtakY6oXI7vfdb3zbyHnYYxAfMwyghZDSMqLowAZs4YkFx262PB5W8l BXdg== X-Received: by 10.50.43.234 with SMTP id z10mr4683919igl.58.1449588483619; Tue, 08 Dec 2015 07:28:03 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.169.85 with HTTP; Tue, 8 Dec 2015 07:27:44 -0800 (PST) From: Ed Maste Date: Tue, 8 Dec 2015 10:27:44 -0500 X-Google-Sender-Auth: _IMVofmuiaY9TKnSgl1l-DDb8UI Message-ID: Subject: HEADS-UP: Userland debug files enabled by default To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 15:28:04 -0000 As of r291955 userland debug files are built and installed by default, in order to facilitate debugging. They will be built as part of the release process (in FreeBSD 11) so that they can be made available for download either at install time, or later on to debug a core file after a crash. (Release builds currently require the use of all default options.) The debug files will be located automatically by gdb or lldb, by following the ".gnu_debuglink" section in the binary or library. These files occupy additional disk space in the build object directory (e.g. /usr/obj) and in the install target filesystem (in /usr/lib/debug/...). If you do not want to build and install the debug files for any reason, add the following to /etc/src.conf: WITHOUT_DEBUG_FILES=YES I hope to refine the option further to provide separate control over building debug files for binaries and for libraries/rltd. From owner-freebsd-current@freebsd.org Tue Dec 8 15:52:14 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14A029D4D98; Tue, 8 Dec 2015 15:52:14 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D31F21C5F; Tue, 8 Dec 2015 15:52:13 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 045CED20A; Tue, 8 Dec 2015 15:52:13 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 81C1D482CD; Tue, 8 Dec 2015 16:52:05 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Maxim Sobolev Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, Kirk McKusick , kib@freebsd.org Subject: Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken References: Date: Tue, 08 Dec 2015 16:52:05 +0100 In-Reply-To: (Maxim Sobolev's message of "Tue, 8 Dec 2015 01:35:31 -0800") Message-ID: <868u55rl96.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 15:52:14 -0000 Maxim Sobolev writes: > Hi, while working on some unrelated feature I've noticed that at least > those two system calls are not returning proper value (-1) on error. > Instead actual errno value is returned from the syscall verbatim, > i.e. posix_fadvise() returns 22 on EINVAL. That's how syscalls work. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@freebsd.org Tue Dec 8 16:09:34 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE23F9D3DB2 for ; Tue, 8 Dec 2015 16:09:34 +0000 (UTC) (envelope-from 214748mv@gmail.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 8F0281235 for ; Tue, 8 Dec 2015 16:09:34 +0000 (UTC) (envelope-from 214748mv@gmail.com) Received: by iofh3 with SMTP id h3so28911679iof.3 for ; Tue, 08 Dec 2015 08:09: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:date:message-id:subject:from:to :cc:content-type; bh=kxs47MfDyllvq0BBuwQt04mVJsr6ykbx1S8Yio2npjY=; b=0as44VphSEJWokmeBcs1MmNW97fyU70ZZguNy673oSdTFGKuXJK+nBab4jrpGn344L qQhIVdLvyOrPp4CL36NoJLbQqUUZUmYa2kukLj6bZ1sjktD0bSRHWmVZyb37gptv0vSZ W60dhxtYzqdOeisRIGI3HoLOqKTRv3MSVHSapNTUl9ORsRUzF0OXsEY82lbO/97qB49O y91bx8r1KR1qtC3rCmkbC5NWGBaC5bvIiT9Gy+8wRfUIA8FcHiWl6U8P/8G2RHv/8fo1 Ur7QlPX4PvaMaLOASQprN9WRvqhRu7+J0/zJPYJxV6pxZqIKXgCWSF7nUlX1mMq52Eu4 4yuQ== MIME-Version: 1.0 X-Received: by 10.107.46.137 with SMTP id u9mr664907iou.136.1449590973992; Tue, 08 Dec 2015 08:09:33 -0800 (PST) Received: by 10.79.111.199 with HTTP; Tue, 8 Dec 2015 08:09:33 -0800 (PST) In-Reply-To: <055E0877-533A-4378-A306-FDE511543243@gmail.com> References: <055E0877-533A-4378-A306-FDE511543243@gmail.com> Date: Tue, 8 Dec 2015 17:09:33 +0100 Message-ID: Subject: Re: Panic at shutdown From: "Ranjan1018 ." <214748mv@gmail.com> To: Garrett Cooper Cc: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 16:09:34 -0000 2015-11-29 0:10 GMT+01:00 Garrett Cooper : > > > On Nov 28, 2015, at 12:32, Ranjan1018 . <214748mv@gmail.com> wrote: > > > > Hi, > > > > sometimes I have the panic in the photo at shutdown: > > > > http://imgur.com/mXrgFLp > > > > Unfortunately this happens randomly. > > > > I am running: > > > > $ uname -a > > > > FreeBSD ativ 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r291160M: Sun Nov 22 > > 17:10:38 CET 2015 root@ativ:/usr/obj/usr/src/sys/GENERIC amd64 > > The panic is in the ZFS code. > > Have you run memtest on the machine recently? > Good suggestion I have run memtest successfully for few hours on my laptop. I have understood the panic cause: is an invalid offset. The original function in /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c is: boolean_t txg_list_member(txg_list_t *tl, void *p, uint64_t txg) { int t = txg & TXG_MASK; txg_node_t *tn = (txg_node_t *)((char *)p + tl->tl_offset); return (tn->tn_member[t] != 0); } I have modified the function to print an uncommon or invalid tl->tl_offset : boolean_t txg_list_member(txg_list_t *tl, void *p, uint64_t txg) { size_t ofs = tl->tl_offset; { static int cnt=0; if ( (cnt++ % 1000) == 0 || (ofs != 88 && ofs != 984) ) printf("**** %d) tl->tl_offset %zu\n", cnt, ofs); } txg_node_t *tn = (txg_node_t *)((char *)p + ofs); return (tn->tn_member[txg & TXG_MASK] != 0); } I have received the panic again with an invalid tl->tl_offset of 16045693110842147038. In /val/log/messages I have: Dec 8 10:32:42 ativ kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done Dec 8 10:32:42 ativ kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Dec 8 10:32:42 ativ kernel: Waiting (max 60 seconds) for system process `syncer' to stop... Dec 8 10:32:42 ativ kernel: Syncing disks, vnodes remaining...0 0 0 done Dec 8 10:32:42 ativ kernel: All buffers synced. Dec 8 10:32:42 ativ kernel: **** 9692) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: **** 9693) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: **** 9694) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: **** 9695) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: **** 9708) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: **** 9709) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: **** 9710) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: **** 9711) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: **** 9720) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: **** 9721) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: **** 9722) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: **** 9723) tl->tl_offset 384 Dec 8 10:32:42 ativ kernel: Uptime: 1h57m42s Dec 8 10:32:42 ativ kernel: **** 9736) tl->tl_offset 16045693110842147038 Dec 8 10:32:42 ativ kernel: Dec 8 10:32:42 ativ kernel: Dec 8 10:32:42 ativ kernel: Fatal trap 9: general protection fault while in kernel mode Dec 8 10:32:42 ativ kernel: cpuid = 2; apic id = 02 Dec 8 10:32:42 ativ kernel: instruction pointer = 0x20:0xffffffff8211b1cb Dec 8 10:32:42 ativ kernel: stack pointer = 0x28:0xfffffe0119525990 Dec 8 10:32:42 ativ kernel: frame pointer = 0x28:0xfffffe01195259c0 Dec 8 10:32:42 ativ kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Dec 8 10:32:42 ativ kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Dec 8 10:32:42 ativ kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Dec 8 10:32:42 ativ kernel: current process = 0 (dbu_evict) Probably the panic is caused by some memory already freed, the hex value of 16045693110842147038 is 0xdeadc0dedeadc0de. To solve the panic I need some tips form someone more expert than me in ZFS code. Thanks. -- Maurizio From owner-freebsd-current@freebsd.org Tue Dec 8 16:59:49 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2974F9D46B6 for ; Tue, 8 Dec 2015 16:59:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3E97E1F32; Tue, 8 Dec 2015 16:59:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA26780; Tue, 08 Dec 2015 18:59:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1a6Lc2-000BZm-Oc; Tue, 08 Dec 2015 18:59:38 +0200 Subject: Re: HEADS-UP: Userland debug files enabled by default To: Ed Maste , FreeBSD Current References: From: Andriy Gapon Message-ID: <56670C40.30207@FreeBSD.org> Date: Tue, 8 Dec 2015 18:58:40 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 16:59:49 -0000 On 08/12/2015 17:27, Ed Maste wrote: > As of r291955 userland debug files are built and installed by default, > in order to facilitate debugging. They will be built as part of the > release process (in FreeBSD 11) so that they can be made available for > download either at install time, or later on to debug a core file > after a crash. (Release builds currently require the use of all > default options.) > > The debug files will be located automatically by gdb or lldb, by > following the ".gnu_debuglink" section in the binary or library. > > These files occupy additional disk space in the build object directory > (e.g. /usr/obj) and in the install target filesystem (in > /usr/lib/debug/...). If you do not want to build and install the debug > files for any reason, add the following to /etc/src.conf: > WITHOUT_DEBUG_FILES=YES > > I hope to refine the option further to provide separate control over > building debug files for binaries and for libraries/rltd. Thank you very much! This is a good improvement. Now I only wish that we could do the same for packages (where possible) :-) -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue Dec 8 17:32:49 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47ACB9D438B; Tue, 8 Dec 2015 17:32:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 1F8E01EF6; Tue, 8 Dec 2015 17:32:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by pacej9 with SMTP id ej9so15179357pac.2; Tue, 08 Dec 2015 09:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=X6WPJ2asx03m+jFClRzP+If50bXb3F0d3Hd1JQRq9vU=; b=iuXsHLcs4jdqWRezpF+HE3kSNN41W17v8D4KMZXL60YkjeFQ3OIJQBUcW4uNWgbFlv bfYJjSSd0YW0m8YIR/XRGqXbBrS3pUvh0+pRvlB9JAiSFC2+kPoCQUTq2TeE2TBoUsva UFDnA1J9HeP87HLWj02Fw4BVHx35KuXJyj2Qn1PBrM269UE1wispepIa07K9azNSUkRG S7aTjAq8T2EiC2wU4tQG9g0q/pdBFhHkNBU3B7qjouKaNlxALuPRSmbFNKvr0s+uirxI 6+8/qfS2P0rlGmke6PaDTnZwuxtarN7zew5px3oW3uoQqZ98k51MTTIywPL0iZDedxIq 2gxw== X-Received: by 10.66.224.165 with SMTP id rd5mr1508464pac.73.1449595968727; Tue, 08 Dec 2015 09:32:48 -0800 (PST) Received: from raichu ([104.232.114.184]) by smtp.gmail.com with ESMTPSA id 71sm6037676pfj.28.2015.12.08.09.32.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Dec 2015 09:32:48 -0800 (PST) Sender: Mark Johnston Date: Tue, 8 Dec 2015 09:32:36 -0800 From: Mark Johnston To: Maxim Sobolev Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, Kirk McKusick , kib@freebsd.org Subject: Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken Message-ID: <20151208173236.GA11078@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 17:32:49 -0000 On Tue, Dec 08, 2015 at 01:35:31AM -0800, Maxim Sobolev wrote: > Hi, while working on some unrelated feature I've noticed that at least > those two system calls are not returning proper value (-1) on error. > Instead actual errno value is returned from the syscall verbatim, > i.e. posix_fadvise() returns 22 on EINVAL. Attached patch fixes that > problem, however I am not sure if I need to assign td->td_retval[0] at all, > those two operations by design never return anything but -1 on error and 0 > on success. Can someone comment on this? Thanks! This behaviour is documented and specified by POSIX. I'm not sure why these syscalls are inconsistent with everything else, but the current implementation is correct. From owner-freebsd-current@freebsd.org Tue Dec 8 17:37:24 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E4EC9D4879 for ; Tue, 8 Dec 2015 17:37:24 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 D9B6C159D for ; Tue, 8 Dec 2015 17:37:23 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by wmec201 with SMTP id c201so223152105wme.0 for ; Tue, 08 Dec 2015 09:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aT2Mjvn64OpVhHB9XBny4RRZsVe/z+J5b+ycf24+Buk=; b=eV8nhDoWsNIWz29v3wffotBrApvqpI69V/vMM03gNPWIDcF0INYw9M+nI7vKXyL5GU Ac3+H4oMpMT9uMTlOw/UIhl6mKCMPMw4M3dX1Q2kHPn7Ge1S9sUGEotc/XUWk6GSX57Y 39jnYv7PoBtqm63M8PWaSUuCl8z46lrkKhyNnkVT0PcDbSv7EL2LtC9CVDgZTyQCovle 0HJFqUIIm8dggx3gXGPXikmz3S+Qh3zzol3lKn+m1IlpIUHSZujLKuST+wQMOmQV7/RP OqhPKvSt4ZDkjtm70RrH+AYWt5QV+KalXnLXwQTLm2CuIkKhc4Kt7lARvfEh+y0sSUhk +95A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aT2Mjvn64OpVhHB9XBny4RRZsVe/z+J5b+ycf24+Buk=; b=ZMm5rI15KPNkeA7lfVFk+AA4dMxPYNBqSh9n674Tp3zWlzUl6xI477BCAhQYkTMgA0 deLYDLFbH+W0jogbDyKiJP8u1AUlgGWTMS3OsCm9CS3qIA2ocvFOyMuxsc5HKiPiHsxu 3mTVE34rfgWwPgROc2x67Byx6SaOPnnnixprBPVpTdPRTbjV8Ecb7vb4EZzrFqeDJ5yn ZH3zAL9JkbiAy2d0C/XkyFfMsnvdSOHNxby36nnavLe6pAIOWX+NNgKO/rWlaW0x9Auf dNPU45vSMV5UI6IOCVpyUlleJfRaKQE0YqWQS6lPW/Ya7cPEwkDJp1acT8OlfTSdDnec 8lFw== X-Gm-Message-State: ALoCoQkvyah40kPNayGbdnOh27zKSsoy+qZlcBcq+6JimBoxiqiwcQI6+MoVOHrhZAnlzAcKE0fcMV5ObrsD8GVLN/33wYcZSz6ATPey8jyUzud2b7r+74U= MIME-Version: 1.0 X-Received: by 10.194.185.42 with SMTP id ez10mr962196wjc.82.1449596241214; Tue, 08 Dec 2015 09:37:21 -0800 (PST) Sender: sobomax@sippysoft.com Received: by 10.27.39.135 with HTTP; Tue, 8 Dec 2015 09:37:21 -0800 (PST) In-Reply-To: <201512081701.tB8H1ivY009763@hergotha.csail.mit.edu> References: <201512081701.tB8H1ivY009763@hergotha.csail.mit.edu> Date: Tue, 8 Dec 2015 09:37:21 -0800 X-Google-Sender-Auth: vwKGwcdtcjd5E8BYRUabTjnjh00 Message-ID: Subject: Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken From: Maxim Sobolev To: Garrett Wollman Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 17:37:24 -0000 Then it's documentation bug or maybe some discrepancy between SUS and POSIX. $ man posix_fadvise RETURN VALUES The posix_fadvise() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. STANDARDS The posix_fadvise() interface conforms to IEEE Std 1003.1-2001 (``POSIX.1''). HISTORY The posix_fadvise() system call first appeared in FreeBSD 9.1. On Tue, Dec 8, 2015 at 9:01 AM, Garrett Wollman < wollman@hergotha.csail.mit.edu> wrote: > In article NFGCy_w@mail.gmail.com> > sobomax@freebsd.org writes: > > >Hi, while working on some unrelated feature I've noticed that at least > >those two system calls are not returning proper value (-1) on error. > >Instead actual errno value is returned from the syscall verbatim, > > That is what the specification requires. > > RETURN VALUE > Upon successful completion, posix_fadvise( ) shall return > zero; otherwise, an error number shall be returned to > indicate the error. > > (Quote from SUSv7 p. 1410, lines 46221-46223.) > > -GAWollman > > From owner-freebsd-current@freebsd.org Tue Dec 8 17:01:47 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA9CD9D485D for ; Tue, 8 Dec 2015 17:01:47 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (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 B3C711138; Tue, 8 Dec 2015 17:01:47 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id tB8H1jBZ009764; Tue, 8 Dec 2015 12:01:45 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id tB8H1ivY009763; Tue, 8 Dec 2015 12:01:44 -0500 (EST) (envelope-from wollman) Date: Tue, 8 Dec 2015 12:01:44 -0500 (EST) From: Garrett Wollman Message-Id: <201512081701.tB8H1ivY009763@hergotha.csail.mit.edu> To: sobomax@freebsd.org Subject: Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken References: Organization: none Cc: freebsd-current@freebsd.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Tue, 08 Dec 2015 12:01:45 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hergotha.csail.mit.edu X-Mailman-Approved-At: Tue, 08 Dec 2015 17:40:10 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 17:01:48 -0000 In article sobomax@freebsd.org writes: >Hi, while working on some unrelated feature I've noticed that at least >those two system calls are not returning proper value (-1) on error. >Instead actual errno value is returned from the syscall verbatim, That is what the specification requires. RETURN VALUE Upon successful completion, posix_fadvise( ) shall return zero; otherwise, an error number shall be returned to indicate the error. (Quote from SUSv7 p. 1410, lines 46221-46223.) -GAWollman From owner-freebsd-current@freebsd.org Tue Dec 8 17:43:11 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B66A9D4F09; Tue, 8 Dec 2015 17:43:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 15F431F31; Tue, 8 Dec 2015 17:43:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tB8Hgxo7057780 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Dec 2015 19:43:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tB8Hgxo7057780 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tB8Hgx5T057779; Tue, 8 Dec 2015 19:42:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Dec 2015 19:42:59 +0200 From: Konstantin Belousov To: Dag-Erling Sm??rgrav Cc: Maxim Sobolev , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, Kirk McKusick Subject: Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken Message-ID: <20151208174259.GA82577@kib.kiev.ua> References: <868u55rl96.fsf@desk.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <868u55rl96.fsf@desk.des.no> User-Agent: Mutt/1.5.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 17:43:11 -0000 On Tue, Dec 08, 2015 at 04:52:05PM +0100, Dag-Erling Sm??rgrav wrote: > Maxim Sobolev writes: > > Hi, while working on some unrelated feature I've noticed that at least > > those two system calls are not returning proper value (-1) on error. > > Instead actual errno value is returned from the syscall verbatim, > > i.e. posix_fadvise() returns 22 on EINVAL. > > That's how syscalls work. No, this is not how typical syscalls work, but is how the posix_fallocate() and posix_fadvise() are specified by Posix. The patch is wrong, see also r261080 and r288640. From owner-freebsd-current@freebsd.org Tue Dec 8 17:59:52 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B99F99D4DB1 for ; Tue, 8 Dec 2015 17:59:52 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 51CDF14B1 for ; Tue, 8 Dec 2015 17:59:52 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by wmuu63 with SMTP id u63so191074666wmu.0 for ; Tue, 08 Dec 2015 09:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QPLy10ZJP5pFmUQO/g2lwDAKV5nOfehBd2SRL0SqawY=; b=z59Nxo7RlQDBhIU69VZ4ls+e9OPJqHIDbG15uIu+Aj8Jk/biFMbMWADyzF1TnotrSi 68YkfDM//rPI4b/hucAKz4Ek1ttWKadd6qkWI/fGMkeV57RY8WW/mJbJBN4DSSvNeTCg nk+iqRIylsL8+Noy9gX/7B8CY3kbXLpHaUsXZKJ5cRRuZAC27bGU+LTua1BxuRKTrzYr mTHP0o03w5zsmRWMl2yrRrxIIp/3Hl3zXlulyClxf0ckDZBlJaQDkj/kx436d4t60tS6 Z9tWVqkYdoGuLcqPkTcDOc62WulD/aop4+LeSGPxeql1Aq1bqqK6Y1OPzEltmNYI6VD0 PEHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QPLy10ZJP5pFmUQO/g2lwDAKV5nOfehBd2SRL0SqawY=; b=V64g37gMBcb2nLhiu6ufYazXg7hebXCJFG+BVM4D3dJezm27lY9z9De+6xiKAFO7Ec Bthmp8U2vUEXX8kdRE4teopuCZLRGGceZVHyaTa5BvtHdsLpgX3i8rHzcmBfB24dGWI/ s58MljSWpHj39dJT2LVFLSPq/PrmYbVwea8bEGYhOr+W3/thDHfZviBaC3PK3N8+vWWB nUS6VGHYop69TIzvgVzf4h/cKCIuCDV2RzoXz3NUnds4kUIIgBoaX240eEzBJr9o7VtB 1evcnw3PaqM/fQzE0wN3fDRWz4HQbdqmQ110pYM7w87CpLGyzxbV2ppvUrLBpe5cFzCU ED/A== X-Gm-Message-State: ALoCoQncsG79DzVkKS0NKa6q1WFyN4En76Q/mrhj+N02a7GE4XE8+qsFTg8G2JSKyGHgZFoh6ORb+gDu3D+YuB6aFvM0LP/kjBrdUyPg5Ie512sBo9OF+eU= MIME-Version: 1.0 X-Received: by 10.194.185.42 with SMTP id ez10mr1089745wjc.82.1449597590817; Tue, 08 Dec 2015 09:59:50 -0800 (PST) Sender: sobomax@sippysoft.com Received: by 10.27.39.135 with HTTP; Tue, 8 Dec 2015 09:59:50 -0800 (PST) In-Reply-To: <20151208174259.GA82577@kib.kiev.ua> References: <868u55rl96.fsf@desk.des.no> <20151208174259.GA82577@kib.kiev.ua> Date: Tue, 8 Dec 2015 09:59:50 -0800 X-Google-Sender-Auth: bMK13KdHMtYrxp7Jo9MAO3VtXQU Message-ID: Subject: Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken From: Maxim Sobolev To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 17:59:52 -0000 Ah, ok, I see now. It's been broken and still broken in 9.x/10.x, already fixed in trunk and I been just reading wrong manpage. Thanks for the pointer, on a related note those fixes should probably be MFCed into 10.3 if it has not been already. On Tue, Dec 8, 2015 at 9:42 AM, Konstantin Belousov wrote: > On Tue, Dec 08, 2015 at 04:52:05PM +0100, Dag-Erling Sm??rgrav wrote: > > Maxim Sobolev writes: > > > Hi, while working on some unrelated feature I've noticed that at least > > > those two system calls are not returning proper value (-1) on error. > > > Instead actual errno value is returned from the syscall verbatim, > > > i.e. posix_fadvise() returns 22 on EINVAL. > > > > That's how syscalls work. > > No, this is not how typical syscalls work, but is how the posix_fallocate() > and posix_fadvise() are specified by Posix. The patch is wrong, see also > r261080 and r288640. > > From owner-freebsd-current@freebsd.org Tue Dec 8 18:20:46 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C7739D4230 for ; Tue, 8 Dec 2015 18:20:46 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 2DB321E2E; Tue, 8 Dec 2015 18:20:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1EE55B948; Tue, 8 Dec 2015 13:20:45 -0500 (EST) From: John Baldwin To: Don Lewis Cc: freebsd-current@freebsd.org Subject: Re: panic: sbuf_vprintf called with a NULL sbuf pointer Date: Tue, 08 Dec 2015 09:54:53 -0800 Message-ID: <2133429.08nAJynLee@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <201512080610.tB86Apx0000899@gw.catspoiler.org> References: <201512080610.tB86Apx0000899@gw.catspoiler.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 08 Dec 2015 13:20:45 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 18:20:46 -0000 On Monday, December 07, 2015 10:10:51 PM Don Lewis wrote: > On 2 Dec, John Baldwin wrote: > > On Wednesday, December 02, 2015 01:25:56 PM Don Lewis wrote: > >> > If you want to look at this further, try going to frame 16 and dissassembling the > >> > instructions before the call to see if you can spot which register the first > >> > parameter (saved in %rdi IIRC) comes from. > >> > >> Dump of assembler code for function sbuf_printf: > >> 0xffffffff80a673e0 <+0>: push %rbp > >> 0xffffffff80a673e1 <+1>: mov %rsp,%rbp > >> 0xffffffff80a673e4 <+4>: push %r14 > >> 0xffffffff80a673e6 <+6>: push %rbx > >> 0xffffffff80a673e7 <+7>: sub $0x50,%rsp > >> 0xffffffff80a673eb <+11>: mov %rsi,%r14 > >> 0xffffffff80a673ee <+14>: mov %rdi,%rbx > >> 0xffffffff80a673f1 <+17>: mov %r9,-0x38(%rbp) > >> 0xffffffff80a673f5 <+21>: mov %r8,-0x40(%rbp) > >> 0xffffffff80a673f9 <+25>: mov %rcx,-0x48(%rbp) > >> 0xffffffff80a673fd <+29>: mov %rdx,-0x50(%rbp) > >> 0xffffffff80a67401 <+33>: lea -0x60(%rbp),%rax > >> 0xffffffff80a67405 <+37>: mov %rax,-0x20(%rbp) > >> 0xffffffff80a67409 <+41>: lea 0x10(%rbp),%rax > >> 0xffffffff80a6740d <+45>: mov %rax,-0x28(%rbp) > >> 0xffffffff80a67411 <+49>: movl $0x30,-0x2c(%rbp) > >> 0xffffffff80a67418 <+56>: movl $0x10,-0x30(%rbp) > >> 0xffffffff80a6741f <+63>: mov $0xffffffff8137bdf8,%rdi > >> 0xffffffff80a67426 <+70>: mov %rbx,%rsi > >> 0xffffffff80a67429 <+73>: callq 0xffffffff80a66c00 <_assert_sbuf_integrity> > >> > >> > >> 0xffffffff80a237b9 <+825>: jmpq 0xffffffff80a236fd > >> 0xffffffff80a237be <+830>: mov $0xffffffff80fd8ad3,%rsi > >> 0xffffffff80a237c5 <+837>: xor %eax,%eax > >> 0xffffffff80a237c7 <+839>: mov %r12,%rdi > >> 0xffffffff80a237ca <+842>: mov -0x228(%rbp),%rdx > >> 0xffffffff80a237d1 <+849>: callq 0xffffffff80a673e0 > >> => 0xffffffff80a237d6 <+854>: inc %r14d > >> 0xffffffff80a237d9 <+857>: jmpq 0xffffffff80a236fd > > > > So maybe try 'p $r12' in the corefile_open() frame. > > #17 0xffffffff80a237d6 in corefile_open (compress=0, comm=, > uid=, pid=, td=, > vpp=, namep=) > at /usr/src/sys/kern/kern_sig.c:3188 > 3188 sbuf_printf(&sb, "%s", comm); > (kgdb) p $r12 > $1 = 0 So it's definitely zero. :( The next step is probably to disassemble the corefile_open function (ugh) and walk backwards to find where %r12 is read from. It might be from a local variable on the stack, so then you would want to examine that memory in the stack and the surrounding memory to see if there is memory corruption and perhaps if there is anything recognizable about it (e.g. if the corruption contains some sort of data you recognize, or if the corruption is bounded by a certain length, etc.). It's a bit of a shot in the dark though. Is this reproducible? -- John Baldwin From owner-freebsd-current@freebsd.org Tue Dec 8 18:51:10 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D3459D4F07 for ; Tue, 8 Dec 2015 18:51:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0501310D2 for ; Tue, 8 Dec 2015 18:51:09 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::740b:ca62:c452:aa67] (unknown [IPv6:2001:7b8:3a7:0:740b:ca62:c452:aa67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DBE8A627B; Tue, 8 Dec 2015 19:51:00 +0100 (CET) Subject: Re: Dwarf problem with gcc and gdb Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A2C8DDA7-F321-47FD-8B26-B5A44DE08417"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Dimitry Andric In-Reply-To: Date: Tue, 8 Dec 2015 19:50:49 +0100 Cc: FreeBSD-current@FreeBSD.org Message-Id: <52DCC05E-EC7B-42D2-B46C-EB3816CFA7A1@FreeBSD.org> References: To: Ray Newman X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 18:51:10 -0000 --Apple-Mail=_A2C8DDA7-F321-47FD-8B26-B5A44DE08417 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 08 Dec 2015, at 10:02, Ray Newman wrote: >=20 > Compiled using gcc (FreeBSD Ports Collection) 4.8.5 on arm (Raspberry = Pi - several versions); BSDmakefile attached (make test used). > gdb gives: > 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 "armv6-marcel-freebsd"...Dwarf Error: wrong = version in compilation unit header (is 4, should be 2) [in module = /home/ray/mumps/mumps] >=20 > I need to fix this to find the *real* problem. Since gcc 4.8.0, it defaults to -gdwarf-4. You must explicitly use -gdwarf-2, if you want to debug with the version of gdb in base. Alternatively, use the gdb port, or lldb. -Dimitry --Apple-Mail=_A2C8DDA7-F321-47FD-8B26-B5A44DE08417 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----- Version: GnuPG/MacGPG2 v2.0.28 iEYEARECAAYFAlZnJpQACgkQsF6jCi4glqNkqwCgnU/K33PrlP3GgYatPh0qDXPu MBQAmwbB6zhul4TlVf3cmF+V+5K01NpZ =Vjo1 -----END PGP SIGNATURE----- --Apple-Mail=_A2C8DDA7-F321-47FD-8B26-B5A44DE08417-- From owner-freebsd-current@freebsd.org Tue Dec 8 18:54:14 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58E8D9D3382; Tue, 8 Dec 2015 18:54:14 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 239881871; Tue, 8 Dec 2015 18:54:13 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 2CEE5D6FD; Tue, 8 Dec 2015 18:54:13 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id AA786482E5; Tue, 8 Dec 2015 19:54:06 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Konstantin Belousov Cc: Kirk McKusick , Maxim Sobolev , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken References: <868u55rl96.fsf@desk.des.no> <20151208174259.GA82577@kib.kiev.ua> Date: Tue, 08 Dec 2015 19:54:06 +0100 In-Reply-To: <20151208174259.GA82577@kib.kiev.ua> (Konstantin Belousov's message of "Tue, 8 Dec 2015 19:42:59 +0200") Message-ID: <86poygrctt.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 18:54:14 -0000 Konstantin Belousov writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Maxim Sobolev writes: > > > Hi, while working on some unrelated feature I've noticed that at least > > > those two system calls are not returning proper value (-1) on error. > > > Instead actual errno value is returned from the syscall verbatim, > > > i.e. posix_fadvise() returns 22 on EINVAL. > > That's how syscalls work. > No, this is not how typical syscalls work, but is how the posix_fallocate= () > and posix_fadvise() are specified by Posix. The patch is wrong, see also > r261080 and r288640. Umm, I can't find the code ATM but syscalls store the actual return value in td_retval and return 0 or EWHATEVER and the syscall wrapper handles the translation. If that's not what Maxim was talking about, then please ignore me. Anyway, happy to hear that the X/Open group have found a new way to screw people over. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@freebsd.org Tue Dec 8 19:13:35 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BBC89D45B0; Tue, 8 Dec 2015 19:13:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 9FA9A1C9C; Tue, 8 Dec 2015 19:13:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tB8JDORI045632 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Dec 2015 21:13:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tB8JDORI045632 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tB8JDOYr045631; Tue, 8 Dec 2015 21:13:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Dec 2015 21:13:24 +0200 From: Konstantin Belousov To: Dag-Erling Sm??rgrav Cc: Kirk McKusick , Maxim Sobolev , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken Message-ID: <20151208191324.GF82577@kib.kiev.ua> References: <868u55rl96.fsf@desk.des.no> <20151208174259.GA82577@kib.kiev.ua> <86poygrctt.fsf@desk.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86poygrctt.fsf@desk.des.no> User-Agent: Mutt/1.5.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 19:13:35 -0000 On Tue, Dec 08, 2015 at 07:54:06PM +0100, Dag-Erling Sm??rgrav wrote: > Konstantin Belousov writes: > > Dag-Erling Sm??rgrav writes: > > > Maxim Sobolev writes: > > > > Hi, while working on some unrelated feature I've noticed that at least > > > > those two system calls are not returning proper value (-1) on error. > > > > Instead actual errno value is returned from the syscall verbatim, > > > > i.e. posix_fadvise() returns 22 on EINVAL. > > > That's how syscalls work. > > No, this is not how typical syscalls work, but is how the posix_fallocate() > > and posix_fadvise() are specified by Posix. The patch is wrong, see also > > r261080 and r288640. > > Umm, I can't find the code ATM but syscalls store the actual return > value in td_retval and return 0 or EWHATEVER and the syscall wrapper > handles the translation. If that's not what Maxim was talking about, > then please ignore me. I mean that typical syscall does not return error to usermode, it returns -1 and sets errno. But usermode conventions for the posix_f*e() are different, and I believe this is what tripped over Maxim and I reacted upon. Indeed kernel expects the syscall function from the sysentvec table to return error or zero. If zero is returned, then td_retval array is translated into return value for usermode by cpu_set_syscall_retval(). If non-zero is returned, typical kernel/libc interface returns the syscall function return value to usermode and additionally set flag (like PSL_C in the processor status word). Of course, there is an additional translation layer in usermode syscall trampolines. > > Anyway, happy to hear that the X/Open group have found a new way to > screw people over. It is the same as the pthread_* conventions. They are somewhat consistent. From owner-freebsd-current@freebsd.org Tue Dec 8 19:23:47 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEBA59D509A for ; Tue, 8 Dec 2015 19:23:47 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 9FE961BE9; Tue, 8 Dec 2015 19:23:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E259AB97D; Tue, 8 Dec 2015 14:23:45 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: David Chisnall , Ray Newman , FreeBSD-current@freebsd.org Subject: Re: Dwarf problem with gcc and gdb Date: Tue, 08 Dec 2015 10:42:32 -0800 Message-ID: <3841499.UpalbfMfZ3@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <259B859F-93DD-4989-8E0C-2B7635966F0F@FreeBSD.org> References: <259B859F-93DD-4989-8E0C-2B7635966F0F@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 08 Dec 2015 14:23:46 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 19:23:47 -0000 On Tuesday, December 08, 2015 12:31:11 PM David Chisnall wrote: > The gdb in the base system doesn=E2=80=99t support DWARF4. Use gdb79= 1 or lldb-devel from ports (I believe gdb791 is probably a better bet o= n ARM, currently). gdb710 in ports does not support arm (yet). --=20 John Baldwin From owner-freebsd-current@freebsd.org Tue Dec 8 19:23:48 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B5569D509C for ; Tue, 8 Dec 2015 19:23:48 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 4BADD1BEB for ; Tue, 8 Dec 2015 19:23:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4BE8CB999; Tue, 8 Dec 2015 14:23:47 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Cc: Rick Macklem , Adrian Chadd , Alexander Kabaev Subject: Re: slow screen updates on laptop console (i386) Date: Tue, 08 Dec 2015 10:41:05 -0800 Message-ID: <1558819.MnyjzOdus5@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <387840531.122544462.1449529268528.JavaMail.zimbra@uoguelph.ca> References: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> <387840531.122544462.1449529268528.JavaMail.zimbra@uoguelph.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 08 Dec 2015 14:23:47 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 19:23:48 -0000 On Monday, December 07, 2015 06:01:08 PM Rick Macklem wrote: > Adrian Chadd wrote: > > Hi, > > > > ok. please file a bug for that. It may be something to do with the > > hardware and sleep states and skipping wakeups/interrupts or > > something. > > > > Please try using the default again (LAPIC?) and set > > kern.eventtimer.periodic=1. See if that fixes it. > > > Actually made it worse. Instead of being intermittently slow, it was > almost constantly slow. Try disabling C-states if they are enabled. If you have a BIOS option for C1E you might need to disable that as well. If this fixes it, then there isn't a really viable solution in software, and you might prefer to use the RTC to get the power savings from C-states. -- John Baldwin From owner-freebsd-current@freebsd.org Tue Dec 8 19:36:16 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D86C99D5ACA for ; Tue, 8 Dec 2015 19:36:16 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C5EDF1C1F for ; Tue, 8 Dec 2015 19:36:16 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: by mailman.ysv.freebsd.org (Postfix) id C54539D5AC9; Tue, 8 Dec 2015 19:36:16 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4E049D5AC8 for ; Tue, 8 Dec 2015 19:36:16 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::4]) (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 B55FB1C1E for ; Tue, 8 Dec 2015 19:36:16 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (localhost [127.0.0.1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPS id 06EDE125EE1 for ; Tue, 8 Dec 2015 11:36:10 -0800 (PST) Received: from pop.rubicorp.com (unknown [72.34.113.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPSA id DC293125EBA for ; Tue, 8 Dec 2015 11:36:09 -0800 (PST) To: current@freebsd.org From: Pete Wright Subject: LOR On AMD64 hosted by KVM hypervisor X-Enigmail-Draft-Status: N1110 Message-ID: <56673129.4090207@nomadlogic.org> Date: Tue, 8 Dec 2015 11:36:09 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 19:36:16 -0000 Hey All, I am seeing a repeated LOR on r291495 that is pretty reproducible. This happens right after the system boots: lock order reversal: 1st 0xfffffe03e37fa920 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3476 2nd 0xfffff80024c72200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 stack backtrace: #0 0xffffffff80a7b2e0 at witness_debugger+0x70 #1 0xffffffff80a7b1e1 at witness_checkorder+0xe71 #2 0xffffffff80a28ab2 at _sx_xlock+0x72 #3 0xffffffff80cc0a5d at ufsdirhash_add+0x3d #4 0xffffffff80cc390f at ufs_direnter+0x62f #5 0xffffffff80ccccd3 at ufs_makeinode+0x5f3 #6 0xffffffff80cc881d at ufs_create+0x2d #7 0xffffffff80fb2ed1 at VOP_CREATE_APV+0xf1 #8 0xffffffff80ae3568 at vn_open_cred+0x2f8 #9 0xffffffff80adc8ec at kern_openat+0x25c #10 0xffffffff80e6a4fe at amd64_syscall+0x2de #11 0xffffffff80e4972b at Xfast_syscall+0xfb Here is the system info: % uname -ar FreeBSD bsd-current.trp-srd.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r291495: Mon Nov 30 23:14:34 UTC 2015 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 The server itself is a VM running under the KVM hypervisor. I am currently rebuilding world+kernel now. The base OS image is from the latest 11-CURRENT snapshot, and I have been able to reproduce this on several hypervisors. Has anyone else seen this? Cheers, -pete -- Pete Wright pete@nomadlogic.org twitter => @nomadlogicLA From owner-freebsd-current@freebsd.org Tue Dec 8 19:40:05 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BE619D5CF6 for ; Tue, 8 Dec 2015 19:40:05 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DC5141DC9; Tue, 8 Dec 2015 19:40:04 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id tB8JduPg003988; Tue, 8 Dec 2015 11:40:00 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201512081940.tB8JduPg003988@gw.catspoiler.org> Date: Tue, 8 Dec 2015 11:39:56 -0800 (PST) From: Don Lewis Subject: Re: panic: sbuf_vprintf called with a NULL sbuf pointer To: jhb@freebsd.org cc: freebsd-current@freebsd.org In-Reply-To: <2133429.08nAJynLee@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 19:40:05 -0000 On 8 Dec, John Baldwin wrote: > On Monday, December 07, 2015 10:10:51 PM Don Lewis wrote: >> On 2 Dec, John Baldwin wrote: >> > On Wednesday, December 02, 2015 01:25:56 PM Don Lewis wrote: >> >> > If you want to look at this further, try going to frame 16 and dissassembling the >> >> > instructions before the call to see if you can spot which register the first >> >> > parameter (saved in %rdi IIRC) comes from. >> >> >> >> Dump of assembler code for function sbuf_printf: >> >> 0xffffffff80a673e0 <+0>: push %rbp >> >> 0xffffffff80a673e1 <+1>: mov %rsp,%rbp >> >> 0xffffffff80a673e4 <+4>: push %r14 >> >> 0xffffffff80a673e6 <+6>: push %rbx >> >> 0xffffffff80a673e7 <+7>: sub $0x50,%rsp >> >> 0xffffffff80a673eb <+11>: mov %rsi,%r14 >> >> 0xffffffff80a673ee <+14>: mov %rdi,%rbx >> >> 0xffffffff80a673f1 <+17>: mov %r9,-0x38(%rbp) >> >> 0xffffffff80a673f5 <+21>: mov %r8,-0x40(%rbp) >> >> 0xffffffff80a673f9 <+25>: mov %rcx,-0x48(%rbp) >> >> 0xffffffff80a673fd <+29>: mov %rdx,-0x50(%rbp) >> >> 0xffffffff80a67401 <+33>: lea -0x60(%rbp),%rax >> >> 0xffffffff80a67405 <+37>: mov %rax,-0x20(%rbp) >> >> 0xffffffff80a67409 <+41>: lea 0x10(%rbp),%rax >> >> 0xffffffff80a6740d <+45>: mov %rax,-0x28(%rbp) >> >> 0xffffffff80a67411 <+49>: movl $0x30,-0x2c(%rbp) >> >> 0xffffffff80a67418 <+56>: movl $0x10,-0x30(%rbp) >> >> 0xffffffff80a6741f <+63>: mov $0xffffffff8137bdf8,%rdi >> >> 0xffffffff80a67426 <+70>: mov %rbx,%rsi >> >> 0xffffffff80a67429 <+73>: callq 0xffffffff80a66c00 <_assert_sbuf_integrity> >> >> >> >> >> >> 0xffffffff80a237b9 <+825>: jmpq 0xffffffff80a236fd >> >> 0xffffffff80a237be <+830>: mov $0xffffffff80fd8ad3,%rsi >> >> 0xffffffff80a237c5 <+837>: xor %eax,%eax >> >> 0xffffffff80a237c7 <+839>: mov %r12,%rdi >> >> 0xffffffff80a237ca <+842>: mov -0x228(%rbp),%rdx >> >> 0xffffffff80a237d1 <+849>: callq 0xffffffff80a673e0 >> >> => 0xffffffff80a237d6 <+854>: inc %r14d >> >> 0xffffffff80a237d9 <+857>: jmpq 0xffffffff80a236fd >> > >> > So maybe try 'p $r12' in the corefile_open() frame. >> >> #17 0xffffffff80a237d6 in corefile_open (compress=0, comm=, >> uid=, pid=, td=, >> vpp=, namep=) >> at /usr/src/sys/kern/kern_sig.c:3188 >> 3188 sbuf_printf(&sb, "%s", comm); >> (kgdb) p $r12 >> $1 = 0 > > So it's definitely zero. :( The next step is probably to disassemble the > corefile_open function (ugh) and walk backwards to find where %r12 is read > from. It might be from a local variable on the stack, so then you would > want to examine that memory in the stack and the surrounding memory to see > if there is memory corruption and perhaps if there is anything recognizable > about it (e.g. if the corruption contains some sort of data you recognize, > or if the corruption is bounded by a certain length, etc.). It's a bit of > a shot in the dark though. > > Is this reproducible? No it's not. The only time it happened was when there was a swap timeout, probably because of a lengthy deep recovery on one of the mirrored swap devices. The code in question is: struct sbuf sb; [snip] (void)sbuf_new(&sb, name, MAXPATHLEN, SBUF_FIXEDLEN); [snip] for (i = 0; format[i] != '\0'; i++) { switch (format[i]) { case '%': /* Format character */ i++; switch (format[i]) { [snip] case 'N': /* process name */ sbuf_printf(&sb, "%s", comm); break; &sb is used in a bunch of places, so the compiler probably computes its value once by adding the proper offset to the stack pointer and stashing the result in a register. Since kern.corefile is "%N.core", the failure is happening on the first interation of the loop, so there isn't much opportunity for things to get corrupted. Also, the control flow in this function only depends on the format, so there shouldn't be anything special about a swap timeout vs. a segfault generated core. How is gdb able to print the register contents for an arbitrary stack frame? It's not like this is a SPARC with register windows. Aren't only the final register values when the core dump was generated saved along with the memory contents? Unless a register contents are pushed onto the stack, I would think that if a callee overwrites a register, its contents are gone. From owner-freebsd-current@freebsd.org Tue Dec 8 20:08:27 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E5009D3517 for ; Tue, 8 Dec 2015 20:08:27 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 04E14198E; Tue, 8 Dec 2015 20:08:26 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from [208.184.220.60] (helo=macbook-air-3.dolby.net) by id.bluezbox.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1a6OYc-0008eG-O1; Tue, 08 Dec 2015 12:08:19 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Dwarf problem with gcc and gdb From: Oleksandr Tymoshenko In-Reply-To: <3841499.UpalbfMfZ3@ralph.baldwin.cx> Date: Tue, 8 Dec 2015 12:07:49 -0800 Cc: freebsd-current@freebsd.org, David Chisnall , Ray Newman Content-Transfer-Encoding: quoted-printable Message-Id: References: <259B859F-93DD-4989-8E0C-2B7635966F0F@FreeBSD.org> <3841499.UpalbfMfZ3@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3096.5) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: > On Dec 8, 2015, at 10:42 AM, John Baldwin wrote: > > On Tuesday, December 08, 2015 12:31:11 PM David Chisnall wrote: >> The gdb in the base system doesn’t support DWARF4. Use gdb791 or lldb-devel from ports (I believe gdb791 is probably a better bet on ARM, currently). > > gdb710 in ports does not support arm (yet). [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 20:08:27 -0000 > On Dec 8, 2015, at 10:42 AM, John Baldwin wrote: >=20 > On Tuesday, December 08, 2015 12:31:11 PM David Chisnall wrote: >> The gdb in the base system doesn=E2=80=99t support DWARF4. Use = gdb791 or lldb-devel from ports (I believe gdb791 is probably a better = bet on ARM, currently). >=20 > gdb710 in ports does not support arm (yet). I have half-baked solution for gdb7/arm: https://people.freebsd.org/~gonzo/arm/gdb7-arm.diff And cognet@ worked on cross-debugging part, not sure how far he got.=20= From owner-freebsd-current@freebsd.org Tue Dec 8 20:52:17 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E0C99D587F for ; Tue, 8 Dec 2015 20:52:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id A9ADF1031; Tue, 8 Dec 2015 20:52:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:vWl8PRfao40pWrAI0c8MaVEAlGMj4u6mDksu8pMizoh2WeGdxc68YR7h7PlgxGXEQZ/co6odzbGG7ea4ASQp2tWojjMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3DwdpPOO9QteU1JTpkbjqs7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjN92Mq+lx7DS0Ol738QTWQQ2k5KAwLt4gv3U53qvm39rOUriweAOsijd7E/WnyH5qxoTBLtwHMdMjcy82Xaj+Rti61GrRa5p1p0ytiHM8muKPNic/aFLpshTm1bU5MUDnQZDw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DTAQCGQmdW/61jaINehQG9OQENgW6CXl6CUgKBdxQBAQEBAQEBAYEJgi2CCAEBBCNWEAIBCA4KAgINGQICVwIELogUrk6QZQEBAQEBAQEBAQEBAQEBAQEBARuBAYVThH2EPoM5gUQFjh+IQo8XhEOWTQIfAQFChCIghRyBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,400,1444708800"; d="scan'208";a="254954971" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 08 Dec 2015 15:52:09 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id BA7F415F571; Tue, 8 Dec 2015 15:52:09 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id TTZZ_nBhrCEc; Tue, 8 Dec 2015 15:52:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 6A3DF15F574; Tue, 8 Dec 2015 15:52:09 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m2xZpKUcdr6S; Tue, 8 Dec 2015 15:52:09 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 5102115F571; Tue, 8 Dec 2015 15:52:09 -0500 (EST) Date: Tue, 8 Dec 2015 15:52:08 -0500 (EST) From: Rick Macklem To: John Baldwin Cc: freebsd-current@freebsd.org, Adrian Chadd , Alexander Kabaev Message-ID: <1448756984.124315914.1449607928797.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <1558819.MnyjzOdus5@ralph.baldwin.cx> References: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> <387840531.122544462.1449529268528.JavaMail.zimbra@uoguelph.ca> <1558819.MnyjzOdus5@ralph.baldwin.cx> Subject: Re: slow screen updates on laptop console (i386) 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 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: slow screen updates on laptop console (i386) Thread-Index: OJpIEDEsGBhMt1/7khShMaECrN2+SA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 20:52:17 -0000 John Baldwin wrote: > On Monday, December 07, 2015 06:01:08 PM Rick Macklem wrote: > > Adrian Chadd wrote: > > > Hi, > > > > > > ok. please file a bug for that. It may be something to do with the > > > hardware and sleep states and skipping wakeups/interrupts or > > > something. > > > > > > Please try using the default again (LAPIC?) and set > > > kern.eventtimer.periodic=1. See if that fixes it. > > > > > Actually made it worse. Instead of being intermittently slow, it was > > almost constantly slow. > > Try disabling C-states if they are enabled. If you have a BIOS option > for C1E you might need to disable that as well. If this fixes it, then > there isn't a really viable solution in software, and you might prefer > to use the RTC to get the power savings from C-states. > Well, if the above refers to stuff that would be in the BIOS setup, there isn't anything. Nothing setable w.r.t. the processor and there isn't much of anything under power savings either (a couple of auto-boot options). - It's a single core i386 Celeron about 8 years old. (On the other hand, if these C states are something the FreeBSD kernel sets, then I don't know how it's done;-) Btw, I'm perfectly happy running it with RTC. It was Adrian that was interested in investigating it more. Thanks, rick > -- > John Baldwin > From owner-freebsd-current@freebsd.org Tue Dec 8 20:59:51 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 757E09D5DA6 for ; Tue, 8 Dec 2015 20:59:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 22B95138C; Tue, 8 Dec 2015 20:59:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:81/EPxIGPd1TAl0SudmcpTZWNBhigK39O0sv0rFitYgULPnxwZ3uMQTl6Ol3ixeRBMOAu6wC07KempujcFJDyK7JiGoFfp1IWk1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXsq3G/pQQfBg/4fVIsYL+lRMiK14ye7KObxd76W01wnj2zYLd/fl2djD76kY0ou7ZkMbs70RDTo3FFKKx8zGJsIk+PzV6nvp/jtLYqySlbuuog+shcSu26Ov1gFf0LRAghZkIy5MujnxDHQRSO4DNIUGUcuhRSDgXP9x28WY3+5HjUrO14jRObNs6+aLk/WjCv6u8/UhrhgyQDOjsR7WbYl8F0lKIdqxv39E83+JLdfIzAbKk2RajaZ95PADMZBss= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQDqQ2dW/61jaINehA1uBr05AQ2BbhcKgj2CZkoCgXcUAQEBAQEBAQGBCYItgggBAQQBAQEgKyALEAIBCA4KAgINGQICJwEJJgIECAcEARoCBIgODa5BkGYBAQEBAQEBAQEBAQEBAQEBAQEBFgSBAYVThH2EOwEBAYM5gUQFjh+IQoUthSOER4RDlk0CHwEBQoIRHYF0IDQHhCc6gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,400,1444708800"; d="scan'208";a="256494513" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 08 Dec 2015 15:59:44 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 1E2EC15F574; Tue, 8 Dec 2015 15:59:44 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id uP-l8efcxwNA; Tue, 8 Dec 2015 15:59:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id BEC5715F577; Tue, 8 Dec 2015 15:59:43 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OoVAlUsGW2fZ; Tue, 8 Dec 2015 15:59:43 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id A5AD315F571; Tue, 8 Dec 2015 15:59:43 -0500 (EST) Date: Tue, 8 Dec 2015 15:59:43 -0500 (EST) From: Rick Macklem To: John Baldwin Cc: freebsd-current@freebsd.org, Adrian Chadd , Alexander Kabaev Message-ID: <3445221.124330583.1449608383662.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <1558819.MnyjzOdus5@ralph.baldwin.cx> References: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> <387840531.122544462.1449529268528.JavaMail.zimbra@uoguelph.ca> <1558819.MnyjzOdus5@ralph.baldwin.cx> Subject: Re: slow screen updates on laptop console (i386) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: slow screen updates on laptop console (i386) Thread-Index: jp3IotxEfAEIl4zhz+gLZHssvC9LIw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 20:59:51 -0000 John Baldwin wrote: > On Monday, December 07, 2015 06:01:08 PM Rick Macklem wrote: > > Adrian Chadd wrote: > > > Hi, > > > > > > ok. please file a bug for that. It may be something to do with the > > > hardware and sleep states and skipping wakeups/interrupts or > > > something. > > > > > > Please try using the default again (LAPIC?) and set > > > kern.eventtimer.periodic=1. See if that fixes it. > > > > > Actually made it worse. Instead of being intermittently slow, it was > > almost constantly slow. > > Try disabling C-states if they are enabled. If you have a BIOS option > for C1E you might need to disable that as well. If this fixes it, then > there isn't a really viable solution in software, and you might prefer > to use the RTC to get the power savings from C-states. > Oh, I do see stuff like: hw.acpi.cpu.cx_lowest: C2 and dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/85 Is there a sysctl to disable "C states"? Thanks, rick ps: Like I said, I don't care, but maybe Adrian would like me to try settings? > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Dec 8 21:06:49 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B3209D435D for ; Tue, 8 Dec 2015 21:06:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 0D17119FE; Tue, 8 Dec 2015 21:06:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iofh3 with SMTP id h3so37862839iof.3; Tue, 08 Dec 2015 13:06: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:date:message-id:subject:from:to :cc:content-type; bh=tjoEvl5CoU8KrVFTfTM16aA31/zacxQEaxyqtS/rb+8=; b=FyZ9m4qLw+fB2oC64hyKHdQDyvZhYJm6LwrlGv31Emdza79z2IO0FD0lhXZiGUkHIh wfF4iiftwjnyeGvzsiblFSxEGSNDWNgh7TXOq4fOeiH/rpy401iqXpfmizgtycldLRN8 KCEWnAZhgNmQXIhObo/k/8pIS/gvmLhd5eCm3aC5mIJ4/4FQgKWyqEcq33yv/tkoV41R y6iJ8E2b2tQtnVYOkNyutFGqtxkt4DPF7/4cE5KvK+uSnBbEhdCQBmzyoGCQ5zHjFX5l WIo/7wjqyuit2ykAPGHZT4bJoSy/IA7+cf8iO3lhAa9cz+myDT5a2Skrir+R6MP6YrOm DvKg== MIME-Version: 1.0 X-Received: by 10.107.162.21 with SMTP id l21mr1834614ioe.123.1449608808434; Tue, 08 Dec 2015 13:06:48 -0800 (PST) Received: by 10.36.217.196 with HTTP; Tue, 8 Dec 2015 13:06:48 -0800 (PST) In-Reply-To: <3445221.124330583.1449608383662.JavaMail.zimbra@uoguelph.ca> References: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> <387840531.122544462.1449529268528.JavaMail.zimbra@uoguelph.ca> <1558819.MnyjzOdus5@ralph.baldwin.cx> <3445221.124330583.1449608383662.JavaMail.zimbra@uoguelph.ca> Date: Tue, 8 Dec 2015 13:06:48 -0800 Message-ID: Subject: Re: slow screen updates on laptop console (i386) From: Adrian Chadd To: Rick Macklem Cc: John Baldwin , freebsd-current , Alexander Kabaev Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 21:06:49 -0000 Hi, Yea - try setting hw.acpi.cpu.cx_lowest=C1 and re-test. -a From owner-freebsd-current@freebsd.org Tue Dec 8 21:19:53 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BEF89D4B4B for ; Tue, 8 Dec 2015 21:19:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id AA1691F6D; Tue, 8 Dec 2015 21:19:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:JSg/pxN/v5AHoRXvyMUl6mtUPXoX/o7sNwtQ0KIMzox0KPv5rarrMEGX3/hxlliBBdydsKIazbKO+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStCU15z//tvx0qOQSj0AvCC6b7J2IUf+hiTqne5Sv7FfLL0swADCuHpCdrce72ppIVWOg0S0vZ/or9ZLuh5dsPM59sNGTb6yP+FhFeQZX3waNDUc6NfqvB+LZguG6ndUBmwaiBtBBU7O7Bj2Ur/+tyL7sqx23yzMbuPsSrVhYzWp7O9OQRTrjCoCf2oj9Wjcich9iYpGpx28qhhnw8jfadfGZ7JFYqrBcIZCFiJ6VcFLWnkEW9vkYg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BLAgBnSGdW/61jaINehA1uBr05AQ1QCoEUFwqFI0oCgXcUAQEBAQEBAQGBCYItgggBAQQBAQEgKyALEAIBCBgCAg0ZAgInAQkmAgQIBwQBHASIDg2uLJBlAQEBAQEBAQEBAQEBAQEBAQEBAQEVBIEBhVOEfYQ7AQGDOoFEBY4fiEKFLYUjn1cCHwEBQoQiIDQHhCc6gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,400,1444708800"; d="scan'208";a="254962329" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 08 Dec 2015 16:19:51 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 78EB015F571; Tue, 8 Dec 2015 16:19:51 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3Z9b3LlQu3VB; Tue, 8 Dec 2015 16:19:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 3BFB415F574; Tue, 8 Dec 2015 16:19:51 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KRBBBQjFvZc4; Tue, 8 Dec 2015 16:19:51 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 2211F15F571; Tue, 8 Dec 2015 16:19:51 -0500 (EST) Date: Tue, 8 Dec 2015 16:19:51 -0500 (EST) From: Rick Macklem To: Adrian Chadd Cc: John Baldwin , freebsd-current , Alexander Kabaev Message-ID: <1293110103.124362847.1449609591122.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> <387840531.122544462.1449529268528.JavaMail.zimbra@uoguelph.ca> <1558819.MnyjzOdus5@ralph.baldwin.cx> <3445221.124330583.1449608383662.JavaMail.zimbra@uoguelph.ca> Subject: Re: slow screen updates on laptop console (i386) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: slow screen updates on laptop console (i386) Thread-Index: zrm3x3DVNGayLYo8oLwLR/MygdGO2Q== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 21:19:53 -0000 Adrian Chadd wrote: > Hi, > > Yea - try setting hw.acpi.cpu.cx_lowest=C1 and re-test. > Yep, with this setting, LAPIC seems to work fine. rick > > -a > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Dec 8 21:27:20 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 434329D30FE for ; Tue, 8 Dec 2015 21:27:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) 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 13D94162A; Tue, 8 Dec 2015 21:27:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcph11 with SMTP id ph11so104831657igc.1; Tue, 08 Dec 2015 13:27:19 -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=jn1HwZg3IC0PMNvQPsRkIAdxRL7K4Clduv92KJMWdW4=; b=H+QnXD0zaqqDl4V3/Df0Gn05BLiyUnDvfZEi289uqQql40CuFVSj8lZdK+shBu7hw1 qEFg6SoXGpQNpOglclQr9UXz0l45Tf5GscKAg6T78qg9A+98eFo8y9tOsIwPOl2d/g46 7+9FRjnShqEAcOCT/MvHF0cyQ98Oy2m/t7os8vfksmTVMeoNZl8yPXnCIzyh2u4cxf7+ rKrL9oJM3y7dz/AtA3LBfDk3JYLCSSbjg89sARaiXaRlNuRv7jNSo0+a3D0UsWdHdESR QC46e0jkHpIhXQEErlHH4jeWGR1nje7TIlkF43EAGInlGUSwuSg5oqVgLT6862eY/5BQ Za0Q== MIME-Version: 1.0 X-Received: by 10.50.97.42 with SMTP id dx10mr12919009igb.37.1449610039562; Tue, 08 Dec 2015 13:27:19 -0800 (PST) Received: by 10.36.217.196 with HTTP; Tue, 8 Dec 2015 13:27:19 -0800 (PST) In-Reply-To: <1293110103.124362847.1449609591122.JavaMail.zimbra@uoguelph.ca> References: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> <387840531.122544462.1449529268528.JavaMail.zimbra@uoguelph.ca> <1558819.MnyjzOdus5@ralph.baldwin.cx> <3445221.124330583.1449608383662.JavaMail.zimbra@uoguelph.ca> <1293110103.124362847.1449609591122.JavaMail.zimbra@uoguelph.ca> Date: Tue, 8 Dec 2015 13:27:19 -0800 Message-ID: Subject: Re: slow screen updates on laptop console (i386) From: Adrian Chadd To: Rick Macklem Cc: John Baldwin , freebsd-current , Alexander Kabaev Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 21:27:20 -0000 ok, can you post the full dmesg? I'd like to know which CPU this is. Thanks, -a On 8 December 2015 at 13:19, Rick Macklem wrote: > Adrian Chadd wrote: >> Hi, >> >> Yea - try setting hw.acpi.cpu.cx_lowest=C1 and re-test. >> > Yep, with this setting, LAPIC seems to work fine. > > rick > >> >> -a >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://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 Dec 8 21:30:48 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99F549D34DF for ; Tue, 8 Dec 2015 21:30:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 094A118CA; Tue, 8 Dec 2015 21:30:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:sJsP7BR2CFnra9+08KaEzeJeBtpsv+yvbD5Q0YIujvd0So/mwa65ZxON2/xhgRfzUJnB7Loc0qyN4/6mATRIyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/niabqo9X6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPDtrgTJGAuT+mMHACJRlhtTHxOD4gv3U53qvm39rOU63SCbOcj/S/cwWC++7qFlT1jmkioKPSU1tWrKkNZ9ir4InBX0jhBlwofSKKqVPfZyNvfUcckbTGwHVcZYWyBpDYa1bo9JBO0Ea7V2tY748mEPphj2IACnB+fiz3ccnHr/1q4+3uEJDAbJwQEkB9JIu32C/4a9D7sbTe3glPqA9j7Edf4DnG6lsIU= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DQAQA/SmdW/61jaINWCIQNbga9OQENgW4XCoI9gmZKAoF3FAEBAQEBAQEBgQmCLYIHAQEBAwEBAQEgKyACCQULAgEIGAICDQUBEwICJwEJJgIECAIFBAEcBIgGCA2RIJ0NkGUBAQEBAQEBAQIBAQEBAQEBAQEBFQSBAYVThH2EJBIFAQEBZQGCU4FEBYYUCYEvhlM9h0VAhS2FIySfMwIfAQFCghEdgXQgNAeEIAcXI4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,400,1444708800"; d="scan'208";a="254964586" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 08 Dec 2015 16:30:46 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 62F6C15F571; Tue, 8 Dec 2015 16:30:46 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id jS1qJ45JD-cd; Tue, 8 Dec 2015 16:30:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 67D4B15F574; Tue, 8 Dec 2015 16:30:45 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 24l-QZW2Z0UW; Tue, 8 Dec 2015 16:30:45 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 4916815F571; Tue, 8 Dec 2015 16:30:45 -0500 (EST) Date: Tue, 8 Dec 2015 16:30:45 -0500 (EST) From: Rick Macklem To: Adrian Chadd Cc: John Baldwin , freebsd-current , Alexander Kabaev Message-ID: <932602686.124378139.1449610245277.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <900422043.121631608.1449496955386.JavaMail.zimbra@uoguelph.ca> <387840531.122544462.1449529268528.JavaMail.zimbra@uoguelph.ca> <1558819.MnyjzOdus5@ralph.baldwin.cx> <3445221.124330583.1449608383662.JavaMail.zimbra@uoguelph.ca> <1293110103.124362847.1449609591122.JavaMail.zimbra@uoguelph.ca> Subject: Re: slow screen updates on laptop console (i386) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: slow screen updates on laptop console (i386) Thread-Index: 2XyLvrSL2WV+KMJDeovSEjLXjc6R7g== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 21:30:48 -0000 Adrian Chadd wrote: > ok, can you post the full dmesg? I'd like to know which CPU this is. > Ok, here it is (Kostik already asked, so I have it right here;-): Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #4: Sat Dec 5 17:56:08 EST 2015 root@nfsv4-laptop.rick.home:/usr/src/sys.nov30-2015/i386/compile/GENERIC i386 FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525 WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: Intel(R) Celeron(R) M processor 1.40GHz (1396.57-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6d8 Family=0x6 Model=0xd Stepping=8 Features=0xafe9fbff AMD Features=0x100000 real memory = 268435456 (256 MB) avail memory = 219033600 (208 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: random: unblocking device. ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard random: entropy device external interface kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xc10daf40, 0) error 19 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard cpu0: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xeff8-0xefff mem 0xdff00000-0xdff7ffff,0xc0000000-0xcfffffff,0xdfec0000-0xdfefffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 7932k stolen memory vgapci0: Boot video device vgapci1: mem 0xdff80000-0xdfffffff at device 2.1 on pci0 hdac0: mem 0xdfebc000-0xdfebffff irq 16 at device 27.0 on pci0 pcib1: at device 28.0 on pci0 pci1: on pcib1 pcib2: at device 28.3 on pci0 pci2: on pcib2 uhci0: port 0xbf80-0xbf9f irq 16 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0xbf60-0xbf7f irq 17 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0xbf40-0xbf5f irq 18 at device 29.2 on pci0 usbus2 on uhci2 uhci3: port 0xbf20-0xbf3f irq 19 at device 29.3 on pci0 usbus3 on uhci3 ehci0: mem 0xb0000000-0xb00003ff irq 16 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib3: at device 30.0 on pci0 pci3: on pcib3 bfe0: mem 0xdfbfe000-0xdfbfffff irq 18 at device 0.0 on pci3 miibus0: on bfe0 bmtphy0: PHY 1 on miibus0 bmtphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:14:22:93:66:a0 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf irq 16 at device 31.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcf7ff,0xcf800-0xcffff pnpid ORM0000 on isa0 ppc0: parallel port not found. Timecounters tick every 0.976 msec IPsec: Initialized Security Association Processing. hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 14,13 on hdaa0 hdacc1: at cad 1 on hdac0 unknown: at nid 2 on hdacc1 (no driver attached) usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 usbus4: 480Mbps High Speed USB v2.0 ugen4.1: at usbus4 uhub4: on usbus4 ada0 at ata0 bus 0 scbus0 target 0 lun 0 cd0 at ata0 bus 0 scbus0 target 1 lun 0 cd0: Removable CD-ROM SCSI device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present ada0: ATA-7 device ada0: Serial Number S03WJ40YA03331 ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 38154MB (78140160 512 byte sectors) Timecounter "TSC" frequency 1396569526 Hz quality 800 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ada0s1a [rw]... uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Setting hostuuid: 44454c4c-3300-1038-8047-cac04f443831. Setting hostid: 0x49e43364. warning: total configured swap (1310720 pages) exceeds maximum recommended amount (439936 pages). warning: increase kern.maxswzone or reduce amount of swap. Starting file system checks: /dev/ada0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s1a: clean, 1131648 free (504 frags, 141393 blocks, 0.0% fragmentation) /dev/ada0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s1d: clean, 2207358 free (2270 frags, 275636 blocks, 0.1% fragmentation) /dev/ada0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s1e: clean, 1390306 free (105498 frags, 160601 blocks, 3.5% fragmentation) Mounting local file systems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Setting hostname: nfsv4-laptop.rick.home. Setting up harvesting:[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: uhub4: 8 ports with 8 removable, self powered . bfe0: link state changed to DOWN bfe0: link state changed to UP Starting Network: lo0 bfe0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 groups: lo bfe0: flags=8843 metric 0 mtu 1500 options=80008 ether 00:14:22:93:66:a0 inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active Starting devd. add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Creating and/or trimming log files. Starting syslogd. No core dumps found. Starting casperd. Clearing /tmp (X related). NFS on reserved port only=YES Starting nfsuserd. Starting rpcbind. Starting mountd. Starting nfsd. Updating motd:. Mounting late file systems:. Configuring vt: blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting cron. Starting inetd. Tue Dec 8 17:02:04 EST 2015 Dec 8 17:02:09 nfsv4-laptop login: ROOT LOGIN (root) ON ttyv0 > Thanks, > > -a > > > On 8 December 2015 at 13:19, Rick Macklem wrote: > > Adrian Chadd wrote: > >> Hi, > >> > >> Yea - try setting hw.acpi.cpu.cx_lowest=C1 and re-test. > >> > > Yep, with this setting, LAPIC seems to work fine. > > > > rick > > > >> > >> -a > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Dec 8 22:14:22 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D53A79D452C; Tue, 8 Dec 2015 22:14:22 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C54BF1FC7; Tue, 8 Dec 2015 22:14:22 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id BD3FC1F8B; Tue, 8 Dec 2015 22:14:22 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 7345B16D6D; Tue, 8 Dec 2015 22:14:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id Uq7BxFo86i41; Tue, 8 Dec 2015 22:14:19 +0000 (UTC) Subject: Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 431EC16D64 To: Mark Millard , "Simon J. Gerraty" References: <2426.1449521335@chaos> Cc: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current From: Bryan Drewery Organization: FreeBSD Message-ID: <56675638.5010904@FreeBSD.org> Date: Tue, 8 Dec 2015 14:14:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 22:14:22 -0000 On 12/7/15 1:33 PM, Mark Millard wrote: > >> On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty wrote: >> >> Mark Millard wrote: >>> My guess is that it is picking up the >>> >>> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain >> >> You should use ?= if you want this to work. >> There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked >> in the environment of a sub-make. >> >> By using = above, you break that. > > That presumes that MAKEOBJDIRPREFIX has not been assigned a default value before the SRC_ENV_CONF file has been included the first time. If MAKEOBJDIRPREFIX had been defined already then the ?= would do nothing and the wrong value would be used. > > I believe that the following trace shows that such an assignment of a default value does happen first, making ?= not work either. > > > > /usr/src/Makefile (head/Makefile 29160) has > >> MAKEOBJDIRPREFIX?= /usr/obj > > at line 145 (used when it is not using targets/Makefile from the relevant .if/.else/.endif). > > Line 105 has .include and there no others before the above assignment. bsd.compiler.mk in turn includes bsd.opt.mk (only), which in turns includes bsd.mkopt.mk (only). That in turn includes nothing else. So these files and only these files are the involved files before that assignment as far as I can tell. > > None of these get to src.sys.env.mk and so SRC_ENV_CONF use has not happened yet when > >> MAKEOBJDIRPREFIX?= /usr/obj > > is executed. > > So, if I understand right, MAKEOBJDIRPREFIX is already defined before the code > >> SRC_ENV_CONF?= /etc/src-env.conf >> .if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_) >> .-include "${SRC_ENV_CONF}" >> _src_env_conf_included_: .NOTMAIN >> .endif > > is executed and so using ?= would not be effective in the included file. > > Did I miss something? Yes. sys.mk and src-env.conf are included *before* Makefile. Think of it as being in line 0. Technically you should be able to use MAKEOBJDIRPREFIX in make.conf or src.conf if you are not using any of the meta mode features (all off by default). -- Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Tue Dec 8 22:31:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3A599D4F9D for ; Tue, 8 Dec 2015 22:31:00 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 7D6541754 for ; Tue, 8 Dec 2015 22:31:00 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pfbg73 with SMTP id g73so19224533pfb.1 for ; Tue, 08 Dec 2015 14:31:00 -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=DGeCD7vppW0huIq1PTrvA/zd/VSStUplA5sZZc1NyFU=; b=ejV4EWrjpMkNUSt1JtrLmOzZZ+ihdbmd8Ui5qKII93hFWnKSKikQQs1PApkOs3LVV6 EL4LGwYik1K1r3Dtgi12AlfUHrdPRLMLNVYNkdEmHxXBBb21nUzdlbhvFytnTciPXmR1 kh8vPxubskNrLqcAt7jVjxyicpcLo15LfK9hDzf3A/Xhpvq6wMKe6ts6AOvoQ6AnR9YQ kdJFMyiudtkp/k4JbIQFU1YYSd9G2aQ3JxuDpS+g+hSru+ZKbD4rG2DGvlluArxfqAsx ppEcnVbXbxmp/1oJB0RVqHAkmrOlG7nfR2z6u19Gf/lXeagbURNyBKObbMqZZnTETctU 5e4Q== X-Received: by 10.98.13.200 with SMTP id 69mr7956470pfn.165.1449613860133; Tue, 08 Dec 2015 14:31:00 -0800 (PST) Received: from ?IPv6:2601:601:800:126d:7068:a5d3:b3dd:5ea4? ([2601:601:800:126d:7068:a5d3:b3dd:5ea4]) by smtp.gmail.com with ESMTPSA id r20sm6838075pfa.93.2015.12.08.14.30.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Dec 2015 14:30:58 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Panic at shutdown From: NGie Cooper In-Reply-To: Date: Tue, 8 Dec 2015 14:30:56 -0800 Cc: FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: References: <055E0877-533A-4378-A306-FDE511543243@gmail.com> To: "Ranjan1018 ." <214748mv@gmail.com> X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 08 Dec 2015 22:31:00 -0000 > On Dec 8, 2015, at 08:09, Ranjan1018 . <214748mv@gmail.com> wrote: =E2=80=A6 > Probably the panic is caused by some memory already freed, the hex = value of 16045693110842147038 is 0xdeadc0dedeadc0de. > To solve the panic I need some tips form someone more expert than me = in ZFS code. Good investigative work! There was something reported recently about = unaligned accesses when dealing with msdosfs+zfs+etc, but it was an odd = edgecase. Definitely file a bug and assign it to freebsd-fs@ with the findings you = have made here. Thanks :)! -NGie= From owner-freebsd-current@freebsd.org Wed Dec 9 08:01:22 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0303A9D574B for ; Wed, 9 Dec 2015 08:01:22 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DC21213C3 for ; Wed, 9 Dec 2015 08:01:21 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id D80309D574A; Wed, 9 Dec 2015 08:01:21 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D79679D5749 for ; Wed, 9 Dec 2015 08:01:21 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9661F13C2 for ; Wed, 9 Dec 2015 08:01:21 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p57BB8137.dip0.t-ipconnect.de [87.187.129.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id C400D83E402 for ; Wed, 9 Dec 2015 09:00:54 +0100 (CET) Received: from localhost (Titan.Leidinger.net [192.168.1.17]) (using TLSv1.2 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: Alexander@Leidinger.net) by outgoing.leidinger.net (Postfix) with ESMTPSA id C46755080 for ; Wed, 9 Dec 2015 09:00:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1449648051; bh=6stl2HrlEvEq4NIesSkxnZZIexL1mwhKuU095O/EU8c=; h=Date:From:To:Subject; b=pNIxeRH/YDu5z47RVwxThwjv7pocry6mhKXLn1MJFYM7plzhKB8qtTYHhFpeofD2N xF0MNHBNrx3LNDTwgmXNXgRDs9YWzkFkwZjFhikaFDoki3/n9DrlcVdZa+QG61IoOh h7JGuaHgOfwMc91SHhay9HeVvZ0L25pwRLEKL8X8bYxD82ww/O8mOXThdCo/gaRmRW RtKX/pRrLuT6L+ITT9j3HRIgO7I9A8O+mhWqcGWWKgNZbKihHg8u+YdkXdmgRCVXdi ITMIyQPOGbBDFyXlhdnkkzkJM+4qlRV2oGNvSFTsIAn0PnzFilFKc9XZfTFYS45zly JeFdS2bmpFuDg== Date: Wed, 9 Dec 2015 09:00:49 +0100 From: Alexander Leidinger To: current@FreeBSD.org Subject: Something in r291926 (and earlier) causes reboots during periodic daily (14 jails on system) Message-ID: <20151209090049.000003db@Leidinger.net> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: C400D83E402.A1C0A X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1450252855.17627@cIrqi6nb0mABATwCxtyYLQ X-EBL-Spam-Status: No X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 09 Dec 2015 08:01:22 -0000 Hi, with r291381 a system with 14 jails survives about 1-2 days. with r291926 this system survives 1 day. In both cases it reboots during periodic daily (the jails run periodic too, at the usual time). This is a ZFS-only (+nullfs) system There is no coredump. Watchdogd is currently not enabled on this system. In the logs I don't find any traces. The system is not really low on resources: last pid: 18031; load averages: 0.25, 0.23, 0.80 up 0+03:59:05 08:57:12 189 processes: 1 running, 188 sleeping CPU: 0.3% user, 0.0% nice, 0.4% system, 0.1% interrupt, 99.1% idle Mem: 579M Active, 709M Inact, 2311M Wired, 8253M Free ARC: 1460M Total, 418M MFU, 868M MRU, 1946K Anon, 17M Header, 155M Other Swap: 4096M Total, 4096M Free Does this ring a bell for someone or any ideas before I try to hunt this down? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0xC773696B3BAC17DC http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0xC773696B3BAC17DC From owner-freebsd-current@freebsd.org Wed Dec 9 08:47:18 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 163899D3CE5 for ; Wed, 9 Dec 2015 08:47:18 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 040791DBF for ; Wed, 9 Dec 2015 08:47:18 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: by mailman.ysv.freebsd.org (Postfix) id 007A59D3CE4; Wed, 9 Dec 2015 08:47:18 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 001799D3CE3 for ; Wed, 9 Dec 2015 08:47:17 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 BA7291DBE for ; Wed, 9 Dec 2015 08:47:17 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 589BC2842E; Wed, 9 Dec 2015 09:38:08 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 4812F2840C; Wed, 9 Dec 2015 09:38:07 +0100 (CET) Message-ID: <5667E86F.3050906@quip.cz> Date: Wed, 09 Dec 2015 09:38:07 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Alexander Leidinger , current@FreeBSD.org Subject: Re: Something in r291926 (and earlier) causes reboots during periodic daily (14 jails on system) References: <20151209090049.000003db@Leidinger.net> In-Reply-To: <20151209090049.000003db@Leidinger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 09 Dec 2015 08:47:18 -0000 Alexander Leidinger wrote on 12/09/2015 09:00: > Hi, > > with r291381 a system with 14 jails survives about 1-2 days. > with r291926 this system survives 1 day. > > In both cases it reboots during periodic daily (the jails run periodic > too, at the usual time). This is a ZFS-only (+nullfs) system > > There is no coredump. Watchdogd is currently not enabled on this > system. In the logs I don't find any traces. > > The system is not really low on resources: > last pid: 18031; load averages: 0.25, 0.23, 0.80 up 0+03:59:05 08:57:12 > 189 processes: 1 running, 188 sleeping > CPU: 0.3% user, 0.0% nice, 0.4% system, 0.1% interrupt, 99.1% idle > Mem: 579M Active, 709M Inact, 2311M Wired, 8253M Free > ARC: 1460M Total, 418M MFU, 868M MRU, 1946K Anon, 17M Header, 155M Other > Swap: 4096M Total, 4096M Free > > Does this ring a bell for someone or any ideas before I try to hunt > this down? The same problem was reported yesterday on Stable Periodic jobs triggering panics in 10.1 and 10.2 https://lists.freebsd.org/pipermail/freebsd-stable/2015-December/083807.html Also ZFS with jails. Miroslav Lachman From owner-freebsd-current@freebsd.org Wed Dec 9 09:52:17 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F156E9D5388 for ; Wed, 9 Dec 2015 09:52:16 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D397F121B for ; Wed, 9 Dec 2015 09:52:16 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id D116D9D5385; Wed, 9 Dec 2015 09:52:16 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D068C9D5383; Wed, 9 Dec 2015 09:52:16 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C0AA1218; Wed, 9 Dec 2015 09:52:16 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p57BB8137.dip0.t-ipconnect.de [87.187.129.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 314EF83E402; Wed, 9 Dec 2015 10:51:48 +0100 (CET) Received: from localhost (Titan.Leidinger.net [192.168.1.17]) (using TLSv1.2 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: Alexander@Leidinger.net) by outgoing.leidinger.net (Postfix) with ESMTPSA id 83881509C; Wed, 9 Dec 2015 10:51:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1449654705; bh=0zO+SDHgHa5fcKkCKsFI3DOs4t0xwzHZhqMIK+ceviQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=fhIHw8VaQ80Xgh3EwvT2t3rLO7AA85Z+ew/9F2os1wfle/bKW56H019TJhDI8DTUW OIWtUo95zxeOBE6oaTSCvlKML9JnJzUW5djTdtaYB0V5W/xN037cqB9ZMV5ulHEjII FUj1yD5yTpQigw7/FHQuNjV7SzeFEsT3zAdHaDXmJsZUxspgnfMNtjhLIPUnRTkHHv 2qqRgyFOuoq7vxCDARGG4HcFbXrJob9BJmCGJppzPS9b64qUlWR9wBvrp+1ss7VtEl ru3yJ5ZrNKp5ug4yXGcAiP1tJbLYqzlvWv3A+7lhWH2SNASt/dBhrQk17BU2GBkp1s 6+AVjGR8zxUtw== Date: Wed, 9 Dec 2015 10:51:44 +0100 From: Alexander Leidinger To: Miroslav Lachman <000.fbsd@quip.cz> Cc: current@FreeBSD.org, stable@FreeBSD.org, fs@freebsd.org Subject: Re: Something in r291926 (and earlier) causes reboots during periodic daily (14 jails on system) Message-ID: <20151209105144.000035be@Leidinger.net> In-Reply-To: <5667E86F.3050906@quip.cz> References: <20151209090049.000003db@Leidinger.net> <5667E86F.3050906@quip.cz> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 314EF83E402.A37C1 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1450259509.76673@1p5YboINg4iXzV0psIEvLA X-EBL-Spam-Status: No X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 09 Dec 2015 09:52:17 -0000 On Wed, 09 Dec 2015 09:38:07 +0100 Miroslav Lachman <000.fbsd@quip.cz> wrote: > Alexander Leidinger wrote on 12/09/2015 09:00: > > Does this ring a bell for someone or any ideas before I try to hunt > > this down? > > The same problem was reported yesterday on Stable > > Periodic jobs triggering panics in 10.1 and 10.2 > https://lists.freebsd.org/pipermail/freebsd-stable/2015-December/083807.html > > Also ZFS with jails. The above mail has a backtrace involving ZFS. I'm running the periodic scripts serially now, 8 out of 14 already finished without issues. Smells like a concurrency issue. I would assume it's something introduced between 5 and 1 month ago and MFCed back to 10. Does this ring a bell for someone on fs@? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0xC773696B3BAC17DC http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0xC773696B3BAC17DC From owner-freebsd-current@freebsd.org Wed Dec 9 14:04:19 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE59E9D52F4 for ; Wed, 9 Dec 2015 14:04:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (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 5B2F2105B for ; Wed, 9 Dec 2015 14:04:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15717 invoked from network); 9 Dec 2015 14:04:11 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Dec 2015 14:04:11 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Wed, 09 Dec 2015 09:04:15 -0500 (EST) Received: (qmail 23234 invoked from network); 9 Dec 2015 14:04:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 9 Dec 2015 14:04:14 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7C5301C43BA; Wed, 9 Dec 2015 06:04:09 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling From: Mark Millard In-Reply-To: <5664BA32.3010306@fgznet.ch> Date: Wed, 9 Dec 2015 06:04:10 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current , freebsd-ports@freebsd.org, Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: <1D7927B2-9CC4-4F43-A6A5-2F2B855CDAE9@dsl-only.net> References: <867D2B14-766D-4104-9A77-C35992C357B8@dsl-only.net> <5664BA32.3010306@fgznet.ch> To: Andreas Tobler X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 09 Dec 2015 14:04:19 -0000 [This time I'm explicit about a patch-gcc-freebsd-powerpc64 update and I = report that with the change the PowerMac G5 hosted powerpc64-gcc based = buildworld attempt completed, including WITH_LIB32=3D and WITH_BOOT=3D = being involved. (But it may not be until tomorrow or later until I test = if such a build actually works for installworld and reboot.)] > On 2015-Dec-6, at 2:44 PM, Andreas Tobler = wrote: >=20 > On 06.12.15 22:34, Mark Millard wrote: >> [I picked the lists that I did because powerpc64-gcc is the external >> toolchain created to allow modern powerpc64 builds.] >>=20 >> For the powerpc64-gcc 5.2 vintages. . . (using my environment's path >> as an example) >>=20 >> = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config= /rs6000/freebsd64.h >> has: >>=20 >>> /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults >>> instead. */ #undef WCHAR_TYPE #define WCHAR_TYPE >>> (TARGET_64BIT ? "int" : "long int") #undef WCHAR_TYPE_SIZE #define >>> WCHAR_TYPE_SIZE 32 >>=20 >> That type in quotes ends up being the base type for L". . ." >> notation, for example. Probably the char notation as well (L'?'). >>=20 >> For FreeBSD Char compatibility in a powerpc64 lib32 context that >> "long int" should effectively instead be "int", making the >> conditional above technically unnecessary. >>=20 >> This blocks compiling lib32 source code that uses such notations as >> L". . .": "long int" is not compatible with FreeBSD's Char in the >> powerpc64 environment's 32 bit environment. Some compiler message are >> explicit about the base types of pointers that result for the >> mismatches: that is how I know that "long int" is in use for L". . ." >> and "int" is the other base type involved. >>=20 >> (Yes, freebsd64.h appears to be used for lib32, at least on >> powerpc64. By contrast freebsd.h agrees for the WCHAR_TYPE_SIZE but >> only undef's WCHAR_TYPE, presuming gcc defaults are correct for >> FreeBSD as far as the type goes. It might need a more explicit type >> to be sure of a Char match for that freebsd.h file's context.) >>=20 >> The 4.9 vintages of powerpc64-gcc were messed up the same way, as was >> noted at the time. >=20 > I'll take care. >=20 > Andreas (I make no claim that this note manages to preserve tabs and such in the = diff -u text.) To turn my earlier note into an actual updated = devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64 instead of the = more vague words would involve adding what would look something like: > @@ -304,7 +317,7 @@ > =20 > /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults = instead. */ > #undef WCHAR_TYPE > -#define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > +#define WCHAR_TYPE "int" > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 >=20 (It is what I actually tested.) The full patch-gcc-freebsd-powerpc64 would then look something like: > --- gcc/config/rs6000/freebsd64.h.orig 2015-01-05 04:33:28.000000000 = -0800 > +++ gcc/config/rs6000/freebsd64.h 2015-12-09 00:14:28.520684000 = -0800 > @@ -65,6 +65,13 @@ > #define INVALID_64BIT "-m%s not supported in this configuration" > #define INVALID_32BIT INVALID_64BIT > =20 > +/* Use LINUX64 instead of FREEBSD64 for compat with e.g. sysv4le.h */ > +#ifdef LINUX64_DEFAULT_ABI_ELFv2 > +#define ELFv2_ABI_CHECK (rs6000_elf_abi !=3D 1) > +#else > +#define ELFv2_ABI_CHECK (rs6000_elf_abi =3D=3D 2) > +#endif > + > #undef SUBSUBTARGET_OVERRIDE_OPTIONS > #define SUBSUBTARGET_OVERRIDE_OPTIONS \ > do \ > @@ -84,6 +91,12 @@ > rs6000_isa_flags &=3D ~OPTION_MASK_RELOCATABLE; \ > error (INVALID_64BIT, "relocatable"); \ > } \ > + if (ELFv2_ABI_CHECK) \ > + { \ > + rs6000_current_abi =3D ABI_ELFv2; \ > + if (dot_symbols) \ > + error ("-mcall-aixdesc incompatible with = -mabi=3Delfv2"); \ > + } \ > if (rs6000_isa_flags & OPTION_MASK_EABI) \ > { \ > rs6000_isa_flags &=3D ~OPTION_MASK_EABI; \ > @@ -304,7 +317,7 @@ > =20 > /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults = instead. */ > #undef WCHAR_TYPE > -#define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > +#define WCHAR_TYPE "int" > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 > =20 I can report that a make buildworld with the following WITH/WITHOUT = src.conf type options competed based on the rebuilt powerpc64-gcc. = (WITHOUT_CLANG=3D and WITHOUT_LLDB=3D were just to save time. The = context is already libc++ based and so WITHOUT_GCC=3D and = WITHOUT_GNUXX=3D.) > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc > TARGET_ARCH=3Dpowerpc64 > WITHOUT_CROSS_COMPILER=3D > # > # 1 thing that fails to build if attempted: > WITHOUT_CLANG_EXTRAS=3D > # > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BOOT=3D > WITH_LIB32=3D > WITHOUT_CLANG=3D > WITHOUT_CLANG_IS_CC=3D > WITHOUT_CLANG_FULL=3D > WITHOUT_LLDB=3D > # > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > #CFLAGS+=3D -DELF_VERBOSE > # > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D The FreeBSD version context is: > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #17 r291745M: Sat = Dec 5 08:20:20 PST 2015 = root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc = 1100091 1100091 The technique of using powerpc64-gcc as the host/cross compiler in this = context was as follows. (No gcc 4.2.1 present and clang 3.7 unused. No = initial lib32.) First some symbolic links: > # ls -al /usr/lib/libstdc* > lrwxr-xr-x 1 root wheel 8 Dec 5 05:41 /usr/lib/libstdc++.a -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Dec 5 05:41 /usr/lib/libstdc++.so -> = libc++.so > # ls -l /usr/bin/g[c+][c+] > lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/g++ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc These cover the existing forced, explicit "gcc" commands in a powerpc64 = related csu Makefile and other "old style" references that occur. Also some other file updates: > # svnlite diff /usr/src/ > Index: /usr/src/sys/boot/ofw/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/boot/ofw/Makefile.inc (revision 291891) > +++ /usr/src/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/src/sys/boot/powerpc/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/boot/powerpc/Makefile.inc (revision 291891) > +++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,6 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/src/sys/boot/uboot/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/boot/uboot/Makefile.inc (revision 291891) > +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" There is more src.conf type content to cause use of the powerpc64-gcc = toolchain: > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > # > DEPFLAGS+=3D -isystem = /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include/. = -I/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include/c+= +/v1/. -I/usr/include/c++/v1/. > # > CFLAGS+=3D -isystem = /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include/. = -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/lib/. = -L/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -L/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/lib/. > # > LDFLAGS+=3D -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -Wl,-rpath-link = -Wl,/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/lib/. = -L/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/lib/. = -L/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/lib/. > # > CXXFLAGS+=3D -isystem = /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include/. = -I/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include/c+= +/v1/. -std=3Dgnu++11 > # > CXXFLAGS+=3D -I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. (I'll not get into the details of my workaround for building = powerpc64-gcc in a powerpc64 context, where it is not truly a cross = compiler. I copy 6 files to the right staging place/name when they are = not found and then restart the powerpc64-gcc install. I use gcc49 to = build powerpc64-gcc.) From owner-freebsd-current@freebsd.org Wed Dec 9 18:23:45 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD6999D68F8 for ; Wed, 9 Dec 2015 18:23:45 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 8DC6B100F; Wed, 9 Dec 2015 18:23:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8F65BB94E; Wed, 9 Dec 2015 13:23:43 -0500 (EST) From: John Baldwin To: Don Lewis Cc: freebsd-current@freebsd.org Subject: Re: panic: sbuf_vprintf called with a NULL sbuf pointer Date: Tue, 08 Dec 2015 12:27:48 -0800 Message-ID: <2246380.LId0aa2Jcy@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <201512081940.tB8JduPg003988@gw.catspoiler.org> References: <201512081940.tB8JduPg003988@gw.catspoiler.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 09 Dec 2015 13:23:43 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 09 Dec 2015 18:23:45 -0000 On Tuesday, December 08, 2015 11:39:56 AM Don Lewis wrote: > On 8 Dec, John Baldwin wrote: > > On Monday, December 07, 2015 10:10:51 PM Don Lewis wrote: > >> On 2 Dec, John Baldwin wrote: > >> > On Wednesday, December 02, 2015 01:25:56 PM Don Lewis wrote: > >> >> > If you want to look at this further, try going to frame 16 and dissassembling the > >> >> > instructions before the call to see if you can spot which register the first > >> >> > parameter (saved in %rdi IIRC) comes from. > >> >> > >> >> Dump of assembler code for function sbuf_printf: > >> >> 0xffffffff80a673e0 <+0>: push %rbp > >> >> 0xffffffff80a673e1 <+1>: mov %rsp,%rbp > >> >> 0xffffffff80a673e4 <+4>: push %r14 > >> >> 0xffffffff80a673e6 <+6>: push %rbx > >> >> 0xffffffff80a673e7 <+7>: sub $0x50,%rsp > >> >> 0xffffffff80a673eb <+11>: mov %rsi,%r14 > >> >> 0xffffffff80a673ee <+14>: mov %rdi,%rbx > >> >> 0xffffffff80a673f1 <+17>: mov %r9,-0x38(%rbp) > >> >> 0xffffffff80a673f5 <+21>: mov %r8,-0x40(%rbp) > >> >> 0xffffffff80a673f9 <+25>: mov %rcx,-0x48(%rbp) > >> >> 0xffffffff80a673fd <+29>: mov %rdx,-0x50(%rbp) > >> >> 0xffffffff80a67401 <+33>: lea -0x60(%rbp),%rax > >> >> 0xffffffff80a67405 <+37>: mov %rax,-0x20(%rbp) > >> >> 0xffffffff80a67409 <+41>: lea 0x10(%rbp),%rax > >> >> 0xffffffff80a6740d <+45>: mov %rax,-0x28(%rbp) > >> >> 0xffffffff80a67411 <+49>: movl $0x30,-0x2c(%rbp) > >> >> 0xffffffff80a67418 <+56>: movl $0x10,-0x30(%rbp) > >> >> 0xffffffff80a6741f <+63>: mov $0xffffffff8137bdf8,%rdi > >> >> 0xffffffff80a67426 <+70>: mov %rbx,%rsi > >> >> 0xffffffff80a67429 <+73>: callq 0xffffffff80a66c00 <_assert_sbuf_integrity> > >> >> > >> >> > >> >> 0xffffffff80a237b9 <+825>: jmpq 0xffffffff80a236fd > >> >> 0xffffffff80a237be <+830>: mov $0xffffffff80fd8ad3,%rsi > >> >> 0xffffffff80a237c5 <+837>: xor %eax,%eax > >> >> 0xffffffff80a237c7 <+839>: mov %r12,%rdi > >> >> 0xffffffff80a237ca <+842>: mov -0x228(%rbp),%rdx > >> >> 0xffffffff80a237d1 <+849>: callq 0xffffffff80a673e0 > >> >> => 0xffffffff80a237d6 <+854>: inc %r14d > >> >> 0xffffffff80a237d9 <+857>: jmpq 0xffffffff80a236fd > >> > > >> > So maybe try 'p $r12' in the corefile_open() frame. > >> > >> #17 0xffffffff80a237d6 in corefile_open (compress=0, comm=, > >> uid=, pid=, td=, > >> vpp=, namep=) > >> at /usr/src/sys/kern/kern_sig.c:3188 > >> 3188 sbuf_printf(&sb, "%s", comm); > >> (kgdb) p $r12 > >> $1 = 0 > > > > So it's definitely zero. :( The next step is probably to disassemble the > > corefile_open function (ugh) and walk backwards to find where %r12 is read > > from. It might be from a local variable on the stack, so then you would > > want to examine that memory in the stack and the surrounding memory to see > > if there is memory corruption and perhaps if there is anything recognizable > > about it (e.g. if the corruption contains some sort of data you recognize, > > or if the corruption is bounded by a certain length, etc.). It's a bit of > > a shot in the dark though. > > > > Is this reproducible? > > No it's not. The only time it happened was when there was a swap > timeout, probably because of a lengthy deep recovery on one of the > mirrored swap devices. > > The code in question is: > struct sbuf sb; > [snip] > (void)sbuf_new(&sb, name, MAXPATHLEN, SBUF_FIXEDLEN); > [snip] > for (i = 0; format[i] != '\0'; i++) { > switch (format[i]) { > case '%': /* Format character */ > i++; > switch (format[i]) { > [snip] > case 'N': /* process name */ > sbuf_printf(&sb, "%s", comm); > break; > > > &sb is used in a bunch of places, so the compiler probably computes its > value once by adding the proper offset to the stack pointer and stashing > the result in a register. Since kern.corefile is "%N.core", the failure > is happening on the first interation of the loop, so there isn't much > opportunity for things to get corrupted. Also, the control flow in this > function only depends on the format, so there shouldn't be anything > special about a swap timeout vs. a segfault generated core. Yes, r12 is call-safe (IIRC), so I expect it only computes it once as well, but I've sometimes seen the compiler spill local vars onto the stack due to register pressure. That said, I think it is unlikely it would have to spill &sb during the early part of the function. :( > How is gdb able to print the register contents for an arbitrary stack > frame? It's not like this is a SPARC with register windows. Aren't > only the final register values when the core dump was generated saved > along with the memory contents? Unless a register contents are pushed > onto the stack, I would think that if a callee overwrites a register, > its contents are gone. My understanding is that when the compiler saves a register (e.g. on the stack during a function prologue) it also emits DWARF records that indicate where it saved each register. As the stack unwinder walks back up the stack it populates the current "register view" based on the debug info at that frame (e.g. register X is stored at address Y, register Z is gone ( in gdb parlance)). -- John Baldwin From owner-freebsd-current@freebsd.org Wed Dec 9 18:43:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0D3C9D4835 for ; Wed, 9 Dec 2015 18:43:33 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::4]) (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 E045D1B68 for ; Wed, 9 Dec 2015 18:43:33 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (localhost [127.0.0.1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPS id 838F1125EE1 for ; Wed, 9 Dec 2015 10:43:32 -0800 (PST) Received: from pop.rubicorp.com (unknown [72.34.113.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPSA id 7994F125EBA for ; Wed, 9 Dec 2015 10:43:32 -0800 (PST) Subject: [RESOLVED] LOR On AMD64 hosted by KVM hypervisor To: freebsd-current@freebsd.org References: <56673129.4090207@nomadlogic.org> From: Pete Wright Message-ID: <56687653.1090709@nomadlogic.org> Date: Wed, 9 Dec 2015 10:43:31 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56673129.4090207@nomadlogic.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 09 Dec 2015 18:43:34 -0000 Closing the loop on this for the archives - I am no longer seeing this LOR as of r291998. -pete On 12/08/15 11:36, Pete Wright wrote: > Hey All, > I am seeing a repeated LOR on r291495 that is pretty reproducible. This > happens right after the system boots: > > lock order reversal: > 1st 0xfffffe03e37fa920 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3476 > 2nd 0xfffff80024c72200 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 > stack backtrace: > #0 0xffffffff80a7b2e0 at witness_debugger+0x70 > #1 0xffffffff80a7b1e1 at witness_checkorder+0xe71 > #2 0xffffffff80a28ab2 at _sx_xlock+0x72 > #3 0xffffffff80cc0a5d at ufsdirhash_add+0x3d > #4 0xffffffff80cc390f at ufs_direnter+0x62f > #5 0xffffffff80ccccd3 at ufs_makeinode+0x5f3 > #6 0xffffffff80cc881d at ufs_create+0x2d > #7 0xffffffff80fb2ed1 at VOP_CREATE_APV+0xf1 > #8 0xffffffff80ae3568 at vn_open_cred+0x2f8 > #9 0xffffffff80adc8ec at kern_openat+0x25c > #10 0xffffffff80e6a4fe at amd64_syscall+0x2de > #11 0xffffffff80e4972b at Xfast_syscall+0xfb > > Here is the system info: > % uname -ar > FreeBSD bsd-current.trp-srd.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 > r291495: Mon Nov 30 23:14:34 UTC 2015 > root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > The server itself is a VM running under the KVM hypervisor. I am > currently rebuilding world+kernel now. The base OS image is from the > latest 11-CURRENT snapshot, and I have been able to reproduce this on > several hypervisors. > > Has anyone else seen this? > > Cheers, > -pete > > > > -- Pete Wright pete@nomadlogic.org twitter => @nomadlogicLA From owner-freebsd-current@freebsd.org Thu Dec 10 03:24:36 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87EFF9D528B; Thu, 10 Dec 2015 03:24:36 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 1F9601DC6; Thu, 10 Dec 2015 03:24:35 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190c-f79c96d00000038e-f1-5668ef3ec876 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-1.mit.edu (Symantec Messaging Gateway) with SMTP id 67.5C.00910.E3FE8665; Wed, 9 Dec 2015 22:19:26 -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 tBA3JPAM026925; Wed, 9 Dec 2015 22:19:26 -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 tBA3JLUQ007465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Dec 2015 22:19:25 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tBA3JL0N021673; Wed, 9 Dec 2015 22:19:21 -0500 (EST) Date: Wed, 9 Dec 2015 22:19:20 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: call for 2015Q4 quarterly status reports Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJIsWRmVeSWpSXmKPExsUixG6nrmv3PiPMYG6XssWcNx+YLLZv/sfo wOQx49N8lgDGKC6blNSczLLUIn27BK6Ms8ePsBdc4Ko42ODQwPiao4uRg0NCwETiZqdqFyMn kCkmceHeerYuRi4OIYHFTBLb/55khHA2MEq8n/gByjnIJLFx/zkWkBYhgXqJszdXMoLYLAJa ErOuL2EHsdkE1CTWr7jGDDFWUWLzqUlgtoiAvMS+pvdgNcxA9pbVk9lAbGEBQ4nuD/eYQS7i FXCUuL2iFCQsKqAjsXr/FLBVvAKCEidnPmGBaNWSWD59G8sERoFZSFKzkKQWMDKtYpRNya3S zU3MzClOTdYtTk7My0st0jXUy80s0UtNKd3ECApBTkmeHYxvDiodYhTgYFTi4b3gkh4mxJpY VlyZe4hRkoNJSZR309OMMCG+pPyUyozE4oz4otKc1OJDjBIczEoivMzPgXK8KYmVValF+TAp aQ4WJXHeuV98w4QE0hNLUrNTUwtSi2CyMhwcShK8f94CNQoWpaanVqRl5pQgpJk4OEGG8wAN 5wep4S0uSMwtzkyHyJ9iVJQS5/0HkhAASWSU5sH1glPEbibVV4ziQK8I8+q/A6riAaYXuO5X QIOZgAZ/uZIOMrgkESEl1cDoI1i9dMnST7EXF27J2LtplbJOAdfOjt2HVDonnPPZ+nfHned8 TDezs3p2XXmf/6ZhWuZxk4OXF7Kr7bq5cCf7raMpxUvlNv+44inK5SAVvjZDv1Bu4a/5dxau jX2gUnxnlkyK6Bc/hWVG76Z6WvaYX8qacG/14ROHbbr2ex+5Xhfv/H6+ziUOEyWW4oxEQy3m ouJEAFMNv0/sAgAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 03:24:36 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is January 7, 2016, for work done in October through December. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly at freebsd.org . There is also an XML template [2] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We are looking forward to all of your 2015Q4 reports! Thanks, Ben (on behalf of monthly@) [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2015-04-2015-06.html [5] http://www.freebsd.org/news/status/report-2015-07-2015-09.html From owner-freebsd-current@freebsd.org Thu Dec 10 09:20:15 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09DE99D62AF; Thu, 10 Dec 2015 09:20:15 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 C3D681F09; Thu, 10 Dec 2015 09:20:14 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id c201so22911594wme.0; Thu, 10 Dec 2015 01:20:14 -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=kDLflrP2DGYCOAKYh6KF9olgRBB9gtavhK2LPd/6dnM=; b=FS8kT8l0F7qiYeCrL6TTdGOKzEI2LMK50+b2fe014aqiHAlmyATiLOV4Ay8e3u9DSu 2oWiwsemC+kkwK40z06ob4HGjdGAbIC/nFjY+uVEwPgshbMIAsAHlFCgxcIo02r192UQ p+Kaswb4/n4e2J1pWOgPNciGhOGt0QEXc/lF3EHNqiAeZOHzbKFDEzzsxpFbiMpCqvM/ bOtJjprDJvQb1+wNumItE92Rxv+rEtFZ/uwAtS4wKF4HihGJvxe9f53dGTmJbCiDt+4H SVQfidSabwTySxXJodb+tBy7oNa7KsWujjZqI0vZJbESNCSjW8AJqj8BM4qUev4zoXxo 72Gg== MIME-Version: 1.0 X-Received: by 10.28.100.84 with SMTP id y81mr17918428wmb.48.1449739213238; Thu, 10 Dec 2015 01:20:13 -0800 (PST) Received: by 10.28.181.213 with HTTP; Thu, 10 Dec 2015 01:20:13 -0800 (PST) Date: Thu, 10 Dec 2015 09:20:13 +0000 Message-ID: Subject: ZFSROOT UEFI boot From: krad To: freebsd-current@freebsd.org, FreeBSD Questions X-Mailman-Approved-At: Thu, 10 Dec 2015 12:17:50 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 09:20:15 -0000 Hi, I need to get one of my machines converted over from bios GPT zfsroot boot to efi. I know you can boot freebsd under EFI with a ufs kernel but this isnt the route i want. There are patches under test for EFI zfs root. However when I read the thread it was unclear which version of these patches were needed and where to get them. Does anyone know where they are, if there are any prebuilt zfsloader etc binaries, or if the patches have made it to head yet? Also does anyone have any pointers or good experience with grub efi and zfs on root? I'm considering this option as it would make booting into specific boot environments easier From owner-freebsd-current@freebsd.org Thu Dec 10 12:41:19 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42DB79D7F95 for ; Thu, 10 Dec 2015 12:41:19 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 D34D8106F for ; Thu, 10 Dec 2015 12:41:18 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by wmww144 with SMTP id w144so22946553wmw.0 for ; Thu, 10 Dec 2015 04:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-type; bh=KIBOdA4iANz+WGYnw1xeYPdMIIXj/+IPuMKGgdGZtZo=; b=lJjFhOxJGnkFboqwgR2r4pT3Zes8MPFTQp8P0hcrZVh1jwglaN86fEhX9syo8NJdLz IBSYYEPu7SvXTLBVv9L9Xfo6jap6wWzOARZDwmZ/17M0ZJMbjpOYc0IzWYbe1/jM/zrV fXI2luYJNnkLTyXFxGsdjUc2rtMHib7+vFldk09RvHczcsAtoqEYJnmOjBff6CEKkKCI vsx6mHczcJQ8MpTpoPPLGCmB9mRfVAGAj6GlMMjv9RJBoRUPqfszSRxiw2tIKlgUrFCl xW9oS2gkfueSW86kB/hF8HT+5mCcSzYNbhY+Fc1wWQ/5uEJ+cdSB2NZyvyCCnotpJXv4 g+Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-type; bh=KIBOdA4iANz+WGYnw1xeYPdMIIXj/+IPuMKGgdGZtZo=; b=GISshKg4SXSyGAdvm7nJRc7oU2ZGHynL4ZmECMbGtFEnpV548CQH0fNweGY2lrTLz2 2nMeUgyvozucNQxcFNp2FWx14r8GNO4PZrDCebJxK4rAFMFCsAmBCyVPX9hRJZ1UrWrj KKhA9F6e8LWyt8OUT3srKq7iLhhG+zfn7Y9VbK1+MLM5aW9s3M3kCk4rWzjbojxk/1dH Akm0PmRRywkSkmHlo+5hUysFbM9t6WFhtfTlFnYI46c/QJk+kpiNJxTpBTlw2g1XNPJt 9082mh31qbdnj1wmdxrvWi87nb7HhXMATfQjQeuraT3/NJaWX6Q28todiT/lTBmk9Rl1 f3+w== X-Gm-Message-State: ALoCoQkLJRWL2n/gd6cqSYnDPHe8iUGclsVZ8qaiZ7C3cf7EHHaScj9REX2ObSmQ3FSbr3dub3Kjw4EnegBJq9WTTphbpzl6QQ+tvq/04uYcgDUiS1s7vGM= X-Received: by 10.194.243.6 with SMTP id wu6mr12397354wjc.14.1449751276791; Thu, 10 Dec 2015 04:41:16 -0800 (PST) From: Steven Hartland Mime-Version: 1.0 (1.0) References: In-Reply-To: Date: Thu, 10 Dec 2015 12:41:15 +0000 Message-ID: <8991747525093115430@unknownmsgid> Subject: Re: ZFSROOT UEFI boot To: krad Cc: "freebsd-current@freebsd.org" , FreeBSD Questions X-Mailman-Approved-At: Thu, 10 Dec 2015 13:07:15 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 12:41:19 -0000 Ive literally just got this working on 10.2 after working on the code posted on the review which you can find here: https://reviews.freebsd.org/D4104 If you're happy running current then the patch file I linked in my comment should apply cleanly and just work. If you want 10.x then there's quite a bit more needed. As I said I do have this working so can post patches when I'm back in the office. Either way once applied a standard efi install just works. Essentially create efi partition and use gpart to install the efi bootcode and away you go. I've just used this with a custom mfsbsd iso to perform and 10.2-RELEASE ZFS boot install on some Intel nvme disks setup as raidz2, which only support efi boot. On 10 Dec 2015, at 12:18, krad wrote: Hi, I need to get one of my machines converted over from bios GPT zfsroot boot to efi. I know you can boot freebsd under EFI with a ufs kernel but this isnt the route i want. There are patches under test for EFI zfs root. However when I read the thread it was unclear which version of these patches were needed and where to get them. Does anyone know where they are, if there are any prebuilt zfsloader etc binaries, or if the patches have made it to head yet? Also does anyone have any pointers or good experience with grub efi and zfs on root? I'm considering this option as it would make booting into specific boot environments easier _______________________________________________ freebsd-current@freebsd.org mailing list https://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 Dec 10 13:37:23 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D87B9D68CA for ; Thu, 10 Dec 2015 13:37:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 22F6C1ED1 for ; Thu, 10 Dec 2015 13:37:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:MDjsfxycVjpwYJjXCy+O+j09IxM/srCxBDY+r6Qd0ewSIJqq85mqBkHD//Il1AaPBtWFrasbwLeP+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStCU1pv8irn60qaQSjsLrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGwD884mosBaXKjwZKh9RqFCFjkgLyhh6tfmuBPYQU6E+2EGX2MKuhRSDgXP9x28WY3+5HjUrO14jRObNs6+aLk/WjCv6u8/UhrhgyQDOjsR7WbYl8F0lKIdqxv39E83+JLdfIzAbKk2RajaZ95PHWc= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2B5AgCEf2lW/61jaINehQG9NA6BYoYOAoFnFAEBAQEBAQEBgQmCLYIOIwRkATEHEgIEVQIELogUnWqPcJIhAQEIAQEBAQEBARMJhlaFTxaDQhEBBhYZFiKCToFJBY0xdohIgmiMNpc7g3ECHwFDghEdgXQghE06gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,408,1444708800"; d="scan'208";a="256890408" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 10 Dec 2015 08:37:20 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 9B1E415F56D for ; Thu, 10 Dec 2015 08:37:20 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id fTJEnM9H_qy1 for ; Thu, 10 Dec 2015 08:37:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id A953715F571 for ; Thu, 10 Dec 2015 08:37:19 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id okSnQxTGiemQ for ; Thu, 10 Dec 2015 08:37:19 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 8A7BE15F56D for ; Thu, 10 Dec 2015 08:37:19 -0500 (EST) Date: Thu, 10 Dec 2015 08:37:19 -0500 (EST) From: Rick Macklem To: freebsd-current Message-ID: <521574245.126601980.1449754639530.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <1544725253.126601939.1449754636170.JavaMail.zimbra@uoguelph.ca> Subject: RPC request sent to 127.0.0.1 becomes from other IP on machine MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_126601978_687480826.1449754639528" X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: RPC request sent to 127.0.0.1 becomes from other IP on machine Thread-Index: aD3Cg3fYPJhHwGOVwQfb2MxClb5vVQ== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 13:37:23 -0000 ------=_Part_126601978_687480826.1449754639528 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Mark has reported a problem via email where the nfsuserd daemon sees requests coming from an IP# assigned to the machine instead of 127.0.0.1. Here's a snippet from his message: Ok, I have Plex in a jail and when I scan the remote NFS file share the *local* server's nfsuserd spams the logs. Spamming the logs refers to the messages nfsuserd generates when it gets a request from an address other than 127.0.0.1. I think the best solution is to switch nfsuserd over to using an AF_LOCAL socket like the gssd uses, but that will take a little coding and probably won't be MFCable. I've sent him the attached patch to try as a workaround. Does anyone happen to know under what circumstances the address 127.0.0.1 gets replaced? And do you know if it will always be replaced with the same address? (I'm basically wondering if the workaround needs to be a list of IP addresses instead of a single address?) Thanks in advance for any help with this, rick ------=_Part_126601978_687480826.1449754639528 Content-Type: text/x-patch; name=nfsuserd-fromip.patch Content-Disposition: attachment; filename=nfsuserd-fromip.patch Content-Transfer-Encoding: base64 LS0tIG5mc3VzZXJkLmMuc2F2CTIwMTUtMTItMDkgMTg6NDY6MjkuMjg0OTcyMDAwIC0wNTAwCisr KyBuZnN1c2VyZC5jCTIwMTUtMTItMDkgMTg6NTk6MzMuNTY0NDk4MDAwIC0wNTAwCkBAIC00MCw2 ICs0MCwxMCBAQCBfX0ZCU0RJRCgiJEZyZWVCU0Q6IGhlYWQvdXNyLnNiaW4vbmZzdXNlCiAjaW5j bHVkZSA8c3lzL3Zub2RlLmg+CiAjaW5jbHVkZSA8c3lzL3dhaXQuaD4KIAorI2luY2x1ZGUgPG5l dGluZXQvaW4uaD4KKworI2luY2x1ZGUgPGFycGEvaW5ldC5oPgorCiAjaW5jbHVkZSA8bmZzL25m c3N2Yy5oPgogCiAjaW5jbHVkZSA8cnBjL3JwYy5oPgpAQCAtOTQsNiArOTgsNyBAQCBnaWRfdCBk ZWZhdWx0Z2lkID0gKGdpZF90KTMyNzY3OwogaW50IHZlcmJvc2UgPSAwLCBpbV9hX3NsYXZlID0g MCwgbmZzdXNlcmRjbnQgPSAtMSwgZm9yY2VzdGFydCA9IDA7CiBpbnQgZGVmdXNlcnRpbWVvdXQg PSBERUZVU0VSVElNRU9VVCwgbWFuYWdlX2dpZHMgPSAwOwogcGlkX3Qgc2xhdmVzW01BWE5GU1VT RVJEXTsKK3N0cnVjdCBpbl9hZGRyIGZyb21pcDsKIAogaW50CiBtYWluKGludCBhcmdjLCBjaGFy ICphcmd2W10pCkBAIC0xNDQsNiArMTQ5LDcgQEAgbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltd KQogCQkJfQogCQl9CiAJfQorCWZyb21pcC5zX2FkZHIgPSBpbmV0X2FkZHIoIjEyNy4wLjAuMSIp OwogCW5pZC5uaWRfdXNlcm1heCA9IERFRlVTRVJNQVg7CiAJbmlkLm5pZF91c2VydGltZW91dCA9 IGRlZnVzZXJ0aW1lb3V0OwogCkBAIC0xOTAsNiArMTk2LDE1IEBAIG1haW4oaW50IGFyZ2MsIGNo YXIgKmFyZ3ZbXSkKIAkJCQl1c2FnZSgpOwogCQkJfQogCQkJbmlkLm5pZF91c2VydGltZW91dCA9 IGRlZnVzZXJ0aW1lb3V0ID0gaSAqIDYwOworCQl9IGVsc2UgaWYgKCFzdHJjbXAoKmFyZ3YsICIt ZnJvbWlwIikpIHsKKwkJCWlmIChhcmdjID09IDEpCisJCQkJdXNhZ2UoKTsKKwkJCWFyZ2MtLTsK KwkJCWFyZ3YrKzsKKwkJCWlmIChpbmV0X2F0b24oKmFyZ3YsICZmcm9taXApID09IDApIHsKKwkJ CQlmcHJpbnRmKHN0ZGVyciwgIkJhZCAtZnJvbWlwICVzXG4iLCAqYXJndik7CisJCQkJdXNhZ2Uo KTsKKwkJCX0KIAkJfSBlbHNlIGlmIChuZnN1c2VyZGNudCA9PSAtMSkgewogCQkJbmZzdXNlcmRj bnQgPSBhdG9pKCphcmd2KTsKIAkJCWlmIChuZnN1c2VyZGNudCA8IDEpCkBAIC00NTgsMjIgKzQ3 MywyMiBAQCBuZnN1c2VyZHNydihzdHJ1Y3Qgc3ZjX3JlcSAqcnFzdHAsIFNWQ1hQCiAJdV9zaG9y dCBzcG9ydDsKIAlzdHJ1Y3QgaW5mbyBpbmZvOwogCXN0cnVjdCBuZnNkX2lkYXJncyBuaWQ7Ci0J dV9pbnQzMl90IHNhZGRyOwogCWdpZF90IGdycHNbTkdST1VQU107CiAJaW50IG5ncm91cDsKIAog CS8qCi0JICogT25seSBoYW5kbGUgcmVxdWVzdHMgZnJvbSAxMjcuMC4wLjEgb24gYSByZXNlcnZl ZCBwb3J0IG51bWJlci4KKwkgKiBPbmx5IGhhbmRsZSByZXF1ZXN0cyBmcm9tIDEyNy4wLjAuMSBv biBhIHJlc2VydmVkIHBvcnQgbnVtYmVyLAorCSAqIHVubGVzcyB0aGUgIi1mcm9taXAiIHNwZWNp ZmllZCBhIGRpZmZlcmVudCBhZGRyZXNzLgogCSAqIChTaW5jZSBhIHJlc2VydmVkIHBvcnQgIyBh dCBsb2NhbGhvc3QgaW1wbGllcyBhIGNsaWVudCB3aXRoCiAJICogIGxvY2FsIHJvb3QsIHRoZXJl IHdvbid0IGJlIGEgc2VjdXJpdHkgYnJlYWNoLiBUaGlzIGlzIGFib3V0CiAJICogIHRoZSBvbmx5 IGNhc2UgSSBjYW4gdGhpbmsgb2Ygd2hlcmUgYSByZXNlcnZlZCBwb3J0ICMgbWVhbnMKIAkgKiAg c29tZXRoaW5nLikKIAkgKi8KIAlzcG9ydCA9IG50b2hzKHRyYW5zcC0+eHBfcmFkZHIuc2luX3Bv cnQpOwotCXNhZGRyID0gbnRvaGwodHJhbnNwLT54cF9yYWRkci5zaW5fYWRkci5zX2FkZHIpOwog CWlmICgocnFzdHAtPnJxX3Byb2MgIT0gTlVMTFBST0MgJiYgc3BvcnQgPj0gSVBQT1JUX1JFU0VS VkVEKSB8fAotCSAgICBzYWRkciAhPSAweDdmMDAwMDAxKSB7Ci0JCXN5c2xvZyhMT0dfRVJSLCAi cmVxIGZyb20gaXA9MHgleCBwb3J0PSVkXG4iLCBzYWRkciwgc3BvcnQpOworCSAgICB0cmFuc3At PnhwX3JhZGRyLnNpbl9hZGRyLnNfYWRkciAhPSBmcm9taXAuc19hZGRyKSB7CisJCXN5c2xvZyhM T0dfRVJSLCAicmVxIGZyb20gaXA9JXMgcG9ydD0lZFxuIiwKKwkJICAgIGluZXRfbnRvYSh0cmFu c3AtPnhwX3JhZGRyLnNpbl9hZGRyKSwgc3BvcnQpOwogCQlzdmNlcnJfd2Vha2F1dGgodHJhbnNw KTsKIAkJcmV0dXJuOwogCX0KQEAgLTcyMSw1ICs3MzYsNSBAQCB1c2FnZSh2b2lkKQogewogCiAJ ZXJyeCgxLAotCSAgICAidXNhZ2U6IG5mc3VzZXJkIFstdXNlcm1heCBjYWNoZV9zaXplXSBbLXVz ZXJ0aW1lb3V0IG1pbnV0ZXNdIFstdmVyYm9zZV0gWy1tYW5hZ2UtZ2lkc10gWy1kb21haW4gZG9t YWluX25hbWVdIFtuXSIpOworCSAgICAidXNhZ2U6IG5mc3VzZXJkIFstdXNlcm1heCBjYWNoZV9z aXplXSBbLXVzZXJ0aW1lb3V0IG1pbnV0ZXNdIFstdmVyYm9zZV0gWy1tYW5hZ2UtZ2lkc10gWy1k b21haW4gZG9tYWluX25hbWVdIFstZnJvbWlwIHh4Lnh4Lnh4Lnh4XSBbbl0iKTsKIH0KLS0tIG5m c3VzZXJkLjguc2F2CTIwMTUtMTItMDkgMTk6MTM6NDguMTczODEyMDAwIC0wNTAwCisrKyBuZnN1 c2VyZC44CTIwMTUtMTItMDkgMTk6MTk6MzguNTIyNTE2MDAwIC0wNTAwCkBAIC0yNCw3ICsyNCw3 IEBACiAuXCIKIC5cIiAkRnJlZUJTRDogaGVhZC91c3Iuc2Jpbi9uZnN1c2VyZC9uZnN1c2VyZC44 IDI3NjI1OCAyMDE0LTEyLTI2IDIxOjU2OjIzWiBqb2VsICQKIC5cIgotLkRkIE5vdmVtYmVyIDEs IDIwMTUKKy5EZCBEZWNlbWJlciA5LCAyMDE1CiAuRHQgTkZTVVNFUkQgOAogLk9zCiAuU2ggTkFN RQpAQCAtMzcsNiArMzcsNyBAQCBzZXJ2aWNlcyBwbHVzIHN1cHBvcnQgbWFuYWdlLWdpZHMgZm9y IGFsCiAuT3AgRmwgZG9tYWluIEFyIGRvbWFpbl9uYW1lCiAuT3AgRmwgdXNlcnRpbWVvdXQgQXIg bWludXRlcwogLk9wIEZsIHVzZXJtYXggQXIgbWF4X2NhY2hlX3NpemUKKy5PcCBGbCBmcm9taXAg QXIgaXBfYWRkcmVzcwogLk9wIEZsIHZlcmJvc2UKIC5PcCBGbCBmb3JjZQogLk9wIEZsIG1hbmFn ZS1naWRzCkBAIC03Niw2ICs3NywyMSBAQCB0aGUgbW9yZSBrZXJuZWwgbWVtb3J5IGlzIHVzZWQs IGJ1dCB0aGUgCiBzeXN0ZW0gY2FuIGFmZm9yZCB0aGUgbWVtb3J5IHVzZSwgbWFrZSB0aGlzIHRo ZSBzdW0gb2YgdGhlIG51bWJlciBvZgogZW50cmllcyBpbiB5b3VyIGdyb3VwIGFuZCBwYXNzd29y ZCBkYXRhYmFzZXMuCiBUaGUgZGVmYXVsdCBpcyAyMDAgZW50cmllcy4KKy5JdCBGbCBmcm9taXAg QXIgaXBfYWRkcmVzcworVGhpcyBvdmVycmlkZXMgdGhlIGRlZmF1bHQgdXBjYWxsIGZyb20gYWRk cmVzcyBvZiAxMjcuMC4wLjEuCitBbHRob3VnaCB0aGUgdXBjYWxsIGNvbm5lY3Rpb24gaXMgZG9u ZSB0byAxMjcuMC4wLjEsIHNvbWUgbmV0d29yaworY29uZmlndXJhdGlvbnMgd2lsbCByZXN1bHQg aW4gYW5vdGhlciBJUCBhZGRyZXNzIGFzc2lnbmVkIHRvIHRoZSBtYWNoaW5lCithcyB0aGUgZnJv bSBhZGRyZXNzLgorSWYgeW91IGdldCBzeXNsb2cgbWVzc2FnZXMgbGlrZToKKy5zcAorLm5mCitE ZWMgIDkgMTk6MDM6MjAgbmZzdjQtbGFwdG9wIG5mc3VzZXJkOls1MDZdOiByZXEgZnJvbSBpcD0x MzEuMTA0LjQ4LjE3IHBvcnQ9ODYxCisuZmkKKy5zcAordGhlbiB5b3Ugc2hvdWxkIHVzZSB0aGlz IG9wdGlvbiB0byBzZXQgdGhlIGZyb20gSVAgYWRkcmVzcyB0byB0aGUgb25lIGluCit0aGUgbWVz c2FnZS4KK09ubHkgZG8gdGhpcyBmb3IgSVAgYWRkcmVzc2VzIGFzc2lnbmVkIHRvIHRoZSBtYWNo aW5lIHRoaXMgZGFlbW9uIGlzIHJ1bm5pbmcKK29uLgogLkl0IEZsIHZlcmJvc2UKIFdoZW4gc2V0 LCB0aGUgc2VydmVyIGxvZ3MgYSBidW5jaCBvZiBpbmZvcm1hdGlvbiB0byBzeXNsb2cuCiAuSXQg RmwgZm9yY2UK ------=_Part_126601978_687480826.1449754639528-- From owner-freebsd-current@freebsd.org Thu Dec 10 14:32:41 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BD1C9D7411 for ; Thu, 10 Dec 2015 14:32:41 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 179B91811 for ; Thu, 10 Dec 2015 14:32:40 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by vkay187 with SMTP id y187so83897684vka.3 for ; Thu, 10 Dec 2015 06:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1er81mBhAWfdN9gi/7AZrSk6xx4O+XTjEzxop4zMNgM=; b=zHRBrrtyC2suw43Gtez5EyhQN+YNyvPgiEYP1cl4NgUcjUKy0su5XZ4aKMesvIfy63 40XB/Dh6Aq3a6bmocsmahmx3J3Q9jVt6EOrFBqDtXAXuNzjhHAI6sxdCDi/5y6pJlir8 oOGgwnCpne2fx6rSfT/jLytHEWnEYcV+HE3CCAjxaAdvILD+epfHxNGbtdHWmRRiwVuy zHnVaatUZBdUGd0Kgz/KlJTpZAd6/2JpIOD4qd8uoqP5MXORs3f0AKXDpgk7tyIlT45m TNRCobi4dzh6mk8pyXFY2s/yHyiJElk0/4MYtpOK1uSmIauDmdku/X+i52/HuAqeDe6h Zxtw== 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:date :message-id:subject:from:to:cc:content-type; bh=1er81mBhAWfdN9gi/7AZrSk6xx4O+XTjEzxop4zMNgM=; b=apr51y275PfTaHn8mqmvBPv8CfeQVmndeR6CTQvuMjh7l5WDM35srhF442zgGJ9Orh DWsaQGb6ECFwek7nE+9QjeCxyTonc8QqczAJC+MaQxHCY1UF5n97SCGNxH71Cg0VRyee DEYKgVz3KPBrTLL6dYTjh58EgfCukpjZ52DE6q4XhSrqb0DlWp+nVpdV+ze7QJPgdDzS V+DTuto23gTrFRXbpMiu5gxeCBN6xtnOPNxahaMYqJxMc2EpBIwMCSw3aV+KXs7Ny+Ca gmRR/QM2LwlYWdGbMQVVzNrQ9VlvamVZ6IvRV4LtjzndE7IKGC5oFiufsg1suCRFK81K 9b0A== X-Gm-Message-State: ALoCoQlfZIiVyDIBMfzWAv2qbwncBQk+ZTE1C2vh71PgN7Lv8m2QMWNp9nUmraCWT6J5bnpvvowbywLmPwmHmdT+WmUgFujctg== MIME-Version: 1.0 X-Received: by 10.129.80.138 with SMTP id e132mr4840869ywb.90.1449757959856; Thu, 10 Dec 2015 06:32:39 -0800 (PST) Received: by 10.37.209.216 with HTTP; Thu, 10 Dec 2015 06:32:39 -0800 (PST) In-Reply-To: <521574245.126601980.1449754639530.JavaMail.zimbra@uoguelph.ca> References: <1544725253.126601939.1449754636170.JavaMail.zimbra@uoguelph.ca> <521574245.126601980.1449754639530.JavaMail.zimbra@uoguelph.ca> Date: Thu, 10 Dec 2015 14:32:39 +0000 Message-ID: Subject: Re: RPC request sent to 127.0.0.1 becomes from other IP on machine From: Doug Rabson To: Rick Macklem Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 14:32:41 -0000 I think a local socket is probably the best solution long term. Using a local socket also allows using filesystem permissions to control access which is required for gssd but not necessarily for nfsuserd. On 10 December 2015 at 13:37, Rick Macklem wrote: > Hi, > > Mark has reported a problem via email where the nfsuserd daemon sees > requests coming from an IP# assigned to the machine instead of 127.0.0.1. > Here's a snippet from his message: > Ok, I have Plex in a jail and when I scan the remote NFS file share the > *local* server's nfsuserd spams the logs. > Spamming the logs refers to the messages nfsuserd generates when it gets > a request from an address other than 127.0.0.1. > > I think the best solution is to switch nfsuserd over to using an AF_LOCAL > socket like the gssd uses, but that will take a little coding and probably > won't be MFCable. > > I've sent him the attached patch to try as a workaround. > > Does anyone happen to know under what circumstances the address 127.0.0.1 > gets replaced? > > And do you know if it will always be replaced with the same > address? > (I'm basically wondering if the workaround needs to be a list of IP > addresses > instead of a single address?) > > Thanks in advance for any help with this, rick > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Dec 10 14:37:27 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D22549D76A3 for ; Thu, 10 Dec 2015 14:37:27 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 AC1FE1B39 for ; Thu, 10 Dec 2015 14:37:27 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B790A214E7 for ; Thu, 10 Dec 2015 09:37:25 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Thu, 10 Dec 2015 09:37:25 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=vCuFWSczjer8x9V E7xNhNU9gZJA=; b=UOLIwOgUt6YPMsnql1BZiGVnPcD1YW8+LtsyGkWDSJXIkVh YVMhSxobcwCvQkWhjK3Mv2P12XlTl8OSriISAqDC1hwL/lAivr4c+z21+IupBsCH H2MhvJY/coll+XKhZufIF6yMk+AeHE9Q+AnXpV7WhHqNubJFAq0RPsEv9a9o= Received: by web3.nyi.internal (Postfix, from userid 99) id 91A23107863; Thu, 10 Dec 2015 09:37:25 -0500 (EST) Message-Id: <1449758245.1775185.463651697.2CDBB08E@webmail.messagingengine.com> X-Sasl-Enc: ap1tuBRHRVOoKyROTQ9yGw7HizCJIuP1iqZunHhQSSou 1449758245 From: Mark Felder To: Rick Macklem , "freebsd-current" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-5c8c9c89 In-Reply-To: <521574245.126601980.1449754639530.JavaMail.zimbra@uoguelph.ca> References: <521574245.126601980.1449754639530.JavaMail.zimbra@uoguelph.ca> Subject: Re: RPC request sent to 127.0.0.1 becomes from other IP on machine Date: Thu, 10 Dec 2015 08:37:25 -0600 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 14:37:27 -0000 On Thu, Dec 10, 2015, at 07:37, Rick Macklem wrote: > Hi, > > Mark has reported a problem via email where the nfsuserd daemon sees > requests coming from an IP# assigned to the machine instead of 127.0.0.1. > Here's a snippet from his message: > Ok, I have Plex in a jail and when I scan the remote NFS file share the > *local* server's nfsuserd spams the logs. > Spamming the logs refers to the messages nfsuserd generates when it gets > a request from an address other than 127.0.0.1. > > I think the best solution is to switch nfsuserd over to using an AF_LOCAL > socket like the gssd uses, but that will take a little coding and > probably > won't be MFCable. > > I've sent him the attached patch to try as a workaround. > > Does anyone happen to know under what circumstances the address 127.0.0.1 > gets replaced? > > And do you know if it will always be replaced with the same > address? > (I'm basically wondering if the workaround needs to be a list of IP > addresses > instead of a single address?) > > Thanks in advance for any help with this, rick > I've opened a PR per your request https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205193 -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-current@freebsd.org Thu Dec 10 15:11:28 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE7AD9D6F15; Thu, 10 Dec 2015 15:11:27 +0000 (UTC) (envelope-from hps@selasky.org) 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 9BCC010AA; Thu, 10 Dec 2015 15:11:27 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (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 88AD61FE023; Thu, 10 Dec 2015 16:11:18 +0100 (CET) Subject: Re: panic in arptimer in r289937 To: "Alexander V. Chernikov" , Adrian Chadd References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org> Cc: FreeBSD Net , freebsd-current , Randall Stewart From: Hans Petter Selasky Message-ID: <56699683.5030203@selasky.org> Date: Thu, 10 Dec 2015 16:13:07 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5661EF10.8060300@selasky.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 15:11:28 -0000 Hi, Here is the backtrace for a reproducable panic seen with arptimer(): > #0 doadump (textdump=0) at pcpu.h:221 > #1 0xffffffff80385afb in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/img/freebsd/sys/ddb/db_command.c:533 > #2 0xffffffff803858ee in db_command (cmd_table=0x0) at /usr/img/freebsd/sys/ddb/db_command.c:440 > #3 0xffffffff80385684 in db_command_loop () at /usr/img/freebsd/sys/ddb/db_command.c:493 > #4 0xffffffff8038818b in db_trap (type=, code=0) at /usr/img/freebsd/sys/ddb/db_main.c:251 > #5 0xffffffff80ae0973 in kdb_trap (type=12, code=0, tf=) at /usr/img/freebsd/sys/kern/subr_kdb.c:654 > #6 0xffffffff80f276f1 in trap_fatal (frame=0xfffffe00f59f4950, eva=) at /usr/img/freebsd/sys/amd64/amd64/trap.c:829 > #7 0xffffffff80f27924 in trap_pfault (frame=0xfffffe00f59f4950, usermode=) at /usr/img/freebsd/sys/amd64/amd64/trap.c:684 > #8 0xffffffff80f270de in trap (frame=0xfffffe00f59f4950) at /usr/img/freebsd/sys/amd64/amd64/trap.c:435 > #9 0xffffffff80f0a347 in calltrap () at /usr/img/freebsd/sys/amd64/amd64/exception.S:234 > #10 0xffffffff80be9e3d in arptimer (arg=0xfffff8011d0fda00) at atomic.h:184 > #11 0xffffffff80ab54f1 in softclock_call_cc (c=0xfffff8011d0fdaa8, cc=0xffffffff81ccd600, direct=) > at /usr/img/freebsd/sys/kern/kern_timeout.c:832 > #12 0xffffffff80ab5814 in softclock (arg=0xffffffff81ccd600) at /usr/img/freebsd/sys/kern/kern_timeout.c:921 > #13 0xffffffff80a5d7f6 in intr_event_execute_handlers (p=, ie=0xfffff80003998b00) at /usr/img/freebsd/sys/kern/kern_intr.c:1262 > #14 0xffffffff80a5de06 in ithread_loop (arg=0xfffff8000396cde0) at /usr/img/freebsd/sys/kern/kern_intr.c:1275 > #15 0xffffffff80a5a87c in fork_exit (callout=0xffffffff80a5dd60 , arg=0xfffff8000396cde0, frame=0xfffffe00f59f4c00) > at /usr/img/freebsd/sys/kern/kern_fork.c:1011 > #16 0xffffffff80f0a87e in fork_trampoline () at /usr/img/freebsd/sys/amd64/amd64/exception.S:609 > #17 0x0000000000000000 in ?? () (kgdb) print ((struct llentry *)arg)[0] $5 = { lle_next = { le_next = 0x0, le_prev = 0xfffff80069b5fa98 }, r_l3addr = { addr4 = { s_addr = 1563742475 }, addr6 = { __u6_addr = { __u6_addr8 = 0xfffff8011d0fda10 "\v�4]", __u6_addr16 = 0xfffff8011d0fda10, __u6_addr32 = 0xfffff8011d0fda10 } } }, ll_addr = { mac_aligned = 121984137371108, mac16 = 0xfffff8011d0fda20, mac8 = 0xfffff8011d0fda20 "�\035-��n" }, r_flags = 1, r_skip_req = 1, spare1 = 0, lle_tbl = 0xfffff80005653300, lle_head = 0xfffff80069b5fa98, lle_free = 0xffffffff80bf2270 , la_hold = 0x0, la_numheld = 0, la_expire = 12422, la_flags = 1, la_asked = 0, la_preempt = 5, ln_state = 2, ln_router = 0, ln_ntick = 0, lle_refcnt = 1, lle_chain = { le_next = 0x0, le_prev = 0x0 }, lle_timer = { c_links = { le = { le_next = 0x0, le_prev = 0xffffffff81ccd718 }, sle = { sle_next = 0x0 }, tqe = { tqe_next = 0x0, tqe_prev = 0xffffffff81ccd718 } }, c_time = 53354272998546, c_precision = 268435437, c_arg = 0xfffff8011d0fda00, c_func = 0xffffffff80be9950 , c_lock = 0x0, c_flags = 16, c_cpu = 0 }, lle_lock = { lock_object = { lo_name = 0xffffffff8144abf0 "lle", lo_flags = 90374144, lo_data = 0, lo_witness = 0x0 }, rw_lock = 1 }, req_mtx = { lock_object = { lo_name = 0xffffffff8144abf4 "lle req", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0 }, mtx_lock = 4 } } (kgdb) print /x ((struct llentry *)arg)->lle_tbl[0] $6 = { llt_link = { sle_next = 0xfffff8004be51900 }, llt_af = 0x1d243aa0, llt_hsize = 0xfffff801, lle_head = 0xfffff800053e5330, llt_ifp = 0xd04, llt_lookup = 0x0, llt_alloc_entry = 0xfffffe0001a472f0, llt_delete_entry = 0xfffff800504a5100, llt_prefix_free = 0xfffff800503d8c88, llt_dump_entry = 0x0, llt_hash = 0x0, llt_match_prefix = 0x0, llt_free_entry = 0x0, llt_foreach_entry = 0x0, llt_link_entry = 0x0, llt_unlink_entry = 0x38e425e, llt_fill_sa_entry = 0x0, llt_free_tbl = 0xfffff8011d243ab0 } It appears arptimer() was called after lltable_unlink_entry() was called, because la_flags does not have the LLE_LINKED bit set, which can happen!! If arptimer() is firing exactly when we call lltable_unlink_entry(), then arptimer() will refer to freed memory. Does the following patch make sense? > Index: netinet/if_ether.c > =================================================================== > --- netinet/if_ether.c (revision 291256) > +++ netinet/if_ether.c (working copy) > @@ -185,7 +185,13 @@ > LLE_WUNLOCK(lle); > return; > } > - ifp = lle->lle_tbl->llt_ifp; > + if (lle->la_flags & LLE_LINKED) { > + ifp = lle->lle_tbl->llt_ifp; > + } else { > + /* XXX RACE entry has been freed */ > + llentry_free(lle); > + return; > + } > CURVNET_SET(ifp->if_vnet); > > if ((lle->la_flags & LLE_DELETED) == 0) { If you need more information from the dump, let me know. --HPS From owner-freebsd-current@freebsd.org Thu Dec 10 15:33:22 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5D589D7E93; Thu, 10 Dec 2015 15:33:22 +0000 (UTC) (envelope-from hps@selasky.org) 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 8C9541294; Thu, 10 Dec 2015 15:33:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (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 2C6B01FE023; Thu, 10 Dec 2015 16:33:20 +0100 (CET) Subject: Re: panic in arptimer in r289937 To: Randall Stewart References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org> <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , freebsd-current From: Hans Petter Selasky Message-ID: <56699BAD.9090208@selasky.org> Date: Thu, 10 Dec 2015 16:35:09 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 15:33:22 -0000 On 12/10/15 16:25, Randall Stewart wrote: > For callout_stop/drain you get > > -1 == Callout as already gone off or is not running (usually the latter) else the caller iks > not using locking properly or did not lock and check the active() value (which would have returned not active so no stop > would have been needed); > 0 == we could not stop the callout, it was in process.. > 1 == it was stopped successfully > > > For callout_reset() you get > > 0 == it was started > 1 == it was restarted. > > There is no -1 since it is either started or restarted never left in a not-running state... > Hi, Correct, though if the return values would be the same, it might simplify the callout API and manual page a bit: /* return values for all callout_xxx() functions */ #define CALLOUT_RET_DRAINING 0 /* callout cannot be stopped, need drain */ #define CALLOUT_RET_CANCELLED 1 /* callout was successfully stopped */ #define CALLOUT_RET_STOPPED -1 /* callout was already stopped */ Then callout_reset() would return -1, if it was started from the stopped state. --HPS From owner-freebsd-current@freebsd.org Thu Dec 10 15:40:32 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66C0B9D53E4; Thu, 10 Dec 2015 15:40:32 +0000 (UTC) (envelope-from hps@selasky.org) 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 2E87517A2; Thu, 10 Dec 2015 15:40:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (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 02B6A1FE023; Thu, 10 Dec 2015 16:40:29 +0100 (CET) Subject: Re: panic in arptimer in r289937 To: Randall Stewart References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org> <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> <56699BAD.9090208@selasky.org> <0D974796-6166-48DB-BB66-72236E0B50AF@netflix.com> Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , freebsd-current From: Hans Petter Selasky Message-ID: <56699D5B.8070102@selasky.org> Date: Thu, 10 Dec 2015 16:42:19 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <0D974796-6166-48DB-BB66-72236E0B50AF@netflix.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 15:40:32 -0000 On 12/10/15 16:35, Randall Stewart wrote: > If you did that it would change the KPI a bit meaning lots > of thrashing in the code. > Hi, There are only 5 consumers of the callout_reset() return code in the FreeBSD 11-current kernel from what I can see: grep -r "= callout_reset" sys/ | wc -l 5 Two of these are already using > 0 checks. --HPS From owner-freebsd-current@freebsd.org Thu Dec 10 15:19:21 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E2789D74CD for ; Thu, 10 Dec 2015 15:19:21 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 4F76C18D4 for ; Thu, 10 Dec 2015 15:19:21 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by pacdm15 with SMTP id dm15so49180743pac.3 for ; Thu, 10 Dec 2015 07:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uAXgjMBQMvSBiF56K5cDrS8ficVXXJ7eBLT2JwhSFGs=; b=eVUE3qKnUEdYyN46BSh6O/AiMWzI8iGhAMxXbZUcfZeFeB/kOcFKszPpN40LCpUcii aVcKjEKgm9eP1jBxU3uQ2jUiVNqME41lvk+qRLnIBhoa58RGPb6RjwsNOgB65/lW92yp OCeJYFpSEavojogRt+2fBTppvBGwAG9597jD4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=uAXgjMBQMvSBiF56K5cDrS8ficVXXJ7eBLT2JwhSFGs=; b=e63LW1g+pBvMlt6nlA2jy/6ixaknp6lRTyGHnVx88wS49MZFB5S/UqfCneXJzxm9Tk BmePbIJp0wEQ+qJZlizyy7u2mvqRY/f4aoLi17FYzP0zcCfz2WOvYkolqCsJRDz/tVOl EKAku9PlEXl6ljLZiGec4DOsQVyPxUlsL9QEbGvaXQGyun39/xjfCOeSL0G3ZRjWSqeM /RDaBnGzMjjnuIZvwt0Kth1ZXKkqe0L/InQDycmVl9e/QmgSwHmH9q704EcPmJ/ygtHE e0aspqQkZa2vMRxnezS7KhGCjIPH8gIDXmMWlvflmmOzynKDhO0mR2beLEg965rM4W8/ FW5Q== X-Gm-Message-State: ALoCoQkd7MAqWfgNrWnn7QrUVk8ehCikmThbmdghP+akaki7/H6MiXEzLR8AoZEXW2jSXyXlWMPEXAGo1P2zmH2XY5YUk93xYQ== X-Received: by 10.66.254.234 with SMTP id al10mr17371925pad.87.1449760760835; Thu, 10 Dec 2015 07:19:20 -0800 (PST) Received: from ?IPv6:2607:fb10:16:208:6441:e815:1de9:889c? ([2607:fb10:16:208:6441:e815:1de9:889c]) by smtp.gmail.com with ESMTPSA id xz6sm12185043pab.42.2015.12.10.07.19.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Dec 2015 07:19:19 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: panic in arptimer in r289937 From: Randall Stewart In-Reply-To: <5661EAAF.1010906@selasky.org> Date: Thu, 10 Dec 2015 07:19:17 -0800 Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , freebsd-current Message-Id: <2CB15013-69DC-491E-A9AD-45CA95D37AE9@netflix.com> References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Thu, 10 Dec 2015 16:08:32 +0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 15:19:21 -0000 Hans: Though it would not hurt to add your patch, its not possible for callout_reset() to return anything but 1 or 0. Only callout_stop(), callout_drain(), callout_async_drain() can return = -1. So I don=92t think that this will fix it. R On Dec 4, 2015, at 11:34 AM, Hans Petter Selasky = wrote: >>>> . -------- Randall Stewart rrs@netflix.com 803-317-4952 From owner-freebsd-current@freebsd.org Thu Dec 10 15:26:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 525D79D791A for ; Thu, 10 Dec 2015 15:26:00 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 233D01D96 for ; Thu, 10 Dec 2015 15:26:00 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by pacdm15 with SMTP id dm15so49256930pac.3 for ; Thu, 10 Dec 2015 07:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=FTTHQyrkWI+EYCu+3oZ9tUhE3sqlQ6eQqVGGmHxbE2I=; b=aeXSkM29eIqqVhuGS75Mh2WBDulordAHYyyjZz+l9Zna9eS/RXA6HieOJpyzGnebiN mzgYKU90GVU/r6ZAfg8XNZf4Punj2XciFshkihVoz8DNox2w6HO9YmJOIoUutEVTKos1 vnMwdWuIPQHPf+K96bThdD0TXkdGl8Cokc8o8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FTTHQyrkWI+EYCu+3oZ9tUhE3sqlQ6eQqVGGmHxbE2I=; b=TiZ5tRB75h4DqOyUYWgG41/t7MXOWe2Rl+WMUAQbbLwhfYOK/qcJvBukvNAoXgELPM Q1orToAPNjIhhu+aNOF2wUgezA/LGpRBAxJj1SCiD4q7aog13k8K2YKkpF+d4B1sPju/ xFC7N8y4x/BduR1U669NeQGipEFUHO3AwAydqDqkvacL4UwuZgHe/FU92H8Wt/NcMMVK GnaxVi/pAB0mqRuJEdzKgYKDent9MqpMV4uNMtYQBtazkluyuz4GMMF9VxHS77I9A9bb rUbPJzWNoLTndedQ/vdEgECJER/LmFT9Tm0Y9KTFBfWpK/JpytjD7J6fF7znL8uUAg8W 5+TQ== X-Gm-Message-State: ALoCoQktI3atNNRRN/G1rqIfagOUK49z9UUETlPRcLWimWMuWrhYQR0nJat9xG/xSs7NMOhm/713pOnr8RDK+SR9F23c1FjUSA== X-Received: by 10.67.5.40 with SMTP id cj8mr17202864pad.98.1449761159705; Thu, 10 Dec 2015 07:25:59 -0800 (PST) Received: from [10.16.208.207] ([69.53.232.0]) by smtp.gmail.com with ESMTPSA id sg4sm19599472pac.48.2015.12.10.07.25.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Dec 2015 07:25:58 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: panic in arptimer in r289937 From: Randall Stewart In-Reply-To: <5661EF10.8060300@selasky.org> Date: Thu, 10 Dec 2015 07:25:56 -0800 Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , freebsd-current Message-Id: <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Thu, 10 Dec 2015 16:21:39 +0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 15:26:00 -0000 For callout_stop/drain you get -1 =3D=3D Callout as already gone off or is not running (usually the = latter) else the caller iks not using locking properly or did not lock and check the = active() value (which would have returned not active so no stop would have been needed); 0 =3D=3D we could not stop the callout, it was in process.. 1 =3D=3D it was stopped successfully=20 For callout_reset() you get 0 =3D=3D it was started 1 =3D=3D it was restarted. There is no -1 since it is either started or restarted never left in a = not-running state... R On Dec 4, 2015, at 11:52 AM, Hans Petter Selasky = wrote: > On 12/04/15 20:34, Hans Petter Selasky wrote: >> Hi Adrian, >>=20 >> On 10/31/15 16:01, Alexander V. Chernikov wrote: >>>=20 >>>=20 >>> 31.10.2015, 16:46, "Adrian Chadd" : >>>> On 31 October 2015 at 09:34, Alexander V. Chernikov >>>> wrote: >>>>> 31.10.2015, 05:32, "Adrian Chadd" : >>>>>> Hiya, >>>>>>=20 >>>>>> Here's a panic from arptimer: >>>>> Hi Adrian, >>>>>=20 >>>>> As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) >>>>> which happens after LLE_WUNLOCK(). >>>>> So, it looks like (pre-cached) ifp had been freed before locking >>>>> ifdata. >>>>> Do you have any more details on that? (e.g. was some interface >>>>> detached at that moment, is it reproducible, etc..) >>>>>=20 >>>>> =46rom a quick glance, potential use-after-free has been possible >>>>> for quite a long time, but I wonder why it hasn't been observed = before. >>>>> Probably lltable_free() changes might have triggered that. >>>>>=20 >>>>> I'll take a deeper look on that and reply. >>>>=20 >>=20 >> Observed on an idle box with projects/hps_head too: >>=20 >>> panic: bogus refcnt 0 on lle 0xfffff8016508ca00 >>> cpuid =3D 7 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xfffffe03e4e8c7e0 >>> vpanic() at vpanic+0x182/frame 0xfffffe03e4e8c860 >>> kassert_panic() at kassert_panic+0x126/frame 0xfffffe03e4e8c8d0 >>> llentry_free() at llentry_free+0x136/frame 0xfffffe03e4e8c900 >>> arptimer() at arptimer+0x20e/frame 0xfffffe03e4e8c950 >>> softclock_call_cc() at softclock_call_cc+0x170/frame = 0xfffffe03e4e8c9c0 >>> softclock() at softclock+0x47/frame 0xfffffe03e4e8c9e0 >>> intr_event_execute_handlers() at >>> intr_event_execute_handlers+0x96/frame 0xfffffe03e4e8ca20 >>> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe03e4e8ca70 >>> fork_exit() at fork_exit+0x84/frame 0xfffffe03e4e8cab0 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe03e4e8cab0 >>> --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- >>=20 >> Looks like callout_reset() must be examined too, and was missed by: >>=20 >> https://svnweb.freebsd.org/changeset/base/290805 >>=20 >> Can you try the attached patch? >>=20 >> Randall: Can you fix this ASAP? >>=20 >> --HPS >>=20 >=20 > Hi, >=20 > Randall: >=20 > I see for 11-current, callout_reset() doesn't return -1 when the = callout is stopped like with callout_stop(). Is this a bug or a feature? = Why can't the callout_reset() and callout_stop() functions use the same = return values? >=20 > In nd6_llinfo_settimer_locked() the return value of both = callout_reset() and callout_stop() is checked for positive values, but = not in the other places mentioned by my patch. >=20 > --HPS -------- Randall Stewart rrs@netflix.com 803-317-4952 From owner-freebsd-current@freebsd.org Thu Dec 10 15:35:47 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA73D9D50AB for ; Thu, 10 Dec 2015 15:35:47 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 BB33B1539 for ; Thu, 10 Dec 2015 15:35:47 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by pfu207 with SMTP id 207so49790525pfu.2 for ; Thu, 10 Dec 2015 07:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QpbrlU7/zpaHCEIPG7lrq/sXHtnSjTwnW8qIaM/QsFk=; b=oFxKkkPaI3V8Pc4oq/o07kCCE54osSIeJgrH4+d5JjQMm5Nj+xVMwCc/k81/EiNA9i iPnwanWgTOue4ZRK17qKnCAHZInSlfMXT7RxxYNzFRlU+qA0eQDqS4XErc157e2erP8N JfWzB6AsJ16i8uvksFS/aRaBpNED9aaOJkYEs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=QpbrlU7/zpaHCEIPG7lrq/sXHtnSjTwnW8qIaM/QsFk=; b=Z23mTgTrZ4EOiLfqrdAmKzQF74qsvuI5yR4ez5zgnyZixuvyAifd29ZG1ZKmcVYwbo leUUSIsNJSUN4JfGru5WDZousvGDEz278Tl9qw8le59TYiHGi76C4gSaA4eQjXBV7eBu yeTpJ6EaARfjAwi1kWbtUzNdMlYIhg2T4JglH0CNTW1B80qI6Jee9ed0iTArP9479O9d IxZdUAqB0mmP5X27PEl+5R7yn9FrxfmJL61D9v/cDLy+ZP6Jr09yMFjZrn6N3JsrgO5i /0rjHuuoFUCXU4TwSYw1U0phNdEUlnQLzapPZ7tpx8bmfyTd+jEGR4Gfb1+10kp6hXe7 01eg== X-Gm-Message-State: ALoCoQnEyqajEOztWHYgPgFPJhBAWmCvExvZ9pZrfB2TuJbReHBk/SyNFvSbTH/4gy4sSwsukJA4rOvRkKTsTucj3rKO9zWFrg== X-Received: by 10.98.7.129 with SMTP id 1mr7773816pfh.70.1449761747194; Thu, 10 Dec 2015 07:35:47 -0800 (PST) Received: from lgml-rrs-2.corp.netflix.com ([69.53.232.0]) by smtp.gmail.com with ESMTPSA id e14sm17226630pap.24.2015.12.10.07.35.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Dec 2015 07:35:46 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: panic in arptimer in r289937 From: Randall Stewart In-Reply-To: <56699BAD.9090208@selasky.org> Date: Thu, 10 Dec 2015 07:35:44 -0800 Cc: "Alexander V. Chernikov" , Adrian Chadd , freebsd-net , freebsd-current Message-Id: <0D974796-6166-48DB-BB66-72236E0B50AF@netflix.com> References: <2739461446298483@web2h.yandex.ru> <1733241446303675@web19h.yandex.ru> <5661EAAF.1010906@selasky.org> <5661EF10.8060300@selasky.org> <96B619F6-489C-4931-B306-1E1DE03F09B4@netflix.com> <56699BAD.9090208@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Thu, 10 Dec 2015 16:22:03 +0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 15:35:48 -0000 If you did that it would change the KPI a bit meaning lots of thrashing in the code. And on top of that you now would no longer return 0.. You would get 1 it was restarted or -1 it was not running but is now = started. Makes no sense to me sorry.. R On Dec 10, 2015, at 7:35 AM, Hans Petter Selasky = wrote: > On 12/10/15 16:25, Randall Stewart wrote: >> For callout_stop/drain you get >>=20 >> -1 =3D=3D Callout as already gone off or is not running (usually the = latter) else the caller iks >> not using locking properly or did not lock and check the = active() value (which would have returned not active so no stop >> would have been needed); >> 0 =3D=3D we could not stop the callout, it was in process.. >> 1 =3D=3D it was stopped successfully >>=20 >>=20 >> For callout_reset() you get >>=20 >> 0 =3D=3D it was started >> 1 =3D=3D it was restarted. >>=20 >> There is no -1 since it is either started or restarted never left in = a not-running state... >>=20 >=20 > Hi, >=20 > Correct, though if the return values would be the same, it might = simplify the callout API and manual page a bit: >=20 > /* return values for all callout_xxx() functions */ > #define CALLOUT_RET_DRAINING 0 /* callout cannot be stopped, need = drain */ > #define CALLOUT_RET_CANCELLED 1 /* callout was successfully stopped = */ > #define CALLOUT_RET_STOPPED -1 /* callout was already stopped */ >=20 > Then callout_reset() would return -1, if it was started from the = stopped state. >=20 > --HPS -------- Randall Stewart rrs@netflix.com 803-317-4952 From owner-freebsd-current@freebsd.org Thu Dec 10 19:56:37 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A8389D63F8 for ; Thu, 10 Dec 2015 19:56:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 156531E25 for ; Thu, 10 Dec 2015 19:56:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 13C399D63F6; Thu, 10 Dec 2015 19:56:37 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED6689D63F4; Thu, 10 Dec 2015 19:56:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DD3F11E24; Thu, 10 Dec 2015 19:56:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id C23481C8B; Thu, 10 Dec 2015 19:56:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 7671B177DB; Thu, 10 Dec 2015 19:56:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id kFgdGRJglC-K; Thu, 10 Dec 2015 19:56:29 +0000 (UTC) To: arch@FreeBSD.org, current@FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 1BEF0177D3 From: Bryan Drewery Subject: My build work and goals X-Enigmail-Draft-Status: N1110 Organization: FreeBSD Message-ID: <5669D8E9.8060000@FreeBSD.org> Date: Thu, 10 Dec 2015 11:56:25 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 19:56:37 -0000 This mail is to outline my recent work, goals and motivations. This is long. This is not really a architectural review or discussion mail. I am leaving those and details for their own threads where needed, so please do not start discussions about any of the details here. We will have them later. No one has really objected to my work but many have asked what my goals are and if the churn is worth it. A lot of my work lately has been to remove hacks in the build and use normal mechanisms or framework to achieve the same thing. Some of this is to remove hacks from the META build. Some of this is just natural evolution of the framework since we haven't had a real maintainer for so long. That may be putting it wrong but I think it is fair to say we're all a little scared of touching share/mk and try to do so as little as possible. Consider bsd.files.mk/bsd.incs.mk/bsd.confs.mk(new) are all 95% the same. I have not yet combined them but plan to. Why is SCRIPTS only in bsd.prog.mk? There's many problems in these files that need fixing. The vast majority of my work and "churn" lately has been improving the META mode build which is not the default build. So it may appear that I am churning the build a lot when I am really not. More on the META build later. First an introductory and background. Who am I? I came to the FreeBSD community as a Ports committer who was primarily focused on building up the Ports framework and its build tools. I tookover upstream maintenance of Portupgrade and then got involved with Poudriere in its early stages and helped bring it to what it is today. I think it is fair to say I have been the maintainer of Poudriere for some time now. I am one of the maintainers of the pkg.FreeBSD.org package builds and oversee its automation. I've written a few FreeBSD Journal articles about that. 99% of this was not sponsored though. For my day job at Isilon I recently moved my efforts to the base build. In many people's eyes the build system, 'buildworld', mostly "just works". The problems come in when "works" to you is time and productivit= y. At Isilon we have a range of development efforts that span from developers only caring about the kernel to ones who care about 1 userland tool. All of us expect that we should be able to just build our 1 thing rather than everything. Some of these 1 userland tool cases though have hundreds of dependencies. Most developers instinctively try building manually rather than Jenkins as it feels like it should be quicker. This leads to grief. The problem comes down to productivity. I've been given a great opportunity to address these problems and am running with it. Isilon has a quite convoluted build. Our product has its own ELF brand/ABI/KBI and cannot run on native FreeBSD systems. The build is done from a FreeBSD system for reasons, so is entirely a cross-build by expectations. We have a buildworld, ports phase, and then we have a buildworld-type thing of stuff that depends on ports! Both the ports and ports-dependent pieces are built in a jail using a special hack of a kernel module that provides KBI compatibility to the native FreeBSD system so we can run target binaries. QEMU does not apply here as it's not an architecture problem, it's a syscall/KBI problem. Solving ports cross-building will remove the need for this. Stepping back to pure FreeBSD now. Some various problems I've observed in the build: - Building clang twice. We build clang from the source tree so we can build everything with it even if /usr/bin/cc qualifies as "new enough" and "capable of cross-building the target". We later build clang for the target as well. Try doing this for 'make universe' for N architectures and you build clang N*2 times rather than N times. - Not being highly parallel. - Requiring building everything to build anything (without being an expert on manually building dependencies). AKA, no reliable sub-directory builds. - Incremental builds don't work reliably. We have stealth dependencies that are not tracked such as csu, libgcc, compiler_rt, compiler and Makefile (CFLAGS/LDFLAGS,build command). - There is gross under-linkage in libraries and over-linkage in binaries. - No foreign OS cross-build support. You must build from FreeBSD 8.0+. This is a problem when people prefer to run OSX or Linux for their primary system. - No cross-build support in Ports. - share/mk and Makefile.inc1 has a ton of bitrot. Some various problems I've observed with maintaining the build: - Adding new libraries into the build usually results in doing it wrong in Makefile.inc1's handling of 'make libraries'. I think it is fair to say that most people don't understand how any of this works. Just yesterday I discovered more of how it works that surprised me. - Adding new libraries into the build is usually done wrong in terms of the new framework. - There are little build framework sanity checks. The ports build has grown a large array of sanity checks over the past few years that is a decent model for the base system. Such as telling developers that they have used the framework incorrectly or forgotten something. - Adding new DESTDIR directories can lead to installing directories as files (think installing a header as /usr/include/foo rather than /usr/include/foo/file.h). This happens when missing adding to the MTREE files. - No one really was trying to improve it head-on and focused on FreeBSD's general audience needs. The maintenance problems come down to expertise. Most developers are not experts in the build and don't have time or interest to become so. It is not intuitive that adding a new include file and directory should require modifying an MTREE file somewhere else in the tree, or that __L and SUBDIR_depend entries are needed. Removing these landmines and adding sanity checks improves maintenance for everyone. Now for my goals and work. - My general goal is to be able to go into any src or ports directory, type 'make', and have everything just work (and have src/ports work with each other). Have all dependencies build, have them be incremental, and have parallelism work. Being able to do this on a foreign OS, such as OSX or Linux, is a stretch goal that I want to see but will require a lot of work and support from the Community to achieve. This goal may in the end replace 'make' with a different spelling but not one of having to set anything up like Poudriere requires. - Let the build tell you when you added something wrong so you can fix it before it harms someone else's time. Some improvements I have made recently: - WITH_FAST_DEPEND: Replacing the antiquated 'make depend'/'mkdep' with compiler dependency flags to generate the .depend files as a side-effect of compiling. This saves tremendous time in buildworld and buildkernel. Before this we were preprocessing files *twice*. Now we only do so while compiling. https://svnweb.freebsd.org/changeset/base/290433 has more details. This effort has mostly removed the need to even have a 'make depend' phase and I may still remove it with this option. I plan to enable this option by default quite soon. - WITH_CCACHE_BUILD: Utilizing ccache without -DNO_CLEAN to achieve an incremental build where builds are quite frequent. https://svnweb.freebsd.org/changeset/base/290526 has more details. - Having 'make install' error if trying to install a file into a non-existent directory. This has bitten us a lot. - Add more checks for adding LIBADD properly. - Allowing bsd.subdir.mk to run directories in parallel more often, such as always in 'make obj', since there is no harm in doing so. This can seem small at first but it adds up when we do many tree-walks. Some improvements I have planned soon: - Removing all of the __L and SUBDIR_depend in the tree. This depends on LIBADD, which is why I've been polishing it lately. - Tracking csu, libgcc and libcompiler_rt in DPADD. - Removing _DP_ duplication (since LIBADDs already define it) in src.libnames.mk. Midterm goals: - Building clang less. Being smart about when it needs to build a cross-compiler. Only building the cross-compiler with targets that are being built. - MFCing external compiler support to stable/10 as promised at the Vendor summit. I just haven't had time yet, but it is not that much. - Replacing 'make native-xtools' with something that works correctly. It is currently broken as it does not build required libraries for the host. This is only important for the current Poudriere+QEMU effort. - Reliable incremental builds in buildworld. This most likely will utilize the .MAKE.MODE=3Dmeta support from bmake along with filemon. See 'man make'. - Sub-directory builds. - Under-linkage of libraries and over-linkage of binaries. Generally a library should link in all of its needed dependencies, rather than forcing a consumer to link in something it doesn't care about (under-linking). There are exceptions to this of course. Consumers (both library and binary) also should not link in libraries they and their dependents do not need (over-linking). I went through a massive effort at Isilon to fix this for our internal libraries/binaries and plan to do the same for FreeBSD. We have test in our build that check for under/over-linking that utilize the tools/build/check-links.sh script. Special cases usually involve loadable modules that depend on their parent to provide symbols, cyclic dependencies and optional symbols that usually should be using weak symbols instead. The benefits here are both build parallelism, decreasing startup time for binaries/rtld, reducing memory mapping overhead for libraries that won't be used, and providing hints on what libraries are needed. - Possibly defaulting SUBDIR_PARALLEL to on and changing how we handle SUBDIR_DEPEND to be automated. Longterm goals: - Ports cross-building. It is a massive effort that several people have explored before and found to be "too hard" (because 24,000 ports IS too hard for major Ports changes). I admit that my only interest is in a handful of ports and I will not be trying to solve ports I have no interest in. I will not try to get all of ports cross-building, but I will hopefully help bring us a framework to that may lead to not needing QEMU. - Foreign OS builds. I think NetBSD got this right. I'm speaking from a very high-level and quick overview, but it seems that the gist here is that they build all of their libraries (libc being most important) into a libcompat that is linked into all "host"/"build" tools. We have libegacy (-legacy) that serves the same goal but we have by-design kept this extremely minimal. This is why I say the Community needs to support it as we've so far taken the minimum-required route for building on foreign (older) releases. Some details on solving primary goal of sub-directory and incremental builds: This problem is already solved by the recently imported META_MODE/DIRDEPS_BUILD mode from Juniper/sjg@. Simon presented this at BSDCan 2014: http://www.bsdcan.org/2014/schedule/events/460.en.html The DIRDEPS_BUILD is a collection of several features. It was recently renamed from META_MODE so META_MODE could be used on its own. Enabling it enables all of these features: 1. META_MODE (.MAKE.MODE=3Dmeta) which does for any shell command the sam= e as what the compiler -MM flags for generating dependencies (.depend/FAST_DEPEND) do for compiling. It uses filemon(4) to track all files read/written by the shell command and then considers those files as dependencies for the target later. It tracks these in a .meta file that can be thought of as a .depend file; it mostly only benefits incremental builds. It also tracks the build command which fixes changing of CFLAGS/etc not rebuilding. This feature solves incremental builds. This feature also allows not doing the same thing twice, such as installing into a STAGEDIR. If the file already exists and dependencies didn't cause a rebuild then there is no need to instal it again. This sounds magical but is just using a cookie on the install target and the cookie depends on all build dependencies via its .meta fil= e. 2. AUTO_OBJ prevents needing to tree-walk with 'make obj' as it just creates the objdir as soon as it touches a directory. 3. DIRDEPS_BUILD uses the Makefile.depend files to get a list of DIRDEPS. This is just a list of directories that need to be built before this directory. These Makefile.depend files are included from the first make process (non-recursive process-wise) that generate a dependency graph. From this graph sub-makes are called to build each dependency. This also supports building a 'host' version of a directory first so it can be used as a build tool. This feature solves sub-directory builds at the cost of having generated files checked in. 4. STAGING installs files after they are built into a STAGEDIR (like WORLDTMP). This allows linking to libraries already built. This is not that different from what buildworld does not for 'make libraries' but is subtlety different in that it does not tree-walk 'all' before 'install', it just installs right after 'all' in each directory. This subtle difference leads to the surprising behavior I referred to in __L/'make libraries' earlier. The STAGING feature also creates a FILE.dirdep in the STAGEDIR for every file to specify which SRCDIR installed it which UPDATE_DEPENDFILE uses. 5. UPDATE_DEPENDFILE utilizes the information from META_MODE/filemon(4) to see which files from the OBJDIR or STAGEDIR were used in the build. Any SRCDIR from there, considering the FILE.dirdep for used files in STAGEDIR, is added to the DIRDEPS list. A basic .depend-like file is also generated for generating of objects, called "local dependencies". This last piece is due to not running 'make depend' and through my findings is largely unneeded now. All of this information, the DIRDEPS and local dependencies, are written out into the Makefile.depend for that build directory. It is expected to check in this file as otherwise you cannot build in this directory later since it is unknown what it needs to build. Some problems with the combined DIRDEPS_BUILD build: It is very hard to maintain, prone to massive churn in directories you did and did not touch, requires checking in fickle generated files, has a chicken-and-egg problem for adding new things, does not respect WITH/WITHOUT options or ARCH-dependent SUBDIR, has subtle problems with a static dependencies list around options, and has no 'installworld' support. The lack of 'installworld' is a deal breaker, albeit probably trivial to fix. The reason for this is that the system is used to generate packages (not pkgng style) at Juniper. We have our own packaging effort occurring in projects/release-pkg though and won't likely use the same methods that the DIRDEPS_BUILD does (of which none of the support is really in the src tree). This build does not use recursive SUBDIR walking (by design). It uses a static list of directories to build in the targets/pseudo/userland/*/Makefile.depend files. So we have to maintain new/removed applications in two places. The effort by Simon and I here was lacking in 100% OPTION and ARCH support as well. Warner and I have discussed moving OPTION/ARCH checks from SUBDIR Makefile into the actual build files. That would help maintenance of targets/ some but still leave the connect/disconnect maintenance issue. Some directories still not built are rescue/rescue and sys/modules. The checked-in Makefile.depend files have a flaw (feature for static builds perhaps) that the invoking the linker will cause non-direct dependencies to show up in Makefile.depend. This leads to situations such as https://svnweb.freebsd.org/changeset/base/291558. There is also a situation where a local build may set MK_SSP=3Dno and yet need to build a dependency that wants MK_SSP=3Dyes (libssp dependency) but because of how DIRDEPS are processed it means that libssp is never built and the build fails. They also require hacks to support ARCH/OPTION-dependent dependencies by modifying local.dirdeps.mk and local.gendirdeps.mk, which can easily lead to over-depending on something. The checked-in auto generated Makefile.depend can cause them to change unexpectedly and cause a developer to waste their time looking into why, or not committing it and then wasting someone else's time when it won't build. Most developers naturally do not want to check in generated files and so I generally see this as unworkable. Lastly, generating Makefile.depend when you have none, or different options/dependencies than upstream, is an exhaustive chicken-and-egg problem. These problems make checked-in Makefile.depend infeasible. "But wait, can you just not check them in?" Not really. The targets/ and checked-in Makefile.depend are largely to decrease startup overhead costs by not needing recursive tree walks. I have recently added support to local.dirdeps.mk to make an educated guess on what DIRDEPS should be even if there is no Makefile.depend. This is based on what is being built (C and C++ objects have common dependencies) and what DPADD/LIBADD there are. In most cases this is enough. It has greatly helped when bootstrapping Makefile.depend. Going further though I have written a script that just recursively walks the tree to generate the DIRDEPS graph from the first make process rather than including the Makefile.depend files. This removes the need for having any Makefile.depend and allows targets/ to be dynamic and utilize the existing SUBDIR around the tree. Obviously the trade-off here is startup time at the benefit of maintainability. This script I have written for this is very similar to what Poudriere is doing though so I have a lot of experience and code for optimizing it. I plan to use this as a build option at Isilon rather than having checked-in Makefile.depend files. I will add support for this in FreeBSD as well. None of this or DIRDEPS_BUILD would be on-by-default though. As for buildworld, I have been working on improving it as well in case my plans with the META build did not pan out. Having split my time between them I see now that much of buildworld can directly benefit from the range of features that DIRDEPS_BUILD uses. I plan to bring in .MAKE.MODE=3Dmeta to buildworld to fix incremental and redundant WORLDTMP staging. I plan to rework 'make libraries' significantly utilizing my DIRDEPS script to generate the __L in an automatic and hidden way. It may be that my first iterations of this is to have us generate a file and check it in until I can improve the speeds. This is still better than the current situation of unmaintainable __L in Makefile.inc1. P.S. Working on this stuff can be exhausting. Mistakes are easy. Especially when existing behavior is obscure, undocumented and possibly accidental and things depend on that behavior. I get burned out on it often and shift my efforts around to keep going. Some may notice I am skipping review on a lot of it. The reasoning is that it is either too obvious, too prone to bikeshedding over insignificant details, or so obscure and unobvious that a review would not serve much benefit as no one really knows the code in question or just be too unsure to put their name on it. All of which I see as a time waste for others. Objectionable or easily-wrong changes I am getting reviews for or going slow with (such as FAST_DEPEND). I am MFCing relevant and safe changes mostly only to reduce merge conflicts for others. I have no real interest in building stable/* and don't want to cause issues for others there. Thank you for your patience and hopefully when I'm done we will have something better that we can all agree with and work with. --=20 Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Thu Dec 10 22:28:58 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B164F9D6180 for ; Thu, 10 Dec 2015 22:28:58 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 80E671C58 for ; Thu, 10 Dec 2015 22:28:58 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 7D5929D617E; Thu, 10 Dec 2015 22:28:58 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 643C79D617C; Thu, 10 Dec 2015 22:28:58 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD6CF1C56; Thu, 10 Dec 2015 22:28:57 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BLUPR05CA0062.namprd05.prod.outlook.com (10.141.20.32) by BN1PR05MB059.namprd05.prod.outlook.com (10.255.202.149) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 10 Dec 2015 22:28:49 +0000 Received: from BL2FFO11FD047.protection.gbl (2a01:111:f400:7c09::178) by BLUPR05CA0062.outlook.office365.com (2a01:111:e400:855::32) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Thu, 10 Dec 2015 22:28:49 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BL2FFO11FD047.mail.protection.outlook.com (10.173.161.209) with Microsoft SMTP Server (TLS) id 15.1.337.8 via Frontend Transport; Thu, 10 Dec 2015 22:28:48 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 10 Dec 2015 14:28:47 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tBAMSkD70458; Thu, 10 Dec 2015 14:28:47 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id A2D31580A9; Thu, 10 Dec 2015 14:28:46 -0800 (PST) To: Bryan Drewery CC: , , Subject: Re: My build work and goals In-Reply-To: <5669D8E9.8060000@FreeBSD.org> References: <5669D8E9.8060000@FreeBSD.org> Comments: In-reply-to: Bryan Drewery message dated "Thu, 10 Dec 2015 11:56:25 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28127.1449786526.1@chaos> Date: Thu, 10 Dec 2015 14:28:46 -0800 Message-ID: <16318.1449786526@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD047; 1:JhNxxLquP+dLQXXFvN3TgTwNISgAVpYxA8WJuVKTLtGLa3YKUFP+/G/XPYb4KIgeBPsRXz5jtaibEad7sTEMEJEyGaAoKmyS8nshlm+9RPeCczJLkH755uFd9ub7nI8Imlfk8brmKJhmZyMr5IfW9R7L5D4avN5Kd8fecgmBMdfb4oOB9PwTypmot6N2fJXrw6NsO+t9NhgUeNF+vZ39DJgDMjlBuduBt3i0I+ma5iTY02+p2h/Stc0MmvOR86jZXkEDjHWY+ME8ATopX+YOf1I6iMxxl3zXmHo+XtnbqHTWv2sulYsSNVy79ACi42THWtrTy/s4rLG9rwgG/cSILZk28S2bozcACy2IH6jjtpc= X-Forefront-Antispam-Report: CIP:66.129.239.19; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(24454002)(199003)(6806005)(77096005)(4001430100002)(86362001)(5008740100001)(2950100001)(450100001)(50226001)(50466002)(15975445007)(1220700001)(23726003)(76176999)(57986006)(46406003)(106466001)(105596002)(19580405001)(19580395003)(586003)(1096002)(50986999)(117636001)(87936001)(97736004)(107886002)(47776003)(33716001)(69596002)(97756001)(92566002)(110136002)(5001960100002)(81156007)(11100500001)(76506005)(189998001)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB059; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 2:VcXM3KQAN+z/FkyGk+UXvuBKIy81noCp0e0OHiShTT46oOZVwmY2cIbQRE9W1AY0gO3PTom04hcp2kD07QVcU5FTqkLt4oaz9/xg1RfqbNVGqukeQgZxlPGrhcVc1tsf3bHisyGNZE3+IXDAe2uOFw==; 3:bmjjQpQ0vfOKXNB1gB3yOH4uu4q/lh1x8cG01FfMqZkL0akDK2GF/ZhIF5qk9QjRUfV1EygtzGGB2Oa+fKwkfU+lrRExQijfEF9TUupKr7XjhqxveANHMnIELVkwxBAnfTY/vTeOaOCiZVA8rZcru4TzlEF7Oj98ymMuaNYtckCdDlN2et0UDMRLb2f4f7D9suZXIBTVdIiLd1WGLsJWpE3fGCvbO85BUjFSbkmAJkY=; 25:O2U3UUqf8eeIAJKfET4PnU+Ydz7ZzrKVITrqm7okvEDgizo+FdxnM2gKaI2+JRt3cuG+b0ch/qHCxrkkaLmb/5i3jP3zkD9JLnC6y+pbAJwhJ1HFKY19LT7evxGNPWxv2tFj+PDbUpxV7c8uiZnwmI9skSvVx29NHvdL5ISXcAgSQvf76aeHuhniFZYrUzmqB/kxJubriuZ5rneY8EJUB/U2W1+zP2KYthiYM+uEOUzu0Ekvxh5VQ1xfvcOrZfSAe4TNjMtrkI77N1rRydevVA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB059; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 20:6FVIyyPABEvZI8WYr1CqSxfJ57vEEs//aaJHVeJMQeowW/sL7IaIQbDTOA7eEHUyJ2Ec1F3qGK4KY1+wTLWuOJmTjs9wPID0yrf1I+OwBKL9H66iWu8jbCoTVDDntkXLRc2SlhtaM6NSnmRNYDqamNk+yPcn0xJBBMkyTr7jOHlxNPQfSpKKw4Yny19oSqmfn7jyiaYgbImLFK8NTFcy87UAl3sLJDxFDkZjlMpMJlRJkJN0R62sB+J9JQjLVOwubv1YFXJVRv/Ve0mPN6Pq7WRZU0ixR0LzlRLArE0UNI9Qvj/bKD0KCayTUaJwxvR2sVtVAc9K1QLxFUskutafG4p2ETGCPZ3FyrsgyjWOIlH3KQhlVwuuBCiJQNnhWZRokReRRzcc1QFalP0p00adaCXvwIzHGXxl+MHP1qD/c2oYstStnfRnmbvm+RgM3ILXS8NDuYqeiMvkgLfhW2d+B1igmmnHCAsnzLBl4s706C77wooBmzVEars/ZfuUMby/; 4:EscAxGk0Gp0QE8+JZf28VdmMuDz9mDZL64/v7kOLHgX4BZc+9CTOGRbMqkuGN4B/dnn/uPiys44PL76QqkqrVSI2kywlQWcdZGl1DOuHrtL3Y2VWCjp2vM9mn5xY/Yf8eQtvrKKQ/bkbtafFSOH3xyExF+pM+LrHSdNu7sg0Fs/y3zY+8pkm/iz7d8zgNsgh3/msdzR3wslhXG6nTilAV4y7HngxYPq6ahv3oFNBBYF0PKmNKpRZj9de0zKEGfNugKfI0DIaIRhM8q8KEu7IKnhsaCa16Kc46DWz+TxTP8y/m4Obr0enWSsemX9ePoPywJ3oq4Aue89Ag8HWHpEznr/RLH2m3YX5JZ+dfL3P6Nhu464DnyLHumlnGxuzzM28 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN1PR05MB059; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB059; X-Forefront-PRVS: 078693968A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB059; 23:imezTDdd4en7GeZy8kQ2G9zCpny77qXFX04Vuy+vby?= =?us-ascii?Q?xG3gGZMONU/ldfIBPq9L+24OBT6lABu2Ltdr2hufkSJmysLziK9SL0A6kYKf?= =?us-ascii?Q?A6YNE9UIrLGSTQ7NC4VrBUBCfF0kSsGIkdGlDL0hZ3ofKCfegT5yoyaz56u2?= =?us-ascii?Q?+a8/32JZRCIPWq56GqodAJf8MclLZRAmMzavZjZYtnhn0rT0LH6c0Qjnu8Ua?= =?us-ascii?Q?pztP4ekp5/HthgQpYqGmGF0yDaaKDLBRnrnzc5xgTsigTsnomz3h3nWqSvul?= =?us-ascii?Q?UFJrRp5u2ttir+aLn8ewwJV1pfKaTsAkD0lok9lxh9aiST1y9embC2si4cQC?= =?us-ascii?Q?0hVLcSpDt8Zpc3Yfszr8Vtwk661p9zcePetSotq4DX5mxcYo+vY91xo2E6jn?= =?us-ascii?Q?c56sBKjMQ4cWyJlkvUZ8VqY3hmAd7pv43tqf/9EnQDAEVxxTMFv+8hTGbuIA?= =?us-ascii?Q?+94xnRrsAOuI4ZVE78diWrErw9VRK6YdKKXpEX+6uB5F0GnY9FZ+gCZs5AUe?= =?us-ascii?Q?bdow5rGdtGLs3ged9XAa2fHX2QAQSHyRGWnRgVjaT+xMYXQP9eATSnzWacRL?= =?us-ascii?Q?fV07sGe3x964twEcdgTgii9OQhp0s9VnhFW4G6geNAu6jacVBj0BmbKmodOT?= =?us-ascii?Q?I0TbRbD26kO4WK9KcZBgfZWaVj81KqIe0+qVNlhtO/OCaqmC3FSphsl6OoIZ?= =?us-ascii?Q?P7uiQIevLKScl3LmIDdwC/oIXJtFdBI9ofnG0geCq/a4GpbiMuYvszdI+7Y4?= =?us-ascii?Q?0T1JYrRXGONRplDzXQ2rkZUqIZ4goNZ+glvNxAeoz0PnZbK5Ef59+z50dYnJ?= =?us-ascii?Q?+5FMfK5mibz51HCmmGUdakZahOJwZBu6vUdf2Mch+Hqvkouq8GCLE2Lr6uQC?= =?us-ascii?Q?bZZjhB4Pynp1MRq5pR9LpYFHeYSJEsDSIpJMlLTAJTB9Wu7hTb0OK6Q0PLeU?= =?us-ascii?Q?4fHYEw4/2Gcz9oxUTKWER36QrmBWX7bmV71nXKfgYeJ4ODqs8vuNVv5zaEG9?= =?us-ascii?Q?PpGkdyW+DICSduB7+VwDcNZbsZ9cPUSYzjRY0p4CzuKdCrBTKxZ3hCOEkIB4?= =?us-ascii?Q?gePzfLFpvS0BqPuqsv2EF1+De4Ltx+X8/ycpcCcJZDA+xrl4eZmYTvbBcNx9?= =?us-ascii?Q?D6JTpDV1qqMI+VqVSoLx+fwt3crXFpzI3bOL64DayYG22MHkUDag=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 5:E70F5fJLmG5oSuHm+w0rkECYiBU+zX9Rfzn0k5eeP5ebvy7oFuYuuwCBQrJF+jNN3NyuwO0HRJKKg5/SCzknFnxEBOqLmQ+2IJN0/EYkB9Zi2iwOlkbbaV45GqspU7DChidIcBsS8BVqKlVpBkoOBQ==; 24:dWhoCmdEwL4tGbIx4ElCIVpneC4+bRrZ8OrEo7arbpWkQnJr98EH5MQlT7F+0fpBjQHC5fu/BEPRTqXknDQnjiggmXHMap10paRC7t+a6oE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2015 22:28:48.8703 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB059 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 22:28:58 -0000 Firstly, nice writup - a few extra blank lines might have helped my eyes though. Bryan Drewery wrote: > This mail is to outline my recent work, goals and motivations. This is > long. This is not really a architectural review or discussion mail. I ... > Some problems with the combined DIRDEPS_BUILD build: > > It is very hard to maintain, prone to massive churn in directories you > did and did not touch, requires checking in fickle generated files, has > a chicken-and-egg problem for adding new things, does not respect > WITH/WITHOUT options or ARCH-dependent SUBDIR, has subtle problems with > a static dependencies list around options, and has no 'installworld' > support. Dealing with all the optional cases is definitely a problem to be solved. I've a few ideas on that front, but haven't had time to experiment. FWIW we (Juniper) see zero "churn" in our dependencies a/ we use a fixed set of options b/ we've fixed the bugs in makefiles that were causing churn. Ignoring the WITH/WITHOUT options stuff for a sec, dependency churn is usually a result of bugs in the leaf makefiles. These are often easy to spot, sometimes quite hard. The bootstrap issue and even just the need to checkin "generated" files is a head scratcher for a surprising number of people - even after 4+ years of building this way. > The lack of 'installworld' is a deal breaker, albeit probably trivial to > fix. The reason for this is that the system is used to generate > packages (not pkgng style) at Juniper. We have our own packaging effort > occurring in projects/release-pkg though and won't likely use the same > methods that the DIRDEPS_BUILD does (of which none of the support is > really in the src tree). Though AFAIK all the tools we use are, so its really just a matter of adding some suitable makefiles and manifest - to say build a bootable vm image - I probably would have done that by now if bhyve supported vmdk or qcow2 ;-) But that's likely orthogonal to your point. Some form of "installworld" is probably needed. > This build does not use recursive SUBDIR walking (by design). It uses a > static list of directories to build in the > targets/pseudo/userland/*/Makefile.depend files. That's mostly just for the purpose of demonstration/example. If/when FreeBSD has some form of manifest/list for what goes into its "packages" (of whatever form they might be,) then the necessary data to drive what needs to be built could be obtained from them - as we do in the Junos build. > The checked-in Makefile.depend files have a flaw (feature for static > builds perhaps) that the invoking the linker will cause non-direct > dependencies to show up in Makefile.depend. This leads to situations > such as https://svnweb.freebsd.org/changeset/base/291558. There is also > a situation where a local build may set MK_SSP=no and yet need to build > a dependency that wants MK_SSP=yes (libssp dependency) but because of Yes, options are a pain. You can either hard code them via local.dirdeps.mk but it is probably better to do something a bit like what the current intermediate makefiles do (one of the idea I mentioned above). Eg. if the captured dependencies had something like ${lib_libssp} rather than lib/libssp. If MK_SSP=no it expands to nothing. I can elaborate in separate thread if you prefer. > than upstream, is an exhaustive chicken-and-egg problem. These problems > make checked-in Makefile.depend infeasible. "But wait, can you just not > check them in?" Not really. You can, but you lose virtually all the benefits. > recently added support to local.dirdeps.mk to make an educated guess on > what DIRDEPS should be even if there is no Makefile.depend. This is > based on what is being built (C and C++ objects have common > dependencies) and what DPADD/LIBADD there are. In most cases this is > enough. It has greatly helped when bootstrapping Makefile.depend. You still have the issue of local depenenencies. Sure, only a small percentage of makefiles have problems in this regard, but humans are generally bad at expressing the dependencies that result from using things like yacc - get it wrong about 80% of the time. > Going further though I have written a script that just recursively walks > the tree to generate the DIRDEPS graph from the first make process > rather than including the Makefile.depend files. This removes the need That's what we used to do, but was deemed too expensive. Using that to generate Makefile.depend though for your tree, could save you some overhead on subsequent builds, while allowing tailorying tree to your set of options. > P.S. Working on this stuff can be exhausting. Mistakes are easy. Thanks for your efforts btw. --sjg From owner-freebsd-current@freebsd.org Thu Dec 10 23:55:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A58CA9D60A4 for ; Thu, 10 Dec 2015 23:55:00 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 456C517C0 for ; Thu, 10 Dec 2015 23:54:59 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-f793c6d000006975-4f-566a0f9ddee1 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id D1.77.26997.E9F0A665; Thu, 10 Dec 2015 18:49:50 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tBANnnqU028904; Thu, 10 Dec 2015 18:49:49 -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 tBANnjsp009322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Dec 2015 18:49:48 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tBANnjxA008987; Thu, 10 Dec 2015 18:49:45 -0500 (EST) Date: Thu, 10 Dec 2015 18:49:45 -0500 (EST) From: Benjamin Kaduk To: Rick Macklem cc: freebsd-current Subject: Re: RPC request sent to 127.0.0.1 becomes from other IP on machine In-Reply-To: <521574245.126601980.1449754639530.JavaMail.zimbra@uoguelph.ca> Message-ID: References: <521574245.126601980.1449754639530.JavaMail.zimbra@uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrTuPPyvM4G4bh8WcNx+YLB4uu8bk wOQx49N8Fo/fm/cyBTBFcdmkpOZklqUW6dslcGUcPXyRsWAzT8XHi41MDYyPObsYOTkkBEwk Hj0+yQ5hi0lcuLeerYuRi0NIYDGTxNSLU1khnI2MElP2HWSHcA4xScxduZIZwmlglNg85TAb SD+LgLbE9umfmUBsNgEViZlvNoLFRQTUJTav7mcGsZkFDCVerrsHtk9YwFti4rnpYDangI/E sxdXwOp5BRwl9lyZzgpiCwHVPGzsA5spKqAjsXr/FBaIGkGJkzOfsEDM1JJYPn0bywRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3StdDLzSzRS00p3cQIClZ2F9UdjBMOKR1i FOBgVOLh9WDLChNiTSwrrsw9xCjJwaQkyjvrW2aYEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe CG6gct6UxMqq1KJ8mJQ0B4uSOO/cL75hQgLpiSWp2ampBalFMFkZDg4lCd4CPqBGwaLU9NSK tMycEoQ0EwcnyHAeoOGyIDW8xQWJucWZ6RD5U4yKUuK8ASAJAZBERmkeXC84mexmUn3FKA70 ijBvL0gVDzARwXW/AhrMBDT4y5V0kMEliQgpqQZGybQFRWbHe5wnMr3m2LOI5depxRan/l9b +fipMseusnu3Vxwz0herzrirPk1YV8hv0umEd+JTE5nmflWY3rk0TjYi2CBnTeOWwitflSZE 6Pi/m3Z0+asLdWXNfB9+x51dKbbuq7t5j8bpQ4vUK7QNbiw8yjq3cOnTdR/99jyqzFQqKLvK 1pUwUYmlOCPRUIu5qDgRAO4V0SsBAwAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 10 Dec 2015 23:55:00 -0000 On Thu, 10 Dec 2015, Rick Macklem wrote: > Hi, > > Mark has reported a problem via email where the nfsuserd daemon sees > requests coming from an IP# assigned to the machine instead of 127.0.0.1. > Here's a snippet from his message: > Ok, I have Plex in a jail and when I scan the remote NFS file share the > *local* server's nfsuserd spams the logs. > Spamming the logs refers to the messages nfsuserd generates when it gets > a request from an address other than 127.0.0.1. > > I think the best solution is to switch nfsuserd over to using an AF_LOCAL > socket like the gssd uses, but that will take a little coding and probably > won't be MFCable. > > I've sent him the attached patch to try as a workaround. > > Does anyone happen to know under what circumstances the address 127.0.0.1 > gets replaced? My memory is quite hazy on this subject, but I think that outbound traffic from a jail is not permitted to use the system loopback address 127.0.0.1; traffic from this address within a jail gets replace with the jail's primary IP address. It is possible to specify an alternate loopback address for use within the jail (e.g., 127.0.0.2) and if that alternate address is only bound within the jail, it can be used for outgoing traffic to the host. See jail.conf(5); I appear to have something like: kduck { host.hostname = "kduck.mit.edu"; ip4.addr = lo0|127.0.0.2, 18.18.0.52; [...] } Note that there may be some additional magic about the primary address of the jail being first (or last?) in the list of addresses. -Ben From owner-freebsd-current@freebsd.org Fri Dec 11 00:23:03 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90A759D5C1E; Fri, 11 Dec 2015 00:23:03 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 850B819FC; Fri, 11 Dec 2015 00:23:03 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id C694B5B7; Fri, 11 Dec 2015 00:23:02 +0000 (UTC) Date: Fri, 11 Dec 2015 00:22:57 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: asomers@FreeBSD.org, cem@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <633378259.15.1449793381876.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <41829760.13.1449771026305.JavaMail.jenkins@jenkins-9.freebsd.org> References: <41829760.13.1449771026305.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #1858 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 00:23:03 -0000 FreeBSD_HEAD_i386 - Build #1858 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1858/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1858/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1858/console Change summaries: 292067 by cem: vm_page_replace: remove redundant radix lookup Remove redundant lookup of the old page from vm_page_replace. Verification that the old page exists is already done by vm_radix_replace. Submitted by: Ryan Libby Reviewed by: alc, kib Sponsored by: EMC / Isilon Storage Division Follow-up to: https://reviews.freebsd.org/D4326 Differential Revision: https://reviews.freebsd.org/D4471 292066 by asomers: During vdev_geom_open, require that the vdev guids match the device's label except during split, add, or create operations. This fixes a bug where the wrong disk could be returned, and higher layers of ZFS would immediately eject it again. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c: o When opening by GUID, require both the pool and vdev GUIDs to match. While it is highly unlikely for two vdevs to have the same vdev GUIDs, the ZFS storage pool allocator only guarantees they are unique within a pool. o Modify the open behavior to: - If we are opening a vdev that hasn't previously been opened, open by path without checking GUIDs. - Otherwise, open by path and verify GUIDs. - If that fails, search all geom providers for a device with matching GUIDs. - If that fails, return ENOENT. Submitted by: gibbs, asomers Reviewed by: smh MFC after: 4 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D4486 From owner-freebsd-current@freebsd.org Fri Dec 11 01:51:29 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 562219D641E for ; Fri, 11 Dec 2015 01:51:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 02DC21A7E for ; Fri, 11 Dec 2015 01:51:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:mIj+ABIh19+PIjNSYNmcpTZWNBhigK39O0sv0rFitYgULPnxwZ3uMQTl6Ol3ixeRBMOAu6wC07KempujcFJDyK7JiGoFfp1IWk1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXsq3G/pQQfBg/4fVIsYL+lRMiK14ye7KObxd76W01wnj2zYLd/fl2djD76kY0ou7ZkMbs70RDTo3FFKKx8zGJsIk+PzV6nvp/jtLYqySlbuuog+shcSu26Ov1gFf0LRAghZko44s/isBjFBSiG6mYfGjEVmxZVACDgzS28c7vM5HjUrO14jRObNs6+aLk/WjCv6u8/UhrhgyQDOjsR7WbYl8F0lKIdqxv39E83+JLdfIzAbKk2RajaZ95PADMZBss= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CtBACXK2pW/61jaINeDoN/bga9Q4FiFwqFJEoCgXISAQEBAQEBAQGBCYItggcBAQEEAQEBICsgCwwEAgEIGAICDRkCAicBCSYCBAgHBAEaAgSIDg2tFZF/AQEBAQEBAQEBAQEBAQEBAQEBG4EBhVWEfVIWg0IQAgEFgzWBSQWOJ4hJhTSFIoURmmYCKAc0g0ZcIDQHhEmBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,410,1444708800"; d="scan'208";a="255547396" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 10 Dec 2015 20:51:18 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id E7B3415F565; Thu, 10 Dec 2015 20:51:18 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id b7MMgQrlEz_l; Thu, 10 Dec 2015 20:51:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 7CCCA15F56E; Thu, 10 Dec 2015 20:51:18 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vssIHBDONg4R; Thu, 10 Dec 2015 20:51:18 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 63A0215F565; Thu, 10 Dec 2015 20:51:18 -0500 (EST) Date: Thu, 10 Dec 2015 20:51:18 -0500 (EST) From: Rick Macklem To: Benjamin Kaduk Cc: freebsd-current Message-ID: <1916004699.127591232.1449798678143.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: <521574245.126601980.1449754639530.JavaMail.zimbra@uoguelph.ca> Subject: Re: RPC request sent to 127.0.0.1 becomes from other IP on machine MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: RPC request sent to 127.0.0.1 becomes from other IP on machine Thread-Index: u/PpY21mh/Ra6N8poT2Zek8zYa0bjA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 01:51:29 -0000 Ok, I had a hunch it was related to the use of jails. I am just testing a patch that switches the nfsuserd over to using an af_local socket, so this will be avoided. (I think it makes more sense anyhow. I just never got around to doing it.;-) Thanks for the info, rick ----- Original Message ----- > On Thu, 10 Dec 2015, Rick Macklem wrote: > > > Hi, > > > > Mark has reported a problem via email where the nfsuserd daemon sees > > requests coming from an IP# assigned to the machine instead of 127.0.0.1. > > Here's a snippet from his message: > > Ok, I have Plex in a jail and when I scan the remote NFS file share the > > *local* server's nfsuserd spams the logs. > > Spamming the logs refers to the messages nfsuserd generates when it gets > > a request from an address other than 127.0.0.1. > > > > I think the best solution is to switch nfsuserd over to using an AF_LOCAL > > socket like the gssd uses, but that will take a little coding and probably > > won't be MFCable. > > > > I've sent him the attached patch to try as a workaround. > > > > Does anyone happen to know under what circumstances the address 127.0.0.1 > > gets replaced? > > My memory is quite hazy on this subject, but I think that outbound traffic > from a jail is not permitted to use the system loopback address 127.0.0.1; > traffic from this address within a jail gets replace with the jail's > primary IP address. It is possible to specify an alternate loopback > address for use within the jail (e.g., 127.0.0.2) and if that alternate > address is only bound within the jail, it can be used for outgoing traffic > to the host. See jail.conf(5); I appear to have something like: > > kduck { > host.hostname = "kduck.mit.edu"; > ip4.addr = lo0|127.0.0.2, 18.18.0.52; > [...] > } > > Note that there may be some additional magic about the primary address of > the jail being first (or last?) in the list of addresses. > > -Ben > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Dec 11 06:44:25 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFE119D5A31 for ; Fri, 11 Dec 2015 06:44:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B013012E3 for ; Fri, 11 Dec 2015 06:44:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id ABC949D5A30; Fri, 11 Dec 2015 06:44:25 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB4579D5A2D; Fri, 11 Dec 2015 06:44:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (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 8B71E12E1; Fri, 11 Dec 2015 06:44:25 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-242-164.lns20.per4.internode.on.net [121.45.242.164]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tBB6iDgs059838 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 10 Dec 2015 22:44:17 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: My build work and goals To: Bryan Drewery , arch@FreeBSD.org, current@FreeBSD.org References: <5669D8E9.8060000@FreeBSD.org> From: Julian Elischer Message-ID: <566A70B8.3060609@freebsd.org> Date: Fri, 11 Dec 2015 14:44:08 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5669D8E9.8060000@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 06:44:25 -0000 On 11/12/2015 3:56 AM, Bryan Drewery wrote: > I think it is fair to > say that most people don't understand how any of this works. [...] > - No one really was trying to improve it head-on and focused on > FreeBSD's general audience needs. > The maintenance problems come down to expertise. Most developers are > not experts in the build and don't have time or interest to become so. These three points are all pretty much the same thing. I agree that it definitely needs to have a fairy godfather. > > > Some improvements I have made recently: > - WITH_FAST_DEPEND: Replacing the antiquated 'make depend'/'mkdep' with > compiler dependency flags to generate the .depend files as a side-effect > of compiling. This saves tremendous time in buildworld and buildkernel. Mach used to have this through their entire (bsd 4.3) tree. I forget how they bootstrapped it. Gcc would generate added dep files which were included into the static files. Without the dep files, every thing was assumed to be dirty. The new dep files only kicked in on the second build. It worked very very well. > > > > > From owner-freebsd-current@freebsd.org Fri Dec 11 08:29:52 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E4DA9D6482; Fri, 11 Dec 2015 08:29:52 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 730A51DF8; Fri, 11 Dec 2015 08:29:52 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 4E20710F9; Fri, 11 Dec 2015 08:29:52 +0000 (UTC) Date: Fri, 11 Dec 2015 08:29:48 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: imp@FreeBSD.org, hiren@FreeBSD.org, araujo@FreeBSD.org, arybchik@FreeBSD.org, gshapiro@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <2053010502.1.1449822591701.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #1861 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 08:29:52 -0000 FreeBSD_HEAD_i386 - Build #1861 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1861/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1861/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1861/console Change summaries: 292091 by araujo: Fix minor typos introduced on r292084. Approved by: rodrigc (mentor) Differential Revision: https://reviews.freebsd.org/D4495 292090 by arybchik: sfxge: unify MCDI response polling Submitted by: Andy Moreton Reviewed by: philip Sponsored by: Solarflare Communications, Inc. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D4496 292088 by arybchik: sfxge: simplify MCDI methods It is a part of MCDI rework to share more code among NIC families. Submitted by: Andy Moreton Sponsored by: Solarflare Communications, Inc. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D4481 292087 by hiren: Clean up unused bandwidth entry in the TCP hostcache. Submitted by: Jason Wolfe (j at nitrology dot com) Reviewed by: rrs, hiren Sponsored by: Limelight Networks Differential Revision: https://reviews.freebsd.org/D4154 292086 by arybchik: sfxge: add tunable for maximum start attetmps after reset Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D2610 292085 by imp: Handle CPUTYPE=armv[4567]* better. gcc expects those to be either -march=foo or -mcpu=generic-foo. Catch the armvX* case and pass the right args for it. 292084 by imp: Move the inclusion of bsd.cpu.mk from sys.mk to bsd.opts.mk. However, for historical behavior that ports depends on, include it if we're inside the ports tree. Differential Review: https://reviews.freebsd.org/D4383 Ports Exp run: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205021 292083 by imp: Update for final version of mkimg changes. 292082 by imp: Add ppcboot FAT type. Needed to create a bootable powerpc image. Differential Review: https://reviews.freebsd.org/D4407 292081 by imp: Add PNP info for ISA and PCI to the ed driver to prove design. Differential Review: https://reviews.freebsd.org/D3458 292080 by imp: Create a USB_PNP_INFO and use it to export the existing PNP tables. Some drivers needed some slight re-arrangement of declarations to accommodate this. Change the USB pnp tables slightly to allow better compatibility with the system by moving linux driver info from start of each entry to the end. All other PNP tables in the system have the per-device flags and such at the end of the elements rather that at the beginning. Differential Review: https://reviews.freebsd.org/D3458 292079 by imp: Create a generic PCCARD_PNP_INFO from the MODULE_PNP_INFO building block. Use it in all the PNP drivers to export either the current PNP table. For uart, create a custom table and export it using MODULE_PNP_INFO since it's the only one that matches on function number. Differential Review: https://reviews.freebsd.org/D3461 292078 by imp: Augment kldxref to find the new MODULE_PNP_INFO records now in modules, simplify them into a more normal form and write them to linker.hints. Differential Review: https://reviews.freebsd.org/D3461 292077 by imp: Create the MDT_PNP_INFO metadata record to communicate PNP info about modules. External agents may use this data to automatically load those modules. Differential Review: https://reviews.freebsd.org/D3461 292076 by gshapiro: Retain maintership over sendmail pieces so I can keep upstream in sync 292075 by imp: o Resolve the real path to NANO_OBJ so everything that depends on it doesn't have lots of ../../foo in it. o Tweak the powerpc64 variant a bit. This gets us closer to working with qemu-system-poewrpc64, but we aren't quite there yet. The end of the build log: [...truncated 195080 lines...] --- mxge_eth_z8e.ko.full --- ld -Bshareable -d -warn-common -o mxge_eth_z8e.ko.full mxge_eth_z8e.kld --- mxge_eth_z8e.ko.debug --- objcopy --only-keep-debug mxge_eth_z8e.ko.full mxge_eth_z8e.ko.debug --- mxge_eth_z8e.ko --- objcopy --strip-debug --add-gnu-debuglink=mxge_eth_z8e.ko.debug mxge_eth_z8e.ko.full mxge_eth_z8e.ko --- db_sym.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/ddb/db_sym.c --- modules-all --- --- all_subdir_mwl --- --- mwlhal.o --- ctfconvert -L VERSION -g mwlhal.o --- if_mwl.kld --- ld -d -warn-common -r -d -o if_mwl.kld if_mwl.o if_mwl_pci.o mwlhal.o ctfmerge -L VERSION -g -o if_mwl.kld if_mwl.o if_mwl_pci.o mwlhal.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_mwl.kld export_syms | xargs -J% objcopy % if_mwl.kld --- if_mwl.ko.full --- ld -Bshareable -d -warn-common -o if_mwl.ko.full if_mwl.kld --- if_mwl.ko.debug --- objcopy --only-keep-debug if_mwl.ko.full if_mwl.ko.debug --- if_mwl.ko --- objcopy --strip-debug --add-gnu-debuglink=if_mwl.ko.debug if_mwl.ko.full if_mwl.ko --- db_thread.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/ddb/db_thread.c --- db_sym.o --- ctfconvert -L VERSION -g db_sym.o --- modules-all --- --- all_subdir_ncr --- ===> ncr (all) --- ncr.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ncr/../../dev/ncr/ncr.c -o ncr.o --- db_thread.o --- ctfconvert -L VERSION -g db_thread.o --- modules-all --- --- all_subdir_mxge --- --- all_subdir_mxge_ethp_z8e --- ===> mxge/mxge_ethp_z8e (all) --- mxge_ethp_z8e.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/mxge/mxge_ethp_z8e/../../../dev/mxge/mxge_ethp_z8e.c -o mxge_ethp_z8e.o ctfconvert -L VERSION -g mxge_ethp_z8e.o --- mxge_ethp_z8e.kld --- ld -d -warn-common -r -d -o mxge_ethp_z8e.kld mxge_ethp_z8e.o ctfmerge -L VERSION -g -o mxge_ethp_z8e.kld mxge_ethp_z8e.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk mxge_ethp_z8e.kld export_syms | xargs -J% objcopy % mxge_ethp_z8e.kld --- mxge_ethp_z8e.ko.full --- ld -Bshareable -d -warn-common -o mxge_ethp_z8e.ko.full mxge_ethp_z8e.kld --- mxge_ethp_z8e.ko.debug --- objcopy --only-keep-debug mxge_ethp_z8e.ko.full mxge_ethp_z8e.ko.debug --- mxge_ethp_z8e.ko --- objcopy --strip-debug --add-gnu-debuglink=mxge_ethp_z8e.ko.debug mxge_ethp_z8e.ko.full mxge_ethp_z8e.ko --- all_subdir_mxge_rss_eth_z8e --- ===> mxge/mxge_rss_eth_z8e (all) --- mxge_rss_eth_z8e.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/mxge/mxge_rss_eth_z8e/../../../dev/mxge/mxge_rss_eth_z8e.c -o mxge_rss_eth_z8e.o ctfconvert -L VERSION -g mxge_rss_eth_z8e.o --- mxge_rss_eth_z8e.kld --- ld -d -warn-common -r -d -o mxge_rss_eth_z8e.kld mxge_rss_eth_z8e.o ctfmerge -L VERSION -g -o mxge_rss_eth_z8e.kld mxge_rss_eth_z8e.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk mxge_rss_eth_z8e.kld export_syms | xargs -J% objcopy % mxge_rss_eth_z8e.kld --- mxge_rss_eth_z8e.ko.full --- ld -Bshareable -d -warn-common -o mxge_rss_eth_z8e.ko.full mxge_rss_eth_z8e.kld --- mxge_rss_eth_z8e.ko.debug --- objcopy --only-keep-debug mxge_rss_eth_z8e.ko.full mxge_rss_eth_z8e.ko.debug --- mxge_rss_eth_z8e.ko --- objcopy --strip-debug --add-gnu-debuglink=mxge_rss_eth_z8e.ko.debug mxge_rss_eth_z8e.ko.full mxge_rss_eth_z8e.ko --- all_subdir_mxge_rss_ethp_z8e --- ===> mxge/mxge_rss_ethp_z8e (all) --- mxge_rss_ethp_z8e.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/mxge/mxge_rss_ethp_z8e/../../../dev/mxge/mxge_rss_ethp_z8e.c -o mxge_rss_ethp_z8e.o ctfconvert -L VERSION -g mxge_rss_ethp_z8e.o --- mxge_rss_ethp_z8e.kld --- ld -d -warn-common -r -d -o mxge_rss_ethp_z8e.kld mxge_rss_ethp_z8e.o ctfmerge -L VERSION -g -o mxge_rss_ethp_z8e.kld mxge_rss_ethp_z8e.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk mxge_rss_ethp_z8e.kld export_syms | xargs -J% objcopy % mxge_rss_ethp_z8e.kld --- mxge_rss_ethp_z8e.ko.full --- ld -Bshareable -d -warn-common -o mxge_rss_ethp_z8e.ko.full mxge_rss_ethp_z8e.kld --- all_subdir_my --- ctfconvert -L VERSION -g if_my.o --- all_subdir_mxge --- --- mxge_rss_ethp_z8e.ko.debug --- objcopy --only-keep-debug mxge_rss_ethp_z8e.ko.full mxge_rss_ethp_z8e.ko.debug --- mxge_rss_ethp_z8e.ko --- objcopy --strip-debug --add-gnu-debuglink=mxge_rss_ethp_z8e.ko.debug mxge_rss_ethp_z8e.ko.full mxge_rss_ethp_z8e.ko --- db_textdump.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/ddb/db_textdump.c --- modules-all --- --- all_subdir_my --- --- if_my.kld --- ld -d -warn-common -r -d -o if_my.kld if_my.o ctfmerge -L VERSION -g -o if_my.kld if_my.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_my.kld export_syms | xargs -J% objcopy % if_my.kld --- if_my.ko.full --- ld -Bshareable -d -warn-common -o if_my.ko.full if_my.kld --- if_my.ko.debug --- objcopy --only-keep-debug if_my.ko.full if_my.ko.debug --- if_my.ko --- objcopy --strip-debug --add-gnu-debuglink=if_my.ko.debug if_my.ko.full if_my.ko --- db_variables.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/ddb/db_variables.c ctfconvert -L VERSION -g db_variables.o --- modules-all --- --- all_subdir_ncv --- ===> ncv (all) --- ncr53c500.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500.c -o ncr53c500.o --- db_textdump.o --- ctfconvert -L VERSION -g db_textdump.o --- modules-all --- --- ncr53c500_pccard.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c -o ncr53c500_pccard.o /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_probe'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_probe /usr/src/sys/dev/pccard/pccardvar.h:96:47: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:176:12: note: expanded from macro 'MODULE_PNP_INFO' .table = t, \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:211:1: note: 'ncv_pccard_probe' declared here ncv_pccard_probe(device_t dev) ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_methods'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_methods /usr/src/sys/dev/pccard/pccardvar.h:96:57: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:177:16: note: expanded from macro 'MODULE_PNP_INFO' .entry_len = l, \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:277:24: note: 'ncv_pccard_methods' declared here static device_method_t ncv_pccard_methods[] = { ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_probe'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_probe /usr/src/sys/dev/pccard/pccardvar.h:96:71: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:178:16: note: expanded from macro 'MODULE_PNP_INFO' .num_entry = n \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:211:1: note: 'ncv_pccard_probe' declared here ncv_pccard_probe(device_t dev) ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:1: error: invalid application of 'sizeof' to a function type [-Werror,-Wpointer-arith] PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/dev/pccard/pccardvar.h:96:70: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ /usr/src/sys/sys/module.h:178:16: note: expanded from macro 'MODULE_PNP_INFO' .num_entry = n \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_methods'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_methods /usr/src/sys/dev/pccard/pccardvar.h:96:83: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:178:16: note: expanded from macro 'MODULE_PNP_INFO' .num_entry = n \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:277:24: note: 'ncv_pccard_methods' declared here static device_method_t ncv_pccard_methods[] = { ^ 5 errors generated. *** [ncr53c500_pccard.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/ncv --- ncr53c500.o --- ctfconvert -L VERSION -g ncr53c500.o 1 error make[4]: stopped in /usr/src/sys/modules/ncv *** [all_subdir_ncv] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_ncr --- ctfconvert -L VERSION -g ncr.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/ncr *** [all_subdir_ncr] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_mxge --- --- all_subdir_mxge --- ctfconvert -L VERSION -g if_mxge.o A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/sys/modules/mxge/mxge *** [all_subdir_mxge] Error code 2 make[4]: stopped in /usr/src/sys/modules/mxge 1 error make[4]: stopped in /usr/src/sys/modules/mxge *** [all_subdir_mxge] Error code 2 make[3]: stopped in /usr/src/sys/modules 3 errors make[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /usr/obj/usr/src/sys/GENERIC 1 error make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson1232556758768370218.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Fri Dec 11 12:16:58 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DC2C9D54B3; Fri, 11 Dec 2015 12:16:58 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 21B251256; Fri, 11 Dec 2015 12:16:58 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5ACD0116F; Fri, 11 Dec 2015 12:16:58 +0000 (UTC) Date: Fri, 11 Dec 2015 12:16:54 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: bapt@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <427237084.3.1449836218275.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2053010502.1.1449822591701.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2053010502.1.1449822591701.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #1862 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 12:16:58 -0000 FreeBSD_HEAD_i386 - Build #1862 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1862/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1862/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1862/console Change summaries: 292093 by bapt: sesutils, pass the correct element type when printing the status of a given element of the ses. Sponsored by: Gandi.net 292092 by bapt: sesutil: fix map not printing the status of the LED device in an array Sponsored by: Gandi.net The end of the build log: [...truncated 196126 lines...] ctfconvert -L VERSION -g mxge_eth_z8e.o --- mxge_eth_z8e.kld --- ld -d -warn-common -r -d -o mxge_eth_z8e.kld mxge_eth_z8e.o ctfmerge -L VERSION -g -o mxge_eth_z8e.kld mxge_eth_z8e.o --- db_run.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/ddb/db_run.c --- modules-all --- :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk mxge_eth_z8e.kld export_syms | xargs -J% objcopy % mxge_eth_z8e.kld --- mxge_eth_z8e.ko.full --- ld -Bshareable -d -warn-common -o mxge_eth_z8e.ko.full mxge_eth_z8e.kld --- mxge_eth_z8e.ko.debug --- objcopy --only-keep-debug mxge_eth_z8e.ko.full mxge_eth_z8e.ko.debug --- mxge_eth_z8e.ko --- objcopy --strip-debug --add-gnu-debuglink=mxge_eth_z8e.ko.debug mxge_eth_z8e.ko.full mxge_eth_z8e.ko --- db_ps.o --- ctfconvert -L VERSION -g db_ps.o --- modules-all --- --- all_subdir_my --- ===> my (all) --- if_my.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/my/../../dev/my/if_my.c -o if_my.o --- db_run.o --- ctfconvert -L VERSION -g db_run.o --- modules-all --- --- all_subdir_ncr --- ===> ncr (all) --- ncr.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ncr/../../dev/ncr/ncr.c -o ncr.o --- all_subdir_mwl --- --- if_mwl.o --- ctfconvert -L VERSION -g if_mwl.o --- if_mwl.kld --- ld -d -warn-common -r -d -o if_mwl.kld if_mwl.o if_mwl_pci.o mwlhal.o ctfmerge -L VERSION -g -o if_mwl.kld if_mwl.o if_mwl_pci.o mwlhal.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_mwl.kld export_syms | xargs -J% objcopy % if_mwl.kld --- if_mwl.ko.full --- ld -Bshareable -d -warn-common -o if_mwl.ko.full if_mwl.kld --- if_mwl.ko.debug --- objcopy --only-keep-debug if_mwl.ko.full if_mwl.ko.debug --- if_mwl.ko --- objcopy --strip-debug --add-gnu-debuglink=if_mwl.ko.debug if_mwl.ko.full if_mwl.ko --- all_subdir_mxge --- --- all_subdir_mxge_ethp_z8e --- ===> mxge/mxge_ethp_z8e (all) --- mxge_ethp_z8e.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/mxge/mxge_ethp_z8e/../../../dev/mxge/mxge_ethp_z8e.c -o mxge_ethp_z8e.o ctfconvert -L VERSION -g mxge_ethp_z8e.o --- mxge_ethp_z8e.kld --- ld -d -warn-common -r -d -o mxge_ethp_z8e.kld mxge_ethp_z8e.o ctfmerge -L VERSION -g -o mxge_ethp_z8e.kld mxge_ethp_z8e.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk mxge_ethp_z8e.kld export_syms | xargs -J% objcopy % mxge_ethp_z8e.kld --- mxge_ethp_z8e.ko.full --- ld -Bshareable -d -warn-common -o mxge_ethp_z8e.ko.full mxge_ethp_z8e.kld --- mxge_ethp_z8e.ko.debug --- objcopy --only-keep-debug mxge_ethp_z8e.ko.full mxge_ethp_z8e.ko.debug --- mxge_ethp_z8e.ko --- objcopy --strip-debug --add-gnu-debuglink=mxge_ethp_z8e.ko.debug mxge_ethp_z8e.ko.full mxge_ethp_z8e.ko --- all_subdir_ncv --- ===> ncv (all) --- ncr53c500.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500.c -o ncr53c500.o --- all_subdir_my --- ctfconvert -L VERSION -g if_my.o --- if_my.kld --- ld -d -warn-common -r -d -o if_my.kld if_my.o ctfmerge -L VERSION -g -o if_my.kld if_my.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_my.kld export_syms | xargs -J% objcopy % if_my.kld --- if_my.ko.full --- ld -Bshareable -d -warn-common -o if_my.ko.full if_my.kld --- if_my.ko.debug --- objcopy --only-keep-debug if_my.ko.full if_my.ko.debug --- if_my.ko --- objcopy --strip-debug --add-gnu-debuglink=if_my.ko.debug if_my.ko.full if_my.ko --- db_script.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/ddb/db_script.c ctfconvert -L VERSION -g db_script.o --- modules-all --- --- all_subdir_mxge --- --- all_subdir_mxge_rss_eth_z8e --- ===> mxge/mxge_rss_eth_z8e (all) --- mxge_rss_eth_z8e.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/mxge/mxge_rss_eth_z8e/../../../dev/mxge/mxge_rss_eth_z8e.c -o mxge_rss_eth_z8e.o ctfconvert -L VERSION -g mxge_rss_eth_z8e.o --- mxge_rss_eth_z8e.kld --- ld -d -warn-common -r -d -o mxge_rss_eth_z8e.kld mxge_rss_eth_z8e.o ctfmerge -L VERSION -g -o mxge_rss_eth_z8e.kld mxge_rss_eth_z8e.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk mxge_rss_eth_z8e.kld export_syms | xargs -J% objcopy % mxge_rss_eth_z8e.kld --- mxge_rss_eth_z8e.ko.full --- ld -Bshareable -d -warn-common -o mxge_rss_eth_z8e.ko.full mxge_rss_eth_z8e.kld --- mxge_rss_eth_z8e.ko.debug --- objcopy --only-keep-debug mxge_rss_eth_z8e.ko.full mxge_rss_eth_z8e.ko.debug --- mxge_rss_eth_z8e.ko --- objcopy --strip-debug --add-gnu-debuglink=mxge_rss_eth_z8e.ko.debug mxge_rss_eth_z8e.ko.full mxge_rss_eth_z8e.ko --- all_subdir_ncv --- --- ncr53c500_pccard.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c -o ncr53c500_pccard.o --- ncr53c500.o --- ctfconvert -L VERSION -g ncr53c500.o --- all_subdir_ndis --- ===> ndis (all) --- subr_pe.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ndis/../../compat/ndis/subr_pe.c -o subr_pe.o --- all_subdir_ncv --- --- ncr53c500_pccard.o --- /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_probe'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_probe /usr/src/sys/dev/pccard/pccardvar.h:96:47: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:176:12: note: expanded from macro 'MODULE_PNP_INFO' .table = t, \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:211:1: note: 'ncv_pccard_probe' declared here ncv_pccard_probe(device_t dev) ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_methods'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_methods /usr/src/sys/dev/pccard/pccardvar.h:96:57: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:177:16: note: expanded from macro 'MODULE_PNP_INFO' .entry_len = l, \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:277:24: note: 'ncv_pccard_methods' declared here static device_method_t ncv_pccard_methods[] = { ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_probe'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_probe /usr/src/sys/dev/pccard/pccardvar.h:96:71: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:178:16: note: expanded from macro 'MODULE_PNP_INFO' .num_entry = n \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:211:1: note: 'ncv_pccard_probe' declared here ncv_pccard_probe(device_t dev) ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:1: error: invalid application of 'sizeof' to a function type [-Werror,-Wpointer-arith] PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/dev/pccard/pccardvar.h:96:70: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ /usr/src/sys/sys/module.h:178:16: note: expanded from macro 'MODULE_PNP_INFO' .num_entry = n \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_methods'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_methods /usr/src/sys/dev/pccard/pccardvar.h:96:83: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:178:16: note: expanded from macro 'MODULE_PNP_INFO' .num_entry = n \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:277:24: note: 'ncv_pccard_methods' declared here static device_method_t ncv_pccard_methods[] = { ^ 5 errors generated. *** [ncr53c500_pccard.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/ncv 1 error make[4]: stopped in /usr/src/sys/modules/ncv *** [all_subdir_ncv] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_ncr --- ctfconvert -L VERSION -g ncr.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/ncr *** [all_subdir_ncr] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_ndis --- ctfconvert -L VERSION -g subr_pe.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/ndis *** [all_subdir_ndis] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_mxge --- --- all_subdir_mxge --- ctfconvert -L VERSION -g if_mxge.o A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/sys/modules/mxge/mxge *** [all_subdir_mxge] Error code 2 make[4]: stopped in /usr/src/sys/modules/mxge 1 error make[4]: stopped in /usr/src/sys/modules/mxge *** [all_subdir_mxge] Error code 2 make[3]: stopped in /usr/src/sys/modules 4 errors make[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /usr/obj/usr/src/sys/GENERIC 1 error make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson9047514927438786702.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Fri Dec 11 12:26:37 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4731A9D5E1A for ; Fri, 11 Dec 2015 12:26:37 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from graal.it-profi.org.ua (graal.shurik.kiev.ua [193.239.74.7]) (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 087151C9A for ; Fri, 11 Dec 2015 12:26:36 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from [109.237.91.29] (helo=thinkpad.it-profi.org.ua) by graal.it-profi.org.ua with esmtpa (Exim 4.86 (FreeBSD)) (envelope-from ) id 1a7MKv-0002Ic-Gi for freebsd-current@freebsd.org; Fri, 11 Dec 2015 13:58:09 +0200 From: Alexandr Krivulya Subject: Re: Upgrading to r297291 LAGG(4) stops working. To: freebsd-current@freebsd.org References: <20150901084440.GJ56997@glebius.int.ru> X-Enigmail-Draft-Status: N1110 Message-ID: <566ABA4C.5020505@shurik.kiev.ua> Date: Fri, 11 Dec 2015 13:58:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20150901084440.GJ56997@glebius.int.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 109.237.91.29 X-SA-Exim-Mail-From: shuriku@shurik.kiev.ua X-SA-Exim-Scanned: No (on graal.it-profi.org.ua); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 12:26:37 -0000 01.09.15 11:44, Gleb Smirnoff пишет: > On Mon, Aug 31, 2015 at 09:58:45AM -0700, Adrian Chadd wrote: > A> Hi, > A> > A> +glebius, as he recently messed around with the wifi stack and his > A> changes may have broken how mac addresses are assigned to the > A> hardware. > > I've tested that with new code setting MAC address on wlan0 passed it > down to device driver (iwn in my case). > > As Adrian already noted to Ranjan, his setup worked only by accident :) > If it were not ath(4), but some more dumb WiFi device, the setup wouldn't > work. > Hi, On my -HEAD network traffic passes through re0 only when re0 is in promisc mode. It was not required earlier. Is it necessary now? My configuration is: wlans_iwn0="wlan0" ifconfig_wlan0="WPA country UA" ifconfig_re0="ether 68:5d:43:92:3a:88 promisc" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport re0 laggport wlan0 DHCP" From owner-freebsd-current@freebsd.org Fri Dec 11 16:16:36 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 515BA9D7A9F; Fri, 11 Dec 2015 16:16:36 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 35C33147F; Fri, 11 Dec 2015 16:16:36 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 514F511EF; Fri, 11 Dec 2015 16:16:36 +0000 (UTC) Date: Fri, 11 Dec 2015 16:16:33 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: lidl@FreeBSD.org, emaste@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1696732066.5.1449850596300.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <427237084.3.1449836218275.JavaMail.jenkins@jenkins-9.freebsd.org> References: <427237084.3.1449836218275.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #1863 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 16:16:36 -0000 FreeBSD_HEAD_i386 - Build #1863 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1863/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1863/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1863/console Change summaries: 292110 by lidl: Fixup include protections for building on mips64 with clang Reviewed by: sbruno, imp Approved by: rpaulo (mentor) Differential Revision: https://reviews.freebsd.org/D4457 292106 by emaste: crunchide: add RISC-V to supported machine types MFC after: 1 week Sponsored by: The FreeBSD Foundation The end of the build log: [...truncated 195838 lines...] awk -f /usr/src/sys/conf/kmod_syms.awk mxge_ethp_z8e.kld export_syms | xargs -J% objcopy % mxge_ethp_z8e.kld --- mxge_ethp_z8e.ko.full --- ld -Bshareable -d -warn-common -o mxge_ethp_z8e.ko.full mxge_ethp_z8e.kld --- mxge_ethp_z8e.ko.debug --- objcopy --only-keep-debug mxge_ethp_z8e.ko.full mxge_ethp_z8e.ko.debug --- mxge_ethp_z8e.ko --- objcopy --strip-debug --add-gnu-debuglink=mxge_ethp_z8e.ko.debug mxge_ethp_z8e.ko.full mxge_ethp_z8e.ko --- all_subdir_mxge_rss_ethp_z8e --- ===> mxge/mxge_rss_ethp_z8e (all) --- all_subdir_mwl --- --- if_mwl.ko.debug --- objcopy --only-keep-debug if_mwl.ko.full if_mwl.ko.debug --- all_subdir_mxge --- --- all_subdir_mxge_rss_eth_z8e --- ctfconvert -L VERSION -g mxge_rss_eth_z8e.o --- all_subdir_mwl --- --- if_mwl.ko --- --- all_subdir_mxge --- --- mxge_rss_eth_z8e.kld --- --- all_subdir_mwl --- objcopy --strip-debug --add-gnu-debuglink=if_mwl.ko.debug if_mwl.ko.full if_mwl.ko --- all_subdir_mxge --- --- all_subdir_mxge_rss_ethp_z8e --- --- mxge_rss_ethp_z8e.o --- --- all_subdir_mxge_rss_eth_z8e --- ld -d -warn-common -r -d -o mxge_rss_eth_z8e.kld mxge_rss_eth_z8e.o --- all_subdir_mxge_rss_ethp_z8e --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/mxge/mxge_rss_ethp_z8e/../../../dev/mxge/mxge_rss_ethp_z8e.c -o mxge_rss_ethp_z8e.o --- all_subdir_mxge_rss_eth_z8e --- ctfmerge -L VERSION -g -o mxge_rss_eth_z8e.kld mxge_rss_eth_z8e.o --- des_ecb.o --- --- modules-all --- :> export_syms --- des_ecb.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/crypto/des/des_ecb.c --- modules-all --- awk -f /usr/src/sys/conf/kmod_syms.awk mxge_rss_eth_z8e.kld export_syms | xargs -J% objcopy % mxge_rss_eth_z8e.kld --- mxge_rss_eth_z8e.ko.full --- ld -Bshareable -d -warn-common -o mxge_rss_eth_z8e.ko.full mxge_rss_eth_z8e.kld --- mxge_rss_eth_z8e.ko.debug --- objcopy --only-keep-debug mxge_rss_eth_z8e.ko.full mxge_rss_eth_z8e.ko.debug --- mxge_rss_eth_z8e.ko --- --- des_setkey.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/crypto/des/des_setkey.c --- modules-all --- objcopy --strip-debug --add-gnu-debuglink=mxge_rss_eth_z8e.ko.debug mxge_rss_eth_z8e.ko.full mxge_rss_eth_z8e.ko --- all_subdir_mxge_rss_ethp_z8e --- ctfconvert -L VERSION -g mxge_rss_ethp_z8e.o --- mxge_rss_ethp_z8e.kld --- --- des_ecb.o --- ctfconvert -L VERSION -g des_ecb.o --- modules-all --- ld -d -warn-common -r -d -o mxge_rss_ethp_z8e.kld mxge_rss_ethp_z8e.o ctfmerge -L VERSION -g -o mxge_rss_ethp_z8e.kld mxge_rss_ethp_z8e.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk mxge_rss_ethp_z8e.kld export_syms | xargs -J% objcopy % mxge_rss_ethp_z8e.kld --- all_subdir_my --- ===> my (all) --- all_subdir_mxge --- --- mxge_rss_ethp_z8e.ko.full --- ld -Bshareable -d -warn-common -o mxge_rss_ethp_z8e.ko.full mxge_rss_ethp_z8e.kld --- mxge_rss_ethp_z8e.ko.debug --- objcopy --only-keep-debug mxge_rss_ethp_z8e.ko.full mxge_rss_ethp_z8e.ko.debug --- mxge_rss_ethp_z8e.ko --- --- rijndael-alg-fst.o --- cc -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/crypto/rijndael/rijndael-alg-fst.c --- modules-all --- objcopy --strip-debug --add-gnu-debuglink=mxge_rss_ethp_z8e.ko.debug mxge_rss_ethp_z8e.ko.full mxge_rss_ethp_z8e.ko --- all_subdir_my --- --- if_my.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/my/../../dev/my/if_my.c -o if_my.o --- des_setkey.o --- ctfconvert -L VERSION -g des_setkey.o --- modules-all --- --- all_subdir_ncr --- ===> ncr (all) --- ncr.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ncr/../../dev/ncr/ncr.c -o ncr.o --- rijndael-alg-fst.o --- ctfconvert -L VERSION -g rijndael-alg-fst.o --- modules-all --- --- all_subdir_ncv --- ===> ncv (all) --- ncr53c500.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500.c -o ncr53c500.o --- all_subdir_my --- ctfconvert -L VERSION -g if_my.o --- if_my.kld --- ld -d -warn-common -r -d -o if_my.kld if_my.o ctfmerge -L VERSION -g -o if_my.kld if_my.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_my.kld export_syms | xargs -J% objcopy % if_my.kld --- if_my.ko.full --- ld -Bshareable -d -warn-common -o if_my.ko.full if_my.kld --- if_my.ko.debug --- objcopy --only-keep-debug if_my.ko.full if_my.ko.debug --- if_my.ko --- objcopy --strip-debug --add-gnu-debuglink=if_my.ko.debug if_my.ko.full if_my.ko --- all_subdir_ncv --- --- ncr53c500_pccard.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c -o ncr53c500_pccard.o --- ncr53c500.o --- ctfconvert -L VERSION -g ncr53c500.o --- all_subdir_ndis --- ===> ndis (all) --- subr_pe.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/ndis/../../compat/ndis/subr_pe.c -o subr_pe.o --- all_subdir_ncv --- --- ncr53c500_pccard.o --- /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_probe'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_probe /usr/src/sys/dev/pccard/pccardvar.h:96:47: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:176:12: note: expanded from macro 'MODULE_PNP_INFO' .table = t, \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:211:1: note: 'ncv_pccard_probe' declared here ncv_pccard_probe(device_t dev) ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_methods'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_methods /usr/src/sys/dev/pccard/pccardvar.h:96:57: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:177:16: note: expanded from macro 'MODULE_PNP_INFO' .entry_len = l, \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:277:24: note: 'ncv_pccard_methods' declared here static device_method_t ncv_pccard_methods[] = { ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_probe'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_probe /usr/src/sys/dev/pccard/pccardvar.h:96:71: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:178:16: note: expanded from macro 'MODULE_PNP_INFO' .num_entry = n \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:211:1: note: 'ncv_pccard_probe' declared here ncv_pccard_probe(device_t dev) ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:1: error: invalid application of 'sizeof' to a function type [-Werror,-Wpointer-arith] PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/dev/pccard/pccardvar.h:96:70: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ /usr/src/sys/sys/module.h:178:16: note: expanded from macro 'MODULE_PNP_INFO' .num_entry = n \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:296:17: error: use of undeclared identifier 'ncv_pccard_products'; did you mean 'ncv_pccard_methods'? PCCARD_PNP_INFO(ncv_pccard_products); ^~~~~~~~~~~~~~~~~~~ ncv_pccard_methods /usr/src/sys/dev/pccard/pccardvar.h:96:83: note: expanded from macro 'PCCARD_PNP_INFO' MODULE_PNP_INFO(PCCARD_PNP_DESCR, pccard, t, t, sizeof(t[0]), sizeof(t) / sizeof(t[0])); \ ^ /usr/src/sys/sys/module.h:178:16: note: expanded from macro 'MODULE_PNP_INFO' .num_entry = n \ ^ /usr/src/sys/modules/ncv/../../dev/ncv/ncr53c500_pccard.c:277:24: note: 'ncv_pccard_methods' declared here static device_method_t ncv_pccard_methods[] = { ^ 5 errors generated. *** [ncr53c500_pccard.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/ncv 1 error make[4]: stopped in /usr/src/sys/modules/ncv *** [all_subdir_ncv] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_ndis --- ctfconvert -L VERSION -g subr_pe.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/ndis *** [all_subdir_ndis] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_ncr --- ctfconvert -L VERSION -g ncr.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/ncr *** [all_subdir_ncr] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_mxge --- --- all_subdir_mxge --- ctfconvert -L VERSION -g if_mxge.o A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/sys/modules/mxge/mxge *** [all_subdir_mxge] Error code 2 make[4]: stopped in /usr/src/sys/modules/mxge 1 error make[4]: stopped in /usr/src/sys/modules/mxge *** [all_subdir_mxge] Error code 2 make[3]: stopped in /usr/src/sys/modules 4 errors make[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /usr/obj/usr/src/sys/GENERIC 1 error make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson7207457667702332798.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_i386' + echo 'clean up jail FreeBSD_HEAD_i386' clean up jail FreeBSD_HEAD_i386 + sudo jail -r FreeBSD_HEAD_i386 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias + sudo umount FreeBSD_HEAD_i386/usr/src + sudo umount FreeBSD_HEAD_i386/dev + sudo rm -fr FreeBSD_HEAD_i386 + true + sudo chflags -R noschg FreeBSD_HEAD_i386 + sudo rm -fr FreeBSD_HEAD_i386 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Fri Dec 11 16:33:52 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99F0D9D8908 for ; Fri, 11 Dec 2015 16:33:52 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5073714D2 for ; Fri, 11 Dec 2015 16:33:52 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 4DE849D8907; Fri, 11 Dec 2015 16:33:52 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D5909D8905; Fri, 11 Dec 2015 16:33:52 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B649514D1; Fri, 11 Dec 2015 16:33:51 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from CO2PR05CA027.namprd05.prod.outlook.com (10.141.241.155) by BY1PR0501MB1384.namprd05.prod.outlook.com (10.160.107.142) with Microsoft SMTP Server (TLS) id 15.1.337.19; Fri, 11 Dec 2015 16:18:00 +0000 Received: from BL2FFO11FD032.protection.gbl (2a01:111:f400:7c09::190) by CO2PR05CA027.outlook.office365.com (2a01:111:e400:1429::27) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Fri, 11 Dec 2015 16:18:00 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BL2FFO11FD032.mail.protection.outlook.com (10.173.160.73) with Microsoft SMTP Server (TLS) id 15.1.346.13 via Frontend Transport; Fri, 11 Dec 2015 16:17:59 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 11 Dec 2015 08:17:59 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tBBGHvD47284; Fri, 11 Dec 2015 08:17:57 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [IPv6:::1]) by chaos.jnpr.net (Postfix) with ESMTP id 08CAC580A9; Fri, 11 Dec 2015 08:17:57 -0800 (PST) To: Julian Elischer CC: Bryan Drewery , , , Subject: Re: My build work and goals In-Reply-To: <566A70B8.3060609@freebsd.org> References: <5669D8E9.8060000@FreeBSD.org> <566A70B8.3060609@freebsd.org> Comments: In-reply-to: Julian Elischer message dated "Fri, 11 Dec 2015 14:44:08 +0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6346.1449850676.1@chaos> Date: Fri, 11 Dec 2015 08:17:57 -0800 Message-ID: <16127.1449850677@chaos> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD032; 1:mUiet7CuRvtf6G2/UvnLrYmwNZmUOoygBmlCPnpl1mU7KKa30KBTCUCWNGrFCXHoL+Yqeaxwrm6cUa6LeNIHsq51wEkKOKVssOrQhtKfqhRkjIOAT/dQ5VQsJiSuJLHocaXV9G3hdHvi3OlxEFWl5qBF1zSu6CbpAp5/foFSDpHUBolavsHZGFaGEiOnPfQK3Ht9v7aZTVSRj3pPzOhbMPPgsmp3ExWstXcmdfW+btfZ9nd8XlThHPdzJyimW/P7vKSdO0Dpouq90s13zltr07ijfr2h1xweqg0HybUMNXLkHgFkYcK949lm8T8oRp+ZUPAtIm17iW/PWgG2o7Fq1NqFGwugGOXrfdl3nMmY+xY= X-Forefront-Antispam-Report: CIP:66.129.239.19; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(24454002)(189002)(4001430100002)(189998001)(586003)(117636001)(69596002)(1096002)(33716001)(19580405001)(106466001)(76506005)(97756001)(1220700001)(6806005)(5008740100001)(47776003)(11100500001)(19580395003)(23726003)(50466002)(86362001)(76176999)(97736004)(57986006)(46406003)(105596002)(2950100001)(92566002)(450100001)(50226001)(50986999)(87936001)(107886002)(81156007)(5001960100002)(110136002)(77096005)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1384; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1384; 2:VlIdXmpiJyUIFeMcwWLl3hQ7k1JN2VV82c/dYjWQTGhCZMSXrHgErcVpjIKM3+hZRvJ3pzTAvvr6sIMQUno8z1av09wKFSwCeJGep+yp3jsB+whAb34RzWCrPnnKXoUmV2pFeQEXG7vwZMFTUmIFqg==; 3:nss/yYycecgPR9FrX3Ai3Pek86BVZBa2qKZS0+Ztb0JPLiThdkQlSJWsgxq8yifcriQCNWArrJ0vK9R+HEICjuGyjuZxOC9KWoSVWvUye4eJ3sL8/kI7dWXDljEKdZ8MZ0Gy+BBDJDqoo136e5GudRnEO5hi/+jYq10u7dvdb18fR/bhNH/2SeB1+uB+z/iluvpk5aXUKc8lRaLFX+9LnPVHliHA1iRoUoaqu3GBgPA=; 25:cvKbTqZenjovMfeBkg6JfwH2Yphl+Ra7YkdNtOIoaROZGIfv8hwsEIHixZGiYMmOLPNunF/vJ7R2iKPGYPFrhiX2rE8Ha4L6iQJ6ZxsP6lDszNA991h5FXnUfftN1m0zzdJ+rqJWWWW6wC10gsRgFMxFM7x0wG/0YxzO4hj5FIPBfNCiZQYl7dE9L3olNnwJuFRuBGy9wQeAwCiRFTXP4OHuT5X/357fmmpuvEtnyWEmLPQj2POqRexMJ/ZfxEfauVdDv1p23wCzggklQGU7lQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1384; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1384; 20:L6yb1yUlKWO948uMdyg3YrzRmV/vGOpczNeTl7DWHw1zbL3laXKT3XLtZL2gMZ55I1nZ1UotTNx4Ja/+1Z5gP6C3f/mIXQTEu+6zWAVywVIhaigPhYEKN9SvkPimN6v4LccwkoNexdTCdfDMb8M+Ahj2MyWkwWPR5ZJegQr13uvlijYxxAOWJxb661/hTQxUoOPwXYQWLR3bdg467BBoxJUvN++6cUxYUl7pZ6T+OB8CRQItred8+3DRjBvNVHrWYcMFzeVQw1PrgGpqRUaIQ+F6IYybnYV2J7jpGKA94QlNr2dqDYkjfYVnKnLpjrkg8f/I941CWeCesuwcQUZMfc7wgsiknGpNhF+wv7Q9krMAYiAc+ym1rao1srYVWoHDDhLq09fgnZQIfyLKL/fxQBbx/4/wNH7HYks14M2jAzkr0ORXj2SGg/TMWybXwHxobMPMvqJjly/yhBw1cETCyylPQ57bFKAe8wGk//Sdfv2LYv7aBcen8GOF3xuqkoNR; 4:HNHHXEO6R9fZExjhktsZ1PUy0LSvpTyEODcVb30BTSYMPRj9CLtqzSloV3yRh9PRFXvw3RzxASEOD8DgXOOSRKEhXEsJ7/9gWYkGP++ogsZQ5VAsyRJyuFIuukE6nacyEt/dTNBm2WnV8a3mEgRvkdRwRKIRd0dDkkg3qegNtKs/CCVOrDf6w6pBV4W5zVFaNtKStqlXhgaTIh20rrcHITRttpk5Or/VDLjoCXN4skPx9/q36xhIw+/AuXzDfa9uNiZvky19UyoL9coj2X3nc8zk7XzVoE8jg59rM6zkrx5O78o8f+UpvDc8sNuJB7kzQWmALd5lgHKDAQcI+c/7QH48wF6shUe1XH7od6Tlhec8B2rQ0xswG1f43t6eaC6a X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY1PR0501MB1384; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1384; X-Forefront-PRVS: 0787459938 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0501MB1384; 23:YyWfLnplbDaLhjVl1THLvp8SRO4B7c9ZvUv1L3t?= =?us-ascii?Q?ywErXgB4MGWf4eSDp8+ENvgCaQcDfw7zUp6yDbuiru5Y2oJu8wnXUA56w3kx?= =?us-ascii?Q?x13dqTWvurEHg/mbdqAcBE8PWJmshMRsHOMHkR/zIF3iUiTdYiUnzksCYZEq?= =?us-ascii?Q?dxMDpRwhORbQJZTIuH4a3ZKdbJCzhClEHysZZUygWFdeDCNGoxuHeWmyGVYS?= =?us-ascii?Q?MWBpporU6orlhK8uqA6TNQN/zJp2s3iNEdBRbQZARmo+TNIfAPRrFZCHIpR1?= =?us-ascii?Q?oufkQ4p2jFFW0o438xskzHMoS/T9o5mLy7LAPFIBpzNYhyLTpCEMAOX8EP+Y?= =?us-ascii?Q?uokBE0qMF2PbmBqBzop8XoZcpZD6GnkShkbIMjaLRVjHnTyx36mK5rc1v0Wx?= =?us-ascii?Q?O+ky1Y3JtH8iKHwWxGyN/sZsR4nwUx1ivmrvO6H2mfQSA3NM1MwzJQhKo9kt?= =?us-ascii?Q?DyB3HOrzPsfTf1bbVdUmxJc6+H+uuWH6/NNCo+p2EnwFtECXfVsbG32IcjIv?= =?us-ascii?Q?CS1gIL2PYl84WhKEzNYUSu1DXklUL5ihJHjCMhvt4CXnPhrjYbvssFUIs/e1?= =?us-ascii?Q?C/E3a5TRBOMMO6Sfx2rMIAnvwhDYBQiVvNSLpczWt3u0zV70gg1wota5kKRk?= =?us-ascii?Q?AZhZDwT30HTaGj57qz4NosqS8cyC/BXIfpx9r4CVe4KUPMCRksLTqszEj5VU?= =?us-ascii?Q?2JS8F8JN1AhD4ww8ZtFZbLfU1duwLvA81cTdj3aVuAPpQCSAUYZ2KPWYgXz8?= =?us-ascii?Q?bYi6vmCP+LcW6yJt3whCWyREmF5zO6goPPe5bu91lhOng+CyfDfUwAtRsvz/?= =?us-ascii?Q?vWf/l8G5C/EJylAjx/9Ms+lKXFcNvonNZHhtQauS9AU498IohttP6ZSA93oS?= =?us-ascii?Q?oLmzzKKMzKvxCTRSfa0xy/GW++A2sCndYBnki2Unr+Il+PzCE8RCnUuitfkX?= =?us-ascii?Q?goWgw9de9zoGvGFvNIf9/v0EgwodYoqqv95BfEuc3daRIroRyjmnQdzrP+dR?= =?us-ascii?Q?RPvPj+e24pUqSmu2/cl/3lnwW0R4KycGqPSYqAYpWBU2W8a4+RJJO2xktf6q?= =?us-ascii?Q?5rAtgOBsPrlrekrVCkXx7vR92xDIWGzHQSOWyQHRxcY0KzQwIKOKzJ/yki2M?= =?us-ascii?Q?XMoa14iRo0QWpZ/eFOCwtqF25zgd6e5eP?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1384; 5:BUxAaEAld4gM0yhK6rNnP4gCzwMLbyLZSCdDF1cTm/SO18Hf95FoRlgLEjAOPVZPPFlWEL7cZYfBuQ9+FV+27ZoK+phvSiZchnS7Ev+FXNkYpBLDBmXRvkKY8yP5K401sdgqbiftVC9/55DDKc/7kQ==; 24:xWwIT2VMnhv4rGgz64ypoBzdFu+UFFAbObFE3nHKCBtmYBqUSm9q8l+hD7YokvSzAOGipzdZm8DYkGJpADjchqWireoMRl2upaFVz1/j2C0= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2015 16:17:59.6535 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1384 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 16:33:52 -0000 Julian Elischer wrote: > > Some improvements I have made recently: > > - WITH_FAST_DEPEND: Replacing the antiquated 'make depend'/'mkdep' with > > compiler dependency flags to generate the .depend files as a side-effect > > of compiling. This saves tremendous time in buildworld and buildkernel. > > Mach used to have this through their entire (bsd 4.3) tree. I forget Junos built this way for over 10 years but it only helps for the C/C++ code. From owner-freebsd-current@freebsd.org Fri Dec 11 17:05:45 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D81A69D821A for ; Fri, 11 Dec 2015 17:05:45 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96C881845 for ; Fri, 11 Dec 2015 17:05:45 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-16-z2.arcor-online.net (mail-in-16-z2.arcor-online.net [151.189.8.33]) by mx.arcor.de (Postfix) with ESMTP id 3pHHkT4CC1zwSb5 for ; Fri, 11 Dec 2015 17:34:09 +0100 (CET) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-16-z2.arcor-online.net (Postfix) with ESMTP id 8486F21645E for ; Fri, 11 Dec 2015 17:34:09 +0100 (CET) Received: from webmail08.arcor-online.net (webmail08.arcor-online.net [151.189.8.44]) by mail-in-16.arcor-online.net (Postfix) with ESMTP id 3pHHkT3jSpzCQZq for ; Fri, 11 Dec 2015 17:34:09 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-16.arcor-online.net 3pHHkT3jSpzCQZq DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1449851649; bh=V2Agbyls/SjyQWr6j1K+zQTHnpHNOt0h3rKf1abv3RQ=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=XBmQ8IfSFnLqFH3OtpiVLVOMtCkdsa6r9g6A7UINih4cuHHKkfWKaLq1ktWcRRGnt zFAxHWKNzVBJxqbByoc669zY+dv0wcB8PJvH8FM7w+h70zf4ugP8/zAkgCMm0bugZS GvPByiEZE7idJOer3Qi+6LoQBW5J3z7u0wSoPZnk= Received: from [217.92.152.234] by webmail08.arcor-online.net (151.189.8.44) with HTTP (Arcor Webmail); Fri, 11 Dec 2015 17:34:09 +0100 (CET) Date: Fri, 11 Dec 2015 17:34:09 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <1812473578.396927.1449851649511.JavaMail.ngmail@webmail08.arcor-online.net> Subject: Partitioning on a MBR table disk fails (and destroys my data...) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 217.92.152.234 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 17:05:45 -0000 Hello, I had not been succesful in partitioning and MBR disk for FreeBSD. I have only one free primary partition where I had installed NetBSD and OpenBSD alternatively since many years. The free space on the disk is divided into three parts: one for NetBSD, one for OpenBSD and one left for FreeBSD. When I did change from one BSD to the other I edited the MBR (start sector, end sector and type a6/a9). Before now installing FreeBSD for the first time (did use qemu in the past) I adjusted the sectorss to the FreeBSD range and changed to type a5, then erased the first sectors of that partition. While NetBSD and OpenBSD autoselect their a9/a6 partitions, FreeBSD sees it's partition but doesn't allow to add BSD partitions for e.g. / or swap (no space left...). So I deleted the prepared partition and added a new one. The size the tool told me was too large (sum of free space on the disk) but after it was added a different size had been shown--that which I had reserved for FreeBSD (so there is a bug in the install tool). After installation I saw that it had overwritten the over BSDs data. 1) Why does FreeBSD not simply use the free partitoin that I had prepared for it? It had detected that it is erased, why just doesn't it allow to add / and swap? 2) Why doesn't FreeBSD doesn't show where (on which sector) it adds a new partition? This and the loss of my data is really disappointing. At the moment installing FreeBSD is impossible at my disk while the over BSDs did work out of the box. Carsten From owner-freebsd-current@freebsd.org Fri Dec 11 18:21:01 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD50CA043D8; Fri, 11 Dec 2015 18:21:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 9FEF710AB; Fri, 11 Dec 2015 18:21:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F13101230; Fri, 11 Dec 2015 18:21:01 +0000 (UTC) Date: Fri, 11 Dec 2015 18:20:59 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: andrew@FreeBSD.org, imp@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1526464620.7.1449858061956.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1696732066.5.1449850596300.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1696732066.5.1449850596300.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #1864 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 18:21:01 -0000 FreeBSD_HEAD_i386 - Build #1864 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1864/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1864/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1864/console Change summaries: 292114 by imp: Correct the CONFIG0_VI value. According to http://www.t-es-t.hu/download/mips/md00090c.pdf this is bit 3 of the config0 word, not bit 2. This should fix virtually indexed caches (relatively new in the MIPS world, so no current platforms used this and current code just uses it as an optimization). It was causing false positives on newer platforms that default to large values for the kseg0 cache coherency attribute. Submitted by: Stanislav Galabov PR: 205249 292112 by andrew: Sort the list of NICs after the mii options. While here add the msk driver as it has now been tested. Sponsored by: SoftIron Inc 292111 by imp: Use the right product names. Pointy Hat To: imp@ From owner-freebsd-current@freebsd.org Fri Dec 11 19:42:23 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E45FA04B60 for ; Fri, 11 Dec 2015 19:42:23 +0000 (UTC) (envelope-from mmcco@mykolab.com) Received: from mx-out03.mykolab.com (mx01.mykolab.com [95.128.36.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 0CE001CAB for ; Fri, 11 Dec 2015 19:42:22 +0000 (UTC) (envelope-from mmcco@mykolab.com) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-10 required=6.31 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, FREEMAIL_FROM=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102]) by mx-out03.mykolab.com (Postfix) with ESMTPS id 3735922630 for ; Fri, 11 Dec 2015 20:42:08 +0100 (CET) Date: Fri, 11 Dec 2015 14:42:05 -0500 From: Michael McConville To: freebsd-current@freebsd.org Subject: XOR pt. 2 Message-ID: <20151211194204.GA26628@thinkpad.swarthmore.edu> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Mailman-Approved-At: Fri, 11 Dec 2015 19:58:48 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 19:42:23 -0000 Note that IFCAP_HWCSUM has two bits set. Because of this, it doesn't XOR cleanly in the current if-else condition, but I'm not sure whether that was intended. I just wanted to pass this by people in case it was a logical bug. --- dev/ixgb/if_ixgb.c.orig +++ dev/ixgb/if_ixgb.c @@ -599,10 +599,7 @@ ixgb_ioctl(struct ifnet * ifp, IOCTL_CMD } #endif /* DEVICE_POLLING */ if (mask & IFCAP_HWCSUM) { - if (IFCAP_HWCSUM & ifp->if_capenable) - ifp->if_capenable &= ~IFCAP_HWCSUM; - else - ifp->if_capenable |= IFCAP_HWCSUM; + ifp->if_capenable ^= IFCAP_HWCSUM; if (ifp->if_drv_flags & IFF_DRV_RUNNING) ixgb_init(adapter); } From owner-freebsd-current@freebsd.org Fri Dec 11 21:11:53 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FE809D7BBD for ; Fri, 11 Dec 2015 21:11:53 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-17.arcor-online.net (mail-in-17.arcor-online.net [151.189.21.57]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3183A17AA for ; Fri, 11 Dec 2015 21:11:52 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-16-z2.arcor-online.net (mail-in-16-z2.arcor-online.net [151.189.8.33]) by mx.arcor.de (Postfix) with ESMTP id 3pHP9D2hRPz4RfK for ; Fri, 11 Dec 2015 21:39:12 +0100 (CET) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mail-in-16-z2.arcor-online.net (Postfix) with ESMTP id 59E3721645E for ; Fri, 11 Dec 2015 21:39:12 +0100 (CET) Received: from webmail06.arcor-online.net (webmail06.arcor-online.net [151.189.8.133]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 3pHP9D2NGpz80cn for ; Fri, 11 Dec 2015 21:39:12 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-05.arcor-online.net 3pHP9D2NGpz80cn Received: from [84.179.13.20] by webmail06.arcor-online.net (151.189.8.133) with HTTP (Arcor Webmail); Fri, 11 Dec 2015 21:39:12 +0100 (CET) Date: Fri, 11 Dec 2015 21:39:12 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <1951187234.227919.1449866352324.JavaMail.ngmail@webmail06.arcor-online.net> References: <1812473578.396927.1449851649511.JavaMail.ngmail@webmail08.arcor-online.net> Subject: Partitioning on a MBR table disk fails (and destroys my data...) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 84.179.13.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 21:11:53 -0000 Hello, how is it possible to install FreeBSD in an existing empty MBR partition with type "freebsd"? The installer does not allow this (for unknown reason), it returns the error "no space left". What steps would be necessary to add two freebsd-ufs and one freebsd-swap into the existing freebsd partition? In no case I want to delete this partition since I do *not* want FreeBSD to edit the MBR (to not have data loss again). There is unfortunately not much information in the handbook "2.6.5. Shell Mode Partitioning" (anyway I'd prefer to use the curses UI partition editor). Carsten From owner-freebsd-current@freebsd.org Fri Dec 11 21:19:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16A9BA0448D for ; Fri, 11 Dec 2015 21:19:33 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EF0FF1EAC for ; Fri, 11 Dec 2015 21:19:32 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id tBBLJOYC048783; Fri, 11 Dec 2015 13:19:29 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201512112119.tBBLJOYC048783@gw.catspoiler.org> Date: Fri, 11 Dec 2015 13:19:24 -0800 (PST) From: Don Lewis Subject: Re: XOR pt. 2 To: mmcco@mykolab.com cc: freebsd-current@freebsd.org In-Reply-To: <20151211194204.GA26628@thinkpad.swarthmore.edu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 21:19:33 -0000 On 11 Dec, Michael McConville wrote: > Note that IFCAP_HWCSUM has two bits set. Because of this, it doesn't XOR > cleanly in the current if-else condition, but I'm not sure whether that > was intended. I just wanted to pass this by people in case it was a > logical bug. Yeah, the original code looks incorrect. If HWCSUM is totally disabled and the user requests RXCSUM, then the current code will enable both RXCSUM and TXCSUM. > --- dev/ixgb/if_ixgb.c.orig > +++ dev/ixgb/if_ixgb.c > @@ -599,10 +599,7 @@ ixgb_ioctl(struct ifnet * ifp, IOCTL_CMD > } > #endif /* DEVICE_POLLING */ > if (mask & IFCAP_HWCSUM) { > - if (IFCAP_HWCSUM & ifp->if_capenable) > - ifp->if_capenable &= ~IFCAP_HWCSUM; > - else > - ifp->if_capenable |= IFCAP_HWCSUM; > + ifp->if_capenable ^= IFCAP_HWCSUM; I think that would need to be: ifp->if_capenable ^= (mask & IFCAP_HWCSUM); > if (ifp->if_drv_flags & IFF_DRV_RUNNING) > ixgb_init(adapter); > } > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Dec 11 21:34:59 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE47A9D734A for ; Fri, 11 Dec 2015 21:34:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE8C1A43 for ; Fri, 11 Dec 2015 21:34:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:0GAEgxKo6x0PtGdAe9mcpTZWNBhigK39O0sv0rFitYgULf/xwZ3uMQTl6Ol3ixeRBMOAu6wC07KempujcFJDyK7JiGoFfp1IWk1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXsq3G/pQQfBg/4fVIsYL+lRMiK14ye7KObxd76W01wnj2zYLd/fl2djD76kY0ou7ZkMbs70RDTo3FFKKx8zGJsIk+PzV6nvp/jtLYqySlbuuog+shcSu26Ov1gFf0LRAghZks8/tb3uB+LbhaJ9HZUBm4fiAFUDg6D7wz8TJrZuzHxsfA71CTMbuPsSrVhYzWp7O9OQRTrjCoCf2oj9Wjcich9iYpGpx28qhhnw8jfadfGZ7JFYqrBcIZCFiJ6VcFLWnkEW9vkYg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CtBADgQGtW/61jaINehA1uBr8ZFwqFJEoCgWwRAQEBAQEBAQGBCYItggcBAQEDAQEBASArIAsFCwIBCBgCAg0ZAgInAQkmAgQIBwQBHASIBggNrFKRZQEBAQEBAQEDAQEBAQEBAQEXBIEBhVWEfYQ7AQFWgmSBSQWOKYhJhTWFIp97AjcsghEdgXQgNAeEHTqBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,415,1444708800"; d="scan'208";a="255808315" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 11 Dec 2015 16:34:57 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id E10F415F55D; Fri, 11 Dec 2015 16:34:57 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 52HIp6kAUV_T; Fri, 11 Dec 2015 16:34:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 8E9E815F565; Fri, 11 Dec 2015 16:34:57 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LMQX8SFK_7zK; Fri, 11 Dec 2015 16:34:57 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 77B0115F55D; Fri, 11 Dec 2015 16:34:57 -0500 (EST) Date: Fri, 11 Dec 2015 16:34:57 -0500 (EST) From: Rick Macklem To: Carsten Kunze Cc: freebsd-current@freebsd.org Message-ID: <1872732466.128678074.1449869697292.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <1951187234.227919.1449866352324.JavaMail.ngmail@webmail06.arcor-online.net> References: <1812473578.396927.1449851649511.JavaMail.ngmail@webmail08.arcor-online.net> <1951187234.227919.1449866352324.JavaMail.ngmail@webmail06.arcor-online.net> Subject: Re: Partitioning on a MBR table disk fails (and destroys my data...) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: Partitioning on a MBR table disk fails (and destroys my data...) Thread-Index: EMIrn8615SbNISGOxnTH6wj9psyO2A== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 21:34:59 -0000 Carsten Kunze wrote: > Hello, > > how is it possible to install FreeBSD in an existing empty MBR partition with > type "freebsd"? The installer does not allow this (for unknown reason), it > returns the error "no space left". What steps would be necessary to add two > freebsd-ufs and one freebsd-swap into the existing freebsd partition? In no > case I want to delete this partition since I do *not* want FreeBSD to edit > the MBR (to not have data loss again). There is unfortunately not much > information in the handbook "2.6.5. Shell Mode Partitioning" (anyway I'd > prefer to use the curses UI partition editor). > Did you use "Manual" when it gets to the partitioning screen? When I've done this, after selecting "Manual MBR" (or whatever it's called, one or two below "Auto"), it should show you the slices (what FreeBSD calls the 4 MBR partitions): - Then I select the "freebsd" (move around until it is highlighted one) and create partitions within it with "Create" at the bottom of the screen. (I always have "fun" with the interface, but repeated attempts with and the arrow keys eventually get me to the right place on the screen;-) Good luck with it, rick ps: If it doesn't show the slices,I'm guessing the MBR doesn't make sense to FreeBSD's fdisk. You can go to "" instead of "" and then try typing "fdisk". > Carsten > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Dec 11 22:22:22 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C426E9D7D4B for ; Fri, 11 Dec 2015 22:22:22 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-15.arcor-online.net (mail-in-15.arcor-online.net [151.189.21.55]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84D991945 for ; Fri, 11 Dec 2015 22:22:22 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-02-z2.arcor-online.net (mail-in-02-z2.arcor-online.net [151.189.8.14]) by mx.arcor.de (Postfix) with ESMTP id 3pHQnB0WBTzC1S1 for ; Fri, 11 Dec 2015 22:51:58 +0100 (CET) Received: from mail-in-14.arcor-online.net (mail-in-14.arcor-online.net [151.189.21.54]) by mail-in-02-z2.arcor-online.net (Postfix) with ESMTP id 07815718138 for ; Fri, 11 Dec 2015 22:51:58 +0100 (CET) Received: from webmail06.arcor-online.net (webmail06.arcor-online.net [151.189.8.133]) by mail-in-14.arcor-online.net (Postfix) with ESMTP id 3pHQnB01vpz7NBf for ; Fri, 11 Dec 2015 22:51:58 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-14.arcor-online.net 3pHQnB01vpz7NBf Received: from [84.179.13.20] by webmail06.arcor-online.net (151.189.8.133) with HTTP (Arcor Webmail); Fri, 11 Dec 2015 22:51:57 +0100 (CET) Date: Fri, 11 Dec 2015 22:51:57 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <1216457205.228496.1449870717994.JavaMail.ngmail@webmail06.arcor-online.net> In-Reply-To: <1872732466.128678074.1449869697292.JavaMail.zimbra@uoguelph.ca> References: <1872732466.128678074.1449869697292.JavaMail.zimbra@uoguelph.ca> <1812473578.396927.1449851649511.JavaMail.ngmail@webmail08.arcor-online.net> <1951187234.227919.1449866352324.JavaMail.ngmail@webmail06.arcor-online.net> Subject: Aw: Re: Partitioning on a MBR table disk fails (and destroys my data...) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 84.179.13.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 22:22:22 -0000 Rick Macklem wrote: > Did you use "Manual" when it gets to the partitioning screen? > When I've done this, after selecting "Manual MBR" (or whatever it's called, > one or two below "Auto"), it should show you the slices > (what FreeBSD calls the 4 MBR partitions): > - Then I select the "freebsd" (move around until it is highlighted one) > and create partitions within it with "Create" at the bottom of the > screen. > (I always have "fun" with the interface, but repeated attempts with > and the arrow keys eventually get me to the right place on the screen;-) I think I did select "auto" which brings me into the "manual" screen after few steps. It does show the slices and does even show NTFS and Linux partitions inside the extended partition (I have 3 primary MBR partitions, first is freebsd, then two NTFS, then an extendet with further NTFS and Linux). The first 10MB of the first slice (freebsd) had been cleared with "dd if=/dev/zero of=...". When I put the cursor line on this slice and select "create" it doesn't allow me to create the freebsd-ufs for "/". > Good luck with it, rick > ps: If it doesn't show the slices,I'm guessing the MBR doesn't make sense > to > FreeBSD's fdisk. You can go to "" instead of "" and > then > try typing "fdisk". I did try the shell and typed "fdisk" and "disklabel" but this did not work as known from other BSDs. The actually issue is that I can't create something in the found freebsd slice. In the past I did simply remove this slice and added a new one (since the free space on the disk had exactly been what I wanted to use). But now the seemingly free space is not actually completely free so I'd like to not delete the slice. The installer should support using this slice. Carsten From owner-freebsd-current@freebsd.org Fri Dec 11 22:49:11 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31FC49D7957 for ; Fri, 11 Dec 2015 22:49:11 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 B7D2D1B20; Fri, 11 Dec 2015 22:49:10 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by lbblt2 with SMTP id lt2so78968707lbb.3; Fri, 11 Dec 2015 14:49: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=G1SWWlSLlZOvHqVz2hQZ2gu7UNsYeckCam1/NsI5JAs=; b=Xq0jiIWmrSxhrqqGtWyU4Vv09ee9QHImcEVqm9EQ05rtKCJ/yURuTpWCDZtbaQfXsn V4jqiwQImpDcLEaCYX4gzG7RXYVen7nOZnlFwPENzWiqYlCeTlsnBrh+Sn4+MXTThMk3 MHO7uXb5cTHnKPprUM44N+wDSVqdWJELWT1v5mIxr1zb/r8HbkSy8+G7yH9ls9P1jFP/ HwjAYAKRRcYUbYJ76rG+Cl0EGVcfLnbtVYOZDB3NhBEgq7TwAxAkvRI26rqMeIGi2BNO bIHgPKOiWkALU/yRFDTThQBVCI9qTvIhoI+fvgpfDLChB5JccJHSE9BO6juAFPDQk70L U+SQ== MIME-Version: 1.0 X-Received: by 10.112.126.42 with SMTP id mv10mr8962046lbb.98.1449874148583; Fri, 11 Dec 2015 14:49:08 -0800 (PST) Received: by 10.112.219.9 with HTTP; Fri, 11 Dec 2015 14:49:08 -0800 (PST) In-Reply-To: <201512112119.tBBLJOYC048783@gw.catspoiler.org> References: <20151211194204.GA26628@thinkpad.swarthmore.edu> <201512112119.tBBLJOYC048783@gw.catspoiler.org> Date: Fri, 11 Dec 2015 14:49:08 -0800 Message-ID: Subject: Re: XOR pt. 2 From: NGie Cooper To: Don Lewis Cc: mmcco@mykolab.com, FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 22:49:11 -0000 On Fri, Dec 11, 2015 at 1:19 PM, Don Lewis wrote: > On 11 Dec, Michael McConville wrote: >> Note that IFCAP_HWCSUM has two bits set. Because of this, it doesn't XOR >> cleanly in the current if-else condition, but I'm not sure whether that >> was intended. I just wanted to pass this by people in case it was a >> logical bug. > > Yeah, the original code looks incorrect. If HWCSUM is totally disabled > and the user requests RXCSUM, then the current code will enable both > RXCSUM and TXCSUM. Please file a bug on bugzilla, CC erj, sbruno, and myself (ngie). Thanks! -NGie From owner-freebsd-current@freebsd.org Fri Dec 11 23:10:30 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95946A04DE4 for ; Fri, 11 Dec 2015 23:10:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 49CDB1C95 for ; Fri, 11 Dec 2015 23:10:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:xpssHh9Mt8eJAP9uRHKM819IXTAuvvDOBiVQ1KB91OkcTK2v8tzYMVDF4r011RmSDduds6oMotGVmp6jcFRI2YyGvnEGfc4EfD4+ouJSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47AblHf6ke/8SQVUk2mc1EleKKtQsb7tIee6aObw9XreQJGhT6wM/tZDS6dikHvjPQQmpZoMa0ryxHE8TNicuVSwn50dxrIx06vru/5xpNo8jxRtvQ97IYAFPyiJ+VrBYBfWR8vKXsp6cujlgTFXwbHsnAVSH4KnxwOABXD/hzSV436tTG8uucriweAOsijd7E/WnyH5qxoTBLtwHMdMjcy82Xaj+Rti61GrRa5p1p0ytiHM8muKPNic/aFLpshTm1bU5MUDnQZDw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CtBABaV2tW/61jaINehA1uBr04gWIXCoUjSgKBbRIBAQEBAQEBAYEJgi2CBwEBAQMBAQEBICsgCwULAgEIGAICDRkCAicBCSYCBAgHBAEcBIgGCA2sTJFkAQEBAQEBAQMBAQEBAQEBAQEWBIEBhVWEfYQ7AQGDOoFJBY4piEmFNYUihEiXQoNxAicBO4IRHYF0IDQHhB06gQgBAQE X-IronPort-AV: E=Sophos;i="5.20,415,1444708800"; d="scan'208";a="255823239" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 11 Dec 2015 18:10:28 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id B7F5215F55D; Fri, 11 Dec 2015 18:10:28 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id U_PlN1fqTXHK; Fri, 11 Dec 2015 18:10:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 0A43915F565; Fri, 11 Dec 2015 18:10:28 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id t4Xw80m8TAgA; Fri, 11 Dec 2015 18:10:27 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id E28C515F55D; Fri, 11 Dec 2015 18:10:27 -0500 (EST) Date: Fri, 11 Dec 2015 18:10:27 -0500 (EST) From: Rick Macklem To: Carsten Kunze Cc: freebsd-current@freebsd.org Message-ID: <45234563.128753656.1449875427901.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <1216457205.228496.1449870717994.JavaMail.ngmail@webmail06.arcor-online.net> References: <1872732466.128678074.1449869697292.JavaMail.zimbra@uoguelph.ca> <1812473578.396927.1449851649511.JavaMail.ngmail@webmail08.arcor-online.net> <1951187234.227919.1449866352324.JavaMail.ngmail@webmail06.arcor-online.net> <1216457205.228496.1449870717994.JavaMail.ngmail@webmail06.arcor-online.net> Subject: Re: Aw: Re: Partitioning on a MBR table disk fails (and destroys my data...) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: Partitioning on a MBR table disk fails (and destroys my data...) Thread-Index: jO6JWAYVKBTXOPekN1paR7MWy+cxcA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 23:10:30 -0000 Carsten Kunze wrote: > Rick Macklem wrote: > > > Did you use "Manual" when it gets to the partitioning screen? > > When I've done this, after selecting "Manual MBR" (or whatever it's called, > > one or two below "Auto"), it should show you the slices > > (what FreeBSD calls the 4 MBR partitions): > > - Then I select the "freebsd" (move around until it is highlighted one) > > and create partitions within it with "Create" at the bottom of the > > screen. > > (I always have "fun" with the interface, but repeated attempts with > > and the arrow keys eventually get me to the right place on the screen;-) > > I think I did select "auto" which brings me into the "manual" screen after > few > steps. It does show the slices and does even show NTFS and Linux > partitions inside the extended partition (I have 3 primary MBR partitions, > first is freebsd, then two NTFS, then an extendet with further NTFS and > Linux). > > The first 10MB of the first slice (freebsd) had been cleared with > "dd if=/dev/zero of=...". When I put the cursor line on this slice and > select "create" it doesn't allow me to create the freebsd-ufs for "/". > Sorry, I can`t explain why it would fail. I have seen different fdisks have differing opinions w.r.t. partition alignment in the past. > > Good luck with it, rick > > ps: If it doesn't show the slices,I'm guessing the MBR doesn't make sense > > to > > FreeBSD's fdisk. You can go to "" instead of "" and > > then > > try typing "fdisk". > > I did try the shell and typed "fdisk" and "disklabel" but this did not work > as > known from other BSDs. > You didn`t say what `fdisk` gave as output. If it doesn`t show your slices, I can only guess that the MBR isn`t understood by FreeBSD for some reason. I don`t use it, but gpart is the preferred FreeBSD command. You might try that instead. As I said, it works for me, but I use a simple: - windows NTFS - windows NTFS - freebsd set of slices and I created freebsd with the "Manual MBR" option of the installer. I do not know what ``auto`` might have done. Over the years, I have found that different variants of "fdisk" have different ideas w.r.t. alignment. > The actually issue is that I can't create something in the found freebsd > slice. In the past I did simply remove this slice and added a new one > (since the free space on the disk had exactly been what I wanted to > use). But now the seemingly free space is not actually completely free > so I'd like to not delete the slice. The installer should support using > this slice. > Well, although installing is always a bit scary, if you don`t touch the other slices, I`d delete and create the freebsd one. It gets to a certain point when doing the `Manual MBR` before it asks you if you want to save it on disk. rick > Carsten > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Dec 11 23:23:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87CDA9D7953 for ; Fri, 11 Dec 2015 23:23:00 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45D1D156D for ; Fri, 11 Dec 2015 23:22:59 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-13-z2.arcor-online.net (mail-in-13-z2.arcor-online.net [151.189.8.30]) by mx.arcor.de (Postfix) with ESMTP id 3pHSp328j1z8Tf6 for ; Sat, 12 Dec 2015 00:22:51 +0100 (CET) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-13-z2.arcor-online.net (Postfix) with ESMTP id 1FF083C5729 for ; Sat, 12 Dec 2015 00:22:51 +0100 (CET) Received: from webmail06.arcor-online.net (webmail06.arcor-online.net [151.189.8.133]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id 3pHSp30cfnzBsb5 for ; Sat, 12 Dec 2015 00:22:51 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-07.arcor-online.net 3pHSp30cfnzBsb5 Received: from [84.179.13.20] by webmail06.arcor-online.net (151.189.8.133) with HTTP (Arcor Webmail); Sat, 12 Dec 2015 00:22:50 +0100 (CET) Date: Sat, 12 Dec 2015 00:22:51 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <1453076310.228976.1449876171067.JavaMail.ngmail@webmail06.arcor-online.net> In-Reply-To: <45234563.128753656.1449875427901.JavaMail.zimbra@uoguelph.ca> References: <45234563.128753656.1449875427901.JavaMail.zimbra@uoguelph.ca> <1872732466.128678074.1449869697292.JavaMail.zimbra@uoguelph.ca> <1812473578.396927.1449851649511.JavaMail.ngmail@webmail08.arcor-online.net> <1951187234.227919.1449866352324.JavaMail.ngmail@webmail06.arcor-online.net> <1216457205.228496.1449870717994.JavaMail.ngmail@webmail06.arcor-online.net> Subject: Aw: Re: Aw: Re: Partitioning on a MBR table disk fails (and destroys my data...) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 84.179.13.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 11 Dec 2015 23:23:00 -0000 Rick Macklem wrote: > I don`t use it, but gpart is the preferred FreeBSD command. You might try > that instead. Does it work with MBR or only GPT? Anyway, I'll try it. > Well, although installing is always a bit scary, if you don`t touch the > other > slices, I`d delete and create the freebsd one. It gets to a certain point > when > doing the `Manual MBR` before it asks you if you want to save it on disk. At least creating by the (curses) GUI installer is not possible. It does create somewhere instead of asking me and it doesn't even tell me where it has created it. And there are numeric bugs in the tool. The numbers it displayed changed without reason and became even negative ... So the MBR I don't touch with FreeBSD anymore ... A simple task for the installer developer: Please let me use an existing empty slice. This is no rocket sience. Carsten From owner-freebsd-current@freebsd.org Sat Dec 12 13:36:20 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74CC5A14B66 for ; Sat, 12 Dec 2015 13:36:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF4A124B for ; Sat, 12 Dec 2015 13:36:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:8XV2jRD7BhucdtxD2Sn8UyQJP3N1i/DPJgcQr6AfoPdwSP78pMbcNUDSrc9gkEXOFd2CrakU1ayO6+jJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6MyZzvn8mJuLTtICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJcekFjUlhJFaUggqurpzopM0r221qtvkg789NV7nhN+R9FOQATWduD2dgz8TxrgXOS0Os+30OXy1CmRNSGBTI6lf5Q5HjvwPzrOF6wm+WMJulY6ozXGGY7qxoADrhgyQDOjtxpHvSg8dziK9eiA+mqAFyx5bUJoqcYqktNpjBdM8XEDISFv1aUDZMV8blN9MC X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CnBACRIWxW/61jaINehHsGvT6BY4YOgWASAQEBAQEBAQGBCYItggcBAQEDASMEUgUNASACAg0ZAksBDwQTiCcIrBeRYAEKAQEBAR6BAYVVjHSBSQWOKohMjx+ERZZyAigBOoIRHRaBXiA0hAqBCAEBAQ X-IronPort-AV: E=Sophos;i="5.20,417,1444708800"; d="scan'208";a="255904622" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 12 Dec 2015 08:36:12 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 0B62615F55D; Sat, 12 Dec 2015 08:36:13 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PBbK2dtRnmXL; Sat, 12 Dec 2015 08:36:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 5319415F565; Sat, 12 Dec 2015 08:36:12 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7UNSlsaZkpTV; Sat, 12 Dec 2015 08:36:12 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 350F315F55D; Sat, 12 Dec 2015 08:36:12 -0500 (EST) Date: Sat, 12 Dec 2015 08:36:12 -0500 (EST) From: Rick Macklem To: Carsten Kunze Cc: freebsd-current Message-ID: <1031404841.129079609.1449927372100.JavaMail.zimbra@uoguelph.ca> Subject: Aw: Re: Aw: Re: Partitioning on a MBR table disk fails (and destroys my data...) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF42 (Win)/8.0.9_GA_6191) Thread-Topic: Partitioning on a MBR table disk fails (and destroys my data...) Thread-Index: 4qXMLDZsLFXU+EYy/+dpl09Xg2/b2g== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 12 Dec 2015 13:36:20 -0000 > Rick Macklem wrote: > > > I don`t use it, but gpart is the preferred FreeBSD command. You might try > > that instead. > > Does it work with MBR or only GPT? Anyway, I'll try it. > It does handle MBR. However, since you are already comfortable with the OpenBSD/NetBSD fdisk, maybe firing up one of those and using their fdisk to clear out the slice you want to use for FreeBSD would be easier. Especially since you mention below that you don't want to "touch with FreeBSD anymore". If you have problems doing this, maybe posting with exactly what error(s) you get from fdisk might get some specific suggestions w.r.t. fixing it? If you do choose to use a from the FreeBSD installer, either fdisk (I don't think you need to specify a disk, but if you do, try "/dev/ada0") or "gpart list" should show you what FreeBSD thinks the partition table looks like. (I don't use gpart, so I don't know its commands beyond that. The man page is rather long, so if you choose to use it, you've got some reading to do.) --> If there is anything under the "freebsd" slice, you need to delete those before creating new ones. --> If you do "Manual...MBR" from the installer, it should show you the slices and anything within each slice. If it shows you anything inside the "freebsd" slice, delete those before trying to create any new ones. The "Manual...MBR" is a front-end to either gpart of fdisk (I don't work on the installer, so I don't know which) and has always worked fine for me. (I recently installed using this on the space left over from a Windows install, so it understood the MBR the Windows install put on the drive. I did create the freebsd slice with this, followed by the partitions within the slice.) The only "trick" I've noticed is that I needed to know the names for the types of partitions: freebsd-ufs for a UFS partition freebsd-swap for a swap partition freebsd-zfs for a ZFS partition - because the installer seems to expect you to know these for the "Manual...MBR" case. > > Well, although installing is always a bit scary, if you don`t touch the > > other > > slices, I`d delete and create the freebsd one. It gets to a certain point > > when > > doing the `Manual MBR` before it asks you if you want to save it on disk. > > At least creating by the (curses) GUI installer is not possible. It does create > somewhere instead of asking me and it doesn't even tell me where it > has created it. And there are numeric bugs in the tool. The numbers it > displayed changed without reason and became even negative ... > So the MBR I don't touch with FreeBSD anymore ... > A simple task for the installer developer: Please let me use an existing > empty slice. This is no rocket sience. > > Carsten Once you have cleared out the FreeBSD partition with OpenBSD/NetBSD, then I'd encourage you to use "Manual ..MBR" and avoid the Auto option when you get to that point in the FreeBSD install. Good luck with it, rick ps: I'm not an installer guy. I just use it from time to time. From owner-freebsd-current@freebsd.org Sat Dec 12 20:12:51 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C1A8A3EF92 for ; Sat, 12 Dec 2015 20:12:51 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD2761395 for ; Sat, 12 Dec 2015 20:12:50 +0000 (UTC) (envelope-from carsten.kunze@arcor.de) Received: from mail-in-11-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mx.arcor.de (Postfix) with ESMTP id 3pJ0XG3lv5z8Rtv for ; Sat, 12 Dec 2015 21:12:46 +0100 (CET) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-11-z2.arcor-online.net (Postfix) with ESMTP id 7E06131BD2B for ; Sat, 12 Dec 2015 21:12:46 +0100 (CET) Received: from webmail18.arcor-online.net (webmail18.arcor-online.net [151.189.8.76]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id 3pJ0XG3Y8vzBqxF for ; Sat, 12 Dec 2015 21:12:46 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-07.arcor-online.net 3pJ0XG3Y8vzBqxF DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1449951166; bh=iu6lUERMjkBr0iuUZdQ+8ihojvvWnxxs4vPB8jAWgAQ=; h=Date:From:To:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; b=nmFou1BkJl+5cZjG1UtjC4ghiCQRBjI7Hu6p4oXR2+1nfwhMzLus5MxAegRgCyuEM Fxi8szFW/9JnrLxo4trP3LOwlZ4Rs0ZNVgcdwi7n1oh3LZLpGyaVUFpWvZGWr2b1Y4 RpnRm7C23KsXC+koVe8zY748FtPAGEW5i+1X2DcU= Received: from [84.179.13.20] by webmail18.arcor-online.net (151.189.8.76) with HTTP (Arcor Webmail); Sat, 12 Dec 2015 21:12:46 +0100 (CET) Date: Sat, 12 Dec 2015 21:12:46 +0100 (CET) From: Carsten Kunze To: freebsd-current@freebsd.org Message-ID: <1047622975.189227.1449951166489.JavaMail.ngmail@webmail18.arcor-online.net> In-Reply-To: <1031404841.129079609.1449927372100.JavaMail.zimbra@uoguelph.ca> References: <1031404841.129079609.1449927372100.JavaMail.zimbra@uoguelph.ca> Subject: [Solved] Partitioning on a MBR table disk fails MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ngMessageSubType: MessageSubType_MAIL X-WebmailclientIP: 84.179.13.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 12 Dec 2015 20:12:51 -0000 Hi Rick, thank you for your help! Using gpart in the shell did work well :) Regards, Carsten