From owner-freebsd-current@freebsd.org Sun Jun 19 02:10:26 2016 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 D1A2EA7A3D9 for ; Sun, 19 Jun 2016 02:10:26 +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 C392022D4; Sun, 19 Jun 2016 02:10:26 +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 F36221901; Sun, 19 Jun 2016 02:10:26 +0000 (UTC) Date: Sun, 19 Jun 2016 02:10:25 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <295342895.102.1466302225516.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <531184112.100.1466261881384.JavaMail.jenkins@jenkins-9.freebsd.org> References: <531184112.100.1466261881384.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD_sparc64 #88 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_sparc64 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Jun 2016 02:10:26 -0000 See From owner-freebsd-current@freebsd.org Sun Jun 19 03:48:39 2016 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 10A9FA7A5F1 for ; Sun, 19 Jun 2016 03:48:39 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B4C4516A1; Sun, 19 Jun 2016 03:48:38 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from vsuiko.mahoroba.org (vsuiko.mahoroba.org [IPv6:2001:2f0:104:8010:a00:27ff:feb0:c2e]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.15.2/8.15.2) with ESMTPSA/inet6 id u5J3mXSL041096 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Jun 2016 12:48:33 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 19 Jun 2016 12:47:56 +0900 Message-ID: From: Hajimu UMEMOTO To: Eric van Gyzen Cc: Baptiste Daroussin , freebsd-current@freebsd.org Subject: Re: Date formatting with en_US locale In-Reply-To: <4155ae57-4af9-efcb-e42e-8ac18d568221@FreeBSD.org> References: <499d8ddd-06c8-5184-68cb-4be19764b318@FreeBSD.org> <20160526144944.GD977@ivaldir.etoilebsd.net> <20160526151508.GE977@ivaldir.etoilebsd.net> <6d8f5e72-b3ab-9aa6-4fb6-1986b7b4f19b@FreeBSD.org> <4155ae57-4af9-efcb-e42e-8ac18d568221@FreeBSD.org> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 10.3-STABLE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 19 Jun 2016 12:48:33 +0900 (JST) X-Virus-Scanned: clamav-milter 0.99.2 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on asuka.mahoroba.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Jun 2016 03:48:39 -0000 Hi, >>>>> On Sat, 18 Jun 2016 18:25:51 -0500 >>>>> Eric van Gyzen said: vangyzen> On 06/18/16 04:10 AM, Hajimu UMEMOTO wrote: > Does the attached patch fix your issue? > Though there are many locales it should be fixed, I've included only > en_US one, in this time. vangyzen> Yes, it fixes my issue with en_US. Thank you, Umemoto-san. You are welcome. I've just committed into HEAD. Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-current@freebsd.org Sun Jun 19 07:11:09 2016 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 3051AA7AA27 for ; Sun, 19 Jun 2016 07:11:09 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (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 EF3C21F06 for ; Sun, 19 Jun 2016 07:11:08 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 5893B17209D for ; Sun, 19 Jun 2016 09:11:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id efwdERB-xAMU for ; Sun, 19 Jun 2016 09:11:04 +0200 (CEST) X-Originating-IP: 90.231.139.91 Received: from [192.168.1.249] (h91n1-gl-a-a31.ias.bredband.telia.com [90.231.139.91]) (Authenticated sender: daniel.engberg@pyret.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 94886172094 for ; Sun, 19 Jun 2016 09:11:04 +0200 (CEST) To: freebsd-current@freebsd.org From: Daniel Engberg Subject: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4 Message-ID: <0092113e-6ad6-575c-2127-f211ba9aef50@pyret.net> Date: Sun, 19 Jun 2016 09:10:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.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.22 Precedence: 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, 19 Jun 2016 07:11:09 -0000 Hi, Decided to try ALPHA4 and Samba 4.3 and 4.4 doesn't seem very happy. Fatal error 'mutex 0x8013ec000 own 0x18cdc is on list 0x8112161a0 0x0' at line 153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4) [2016/06/19 01:14:47.689256, 0] ../lib/util/fault.c:78(fault_report) =============================================================== [2016/06/19 01:14:47.689450, 0] ../lib/util/fault.c:79(fault_report) INTERNAL ERROR: Signal 6 in pid 45222 (4.4.3) Please read the Trouble-Shooting section of the Samba HOWTO [2016/06/19 01:14:47.689479, 0] ../lib/util/fault.c:81(fault_report) =============================================================== [2016/06/19 01:14:47.689498, 0] ../source3/lib/util.c:791(smb_panic_s3) PANIC (pid 45222): internal error [2016/06/19 01:14:47.690577, 0] ../source3/lib/util.c:902(log_stack_trace) BACKTRACE: 6 stack frames: #0 0x803c16fe8 at /usr/local/lib/samba4/libsmbconf.so.0 #1 0x803c16ed2 at /usr/local/lib/samba4/libsmbconf.so.0 #2 0x801696dad at /usr/local/lib/samba4/libsamba-util.so.0 #3 0x801696c57 at /usr/local/lib/samba4/libsamba-util.so.0 #4 0x8014616df at /lib/libthr.so.3 #5 0x801460cbf at /lib/libthr.so.3 [2016/06/19 01:14:47.690686, 0] ../source3/lib/dumpcore.c:313(dump_core) unable to change to %N.core refusing to dump core Fatal error 'mutex 0x8013eb000 own 0x18d3d is on list 0x812e161a0 0x0' at line 153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4) [2016/06/19 01:26:41.063681, 0] ../lib/util/fault.c:78(fault_report) =============================================================== [2016/06/19 01:26:41.063827, 0] ../lib/util/fault.c:79(fault_report) INTERNAL ERROR: Signal 6 in pid 61297 (4.3.9) Please read the Trouble-Shooting section of the Samba HOWTO [2016/06/19 01:26:41.063844, 0] ../lib/util/fault.c:81(fault_report) =============================================================== [2016/06/19 01:26:41.063855, 0] ../source3/lib/util.c:789(smb_panic_s3) PANIC (pid 61297): internal error [2016/06/19 01:26:41.064679, 0] ../source3/lib/util.c:900(log_stack_trace) BACKTRACE: 6 stack frames: #0 0x803846eb8 at /usr/local/lib/libsmbconf.so.0 #1 0x803846da2 at /usr/local/lib/libsmbconf.so.0 #2 0x80168c12d at /usr/local/lib/libsamba-util.so.0 #3 0x80168bfd7 at /usr/local/lib/libsamba-util.so.0 #4 0x8014606df at /lib/libthr.so.3 #5 0x80145fcbf at /lib/libthr.so.3 [2016/06/19 01:26:41.064747, 0] ../source3/lib/dumpcore.c:313(dump_core) unable to change to %N.core refusing to dump core This occurs immediately when you start Samba so it's easy to replicate. I know that 4.3 worked on r298887 for sure, I'm going to try this in VM too but I'd apperciate if anyone else could give this a go. I noticed that there were some changes in libthr which might be a clue.... Best regards, Daniel Engberg From owner-freebsd-current@freebsd.org Sun Jun 19 08:04:36 2016 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 2B288A7ABBB; Sun, 19 Jun 2016 08:04:36 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv25.fwdcdn.com (frv25.fwdcdn.com [212.42.77.25]) by mx1.freebsd.org (Postfix) with ESMTP id E35A61C99; Sun, 19 Jun 2016 08:04:35 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from [10.10.14.26] (helo=frv157.fwdcdn.com) by frv25.fwdcdn.com QID:1bEXSl-000DoN-5H/RC:4; Sun, 19 Jun 2016 10:48:11 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=2UUU+kUj+C19qZOpBGItTIRkWEZbBFfNHURNjOkXNZw=; b=fmJ4NSpVwHh+PXCaYj7vrF9mgXjA9lJpqQg4UZCEEZ9kBeZxW1CEpuHoFpgiovCHoQEBnW5qrOvq9VCasMG+FkRUu9kk08xJZc7br5u2p5F/FPxixkYwqy0FBfdPiTw9NPbhIJ+RVKpDkHgRwrEXtPlGrN+tziF17VZa2Lps41g=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1bEXSd-000KtK-Fs ; Sun, 19 Jun 2016 10:48:03 +0300 Date: Sun, 19 Jun 2016 10:48:02 +0300 From: Ivan Klymenko To: Glen Barber Cc: freebsd-snapshots@freebsd.org, freebsd-current@freebsd.org, FreeBSD Release Engineering Team Subject: Re: New FreeBSD snapshots available: head (20160617 r301975) Message-ID: <20160619104802.236aa92b@nonamehost.local> In-Reply-To: <20160618230722.GC28666@FreeBSD.org> References: <20160618055811.GA35283@FreeBSD.org> <1466233842.650879797.mfv3fjy1@frv33.fwdcdn.com> <20160618140250.GB28666@FreeBSD.org> <20160618230722.GC28666@FreeBSD.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-Ukrnet-Yellow: 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Jun 2016 08:04:36 -0000 On Sat, 18 Jun 2016 23:07:22 +0000 Glen Barber wrote: > On Sat, Jun 18, 2016 at 02:02:50PM +0000, Glen Barber wrote: > > On Sat, Jun 18, 2016 at 10:12:07AM +0300, fidaj wrote: > > > === Installation ISOs === > > > > > > Installation images are available for: > > > > > > o 11.0-ALPHA4 amd64 GENERIC > > > o 11.0-ALPHA4 i386 GENERIC > > > o 11.0-ALPHA4 powerpc GENERIC > > > o 11.0-ALPHA4 powerpc64 GENERIC64 > > > o 11.0-ALPHA4 sparc64 GENERIC > > > o 11.0-ALPHA4 armv6 BANANAPI > > > o 11.0-ALPHA4 armv6 BEAGLEBONE > > > o 11.0-ALPHA4 armv6 CUBIEBOARD > > > o 11.0-ALPHA4 armv6 CUBIEBOARD2 > > > o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD > > > o 11.0-ALPHA4 armv6 GUMSTIX > > > o 11.0-ALPHA4 armv6 RPI-B > > > o 11.0-ALPHA4 armv6 RPI2 > > > o 11.0-ALPHA4 armv6 PANDABOARD > > > o 11.0-ALPHA4 armv6 WANDBOARD > > > o 11.0-ALPHA4 aarch64 GENERIC > > > > > > Hello. > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ > > > not have manifest file. > > > > Huh. Yep, this is a problem. > > > > Thank you for the report. I'll investigate what happened here. > > > > This doesn't make sense. The MANIFEST exists on the build machine, > and should have been copied as result of the distribution to the > mirrors. > > I don't understand how it did not make it to the mirrors. > > So I know, how did you discover this? > > I *do* see the MANIFEST for amd64, so something very bizarre happened > here. > > Glen > It breaks my poudriere. poudriere jail -c -v 11.0-ALPHA4 -a i386 -j 11_ALPHA4_i386 -m url=ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ From owner-freebsd-current@freebsd.org Sun Jun 19 08:06:51 2016 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 A6F83A7AC3D for ; Sun, 19 Jun 2016 08:06:51 +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 37E451E7D for ; Sun, 19 Jun 2016 08:06:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5J86imN049986 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 19 Jun 2016 11:06:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5J86imN049986 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5J86iWJ049985; Sun, 19 Jun 2016 11:06:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 19 Jun 2016 11:06:44 +0300 From: Konstantin Belousov To: Daniel Engberg Cc: freebsd-current@freebsd.org Subject: Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4 Message-ID: <20160619080644.GL38613@kib.kiev.ua> References: <0092113e-6ad6-575c-2127-f211ba9aef50@pyret.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0092113e-6ad6-575c-2127-f211ba9aef50@pyret.net> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 19 Jun 2016 08:06:51 -0000 On Sun, Jun 19, 2016 at 09:10:08AM +0200, Daniel Engberg wrote: > Hi, > > Decided to try ALPHA4 and Samba 4.3 and 4.4 doesn't seem very happy. > > Fatal error 'mutex 0x8013ec000 own 0x18cdc is on list 0x8112161a0 0x0' at line 153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4) > [2016/06/19 01:14:47.689256, 0] ../lib/util/fault.c:78(fault_report) > =============================================================== > [2016/06/19 01:14:47.689450, 0] ../lib/util/fault.c:79(fault_report) > INTERNAL ERROR: Signal 6 in pid 45222 (4.4.3) > Please read the Trouble-Shooting section of the Samba HOWTO > [2016/06/19 01:14:47.689479, 0] ../lib/util/fault.c:81(fault_report) > =============================================================== > [2016/06/19 01:14:47.689498, 0] ../source3/lib/util.c:791(smb_panic_s3) > PANIC (pid 45222): internal error > [2016/06/19 01:14:47.690577, 0] ../source3/lib/util.c:902(log_stack_trace) > BACKTRACE: 6 stack frames: > #0 0x803c16fe8 at /usr/local/lib/samba4/libsmbconf.so.0 > #1 0x803c16ed2 at /usr/local/lib/samba4/libsmbconf.so.0 > #2 0x801696dad at /usr/local/lib/samba4/libsamba-util.so.0 > #3 0x801696c57 at /usr/local/lib/samba4/libsamba-util.so.0 > #4 0x8014616df at /lib/libthr.so.3 > #5 0x801460cbf at /lib/libthr.so.3 > [2016/06/19 01:14:47.690686, 0] ../source3/lib/dumpcore.c:313(dump_core) > unable to change to %N.core > refusing to dump core > > Fatal error 'mutex 0x8013eb000 own 0x18d3d is on list 0x812e161a0 0x0' at line 153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4) > [2016/06/19 01:26:41.063681, 0] ../lib/util/fault.c:78(fault_report) > =============================================================== > [2016/06/19 01:26:41.063827, 0] ../lib/util/fault.c:79(fault_report) > INTERNAL ERROR: Signal 6 in pid 61297 (4.3.9) > Please read the Trouble-Shooting section of the Samba HOWTO > [2016/06/19 01:26:41.063844, 0] ../lib/util/fault.c:81(fault_report) > =============================================================== > [2016/06/19 01:26:41.063855, 0] ../source3/lib/util.c:789(smb_panic_s3) > PANIC (pid 61297): internal error > [2016/06/19 01:26:41.064679, 0] ../source3/lib/util.c:900(log_stack_trace) > BACKTRACE: 6 stack frames: > #0 0x803846eb8 at /usr/local/lib/libsmbconf.so.0 > #1 0x803846da2 at /usr/local/lib/libsmbconf.so.0 > #2 0x80168c12d at /usr/local/lib/libsamba-util.so.0 > #3 0x80168bfd7 at /usr/local/lib/libsamba-util.so.0 > #4 0x8014606df at /lib/libthr.so.3 > #5 0x80145fcbf at /lib/libthr.so.3 > [2016/06/19 01:26:41.064747, 0] ../source3/lib/dumpcore.c:313(dump_core) > unable to change to %N.core > refusing to dump core > > This occurs immediately when you start Samba so it's easy to replicate. > I know that 4.3 worked on r298887 for sure, I'm going to try this in VM too but I'd apperciate if anyone else could give this a go. > > I noticed that there were some changes in libthr which might be a clue.... > Please convince samba to allow to dump core on assert (I have no idea how), then get a backtrace from the core, using ports/devel/gdb. After that I may know where to look next. From owner-freebsd-current@freebsd.org Sun Jun 19 09:10:02 2016 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 E6B76A79EB8 for ; Sun, 19 Jun 2016 09:10:02 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (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 ADEBC2040 for ; Sun, 19 Jun 2016 09:10:02 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 922ADA80CE; Sun, 19 Jun 2016 11:10:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id MkcNN17GVwx6; Sun, 19 Jun 2016 11:09:58 +0200 (CEST) X-Originating-IP: 90.231.139.91 Received: from [192.168.1.249] (h91n1-gl-a-a31.ias.bredband.telia.com [90.231.139.91]) (Authenticated sender: daniel.engberg@pyret.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 4F18AA80CD; Sun, 19 Jun 2016 11:09:58 +0200 (CEST) Subject: Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4 To: Konstantin Belousov References: <0092113e-6ad6-575c-2127-f211ba9aef50@pyret.net> <20160619080644.GL38613@kib.kiev.ua> Cc: freebsd-current@freebsd.org From: Daniel Engberg Message-ID: Date: Sun, 19 Jun 2016 11:09:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160619080644.GL38613@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Jun 2016 09:10:03 -0000 On 2016-06-19 10:06, Konstantin Belousov wrote: > On Sun, Jun 19, 2016 at 09:10:08AM +0200, Daniel Engberg wrote: >> Hi, >> >> Decided to try ALPHA4 and Samba 4.3 and 4.4 doesn't seem very happy. >> >> Fatal error 'mutex 0x8013ec000 own 0x18cdc is on list 0x8112161a0 0x0' at line 153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4) >> [2016/06/19 01:14:47.689256, 0] ../lib/util/fault.c:78(fault_report) >> =============================================================== >> [2016/06/19 01:14:47.689450, 0] ../lib/util/fault.c:79(fault_report) >> INTERNAL ERROR: Signal 6 in pid 45222 (4.4.3) >> Please read the Trouble-Shooting section of the Samba HOWTO >> [2016/06/19 01:14:47.689479, 0] ../lib/util/fault.c:81(fault_report) >> =============================================================== >> [2016/06/19 01:14:47.689498, 0] ../source3/lib/util.c:791(smb_panic_s3) >> PANIC (pid 45222): internal error >> [2016/06/19 01:14:47.690577, 0] ../source3/lib/util.c:902(log_stack_trace) >> BACKTRACE: 6 stack frames: >> #0 0x803c16fe8 at /usr/local/lib/samba4/libsmbconf.so.0 >> #1 0x803c16ed2 at /usr/local/lib/samba4/libsmbconf.so.0 >> #2 0x801696dad at /usr/local/lib/samba4/libsamba-util.so.0 >> #3 0x801696c57 at /usr/local/lib/samba4/libsamba-util.so.0 >> #4 0x8014616df at /lib/libthr.so.3 >> #5 0x801460cbf at /lib/libthr.so.3 >> [2016/06/19 01:14:47.690686, 0] ../source3/lib/dumpcore.c:313(dump_core) >> unable to change to %N.core >> refusing to dump core >> >> Fatal error 'mutex 0x8013eb000 own 0x18d3d is on list 0x812e161a0 0x0' at line 153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4) >> [2016/06/19 01:26:41.063681, 0] ../lib/util/fault.c:78(fault_report) >> =============================================================== >> [2016/06/19 01:26:41.063827, 0] ../lib/util/fault.c:79(fault_report) >> INTERNAL ERROR: Signal 6 in pid 61297 (4.3.9) >> Please read the Trouble-Shooting section of the Samba HOWTO >> [2016/06/19 01:26:41.063844, 0] ../lib/util/fault.c:81(fault_report) >> =============================================================== >> [2016/06/19 01:26:41.063855, 0] ../source3/lib/util.c:789(smb_panic_s3) >> PANIC (pid 61297): internal error >> [2016/06/19 01:26:41.064679, 0] ../source3/lib/util.c:900(log_stack_trace) >> BACKTRACE: 6 stack frames: >> #0 0x803846eb8 at /usr/local/lib/libsmbconf.so.0 >> #1 0x803846da2 at /usr/local/lib/libsmbconf.so.0 >> #2 0x80168c12d at /usr/local/lib/libsamba-util.so.0 >> #3 0x80168bfd7 at /usr/local/lib/libsamba-util.so.0 >> #4 0x8014606df at /lib/libthr.so.3 >> #5 0x80145fcbf at /lib/libthr.so.3 >> [2016/06/19 01:26:41.064747, 0] ../source3/lib/dumpcore.c:313(dump_core) >> unable to change to %N.core >> refusing to dump core >> >> This occurs immediately when you start Samba so it's easy to replicate. >> I know that 4.3 worked on r298887 for sure, I'm going to try this in VM too but I'd apperciate if anyone else could give this a go. >> >> I noticed that there were some changes in libthr which might be a clue.... >> > > Please convince samba to allow to dump core on assert (I have no idea how), > then get a backtrace from the core, using ports/devel/gdb. After that I > may know where to look next. > Hi, Thanks for the quick reply, I'm not familiar to gdb but from what I found this seems to be correct way. sysctl kern.corefile=/var/log/samba4/%N.core (for whatever reason %N.core only doesn't seem to make Samba happy) /usr/local/bin/gdb /usr/local/sbin/smbd /var/log/samba4/smbd.core GNU gdb (GDB) 7.11.1 [GDB v7.11.1 for FreeBSD] Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd11.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/local/sbin/smbd...done. [New LWP 101688] Core was generated by `smbd'. Program terminated with signal SIGABRT, Aborted. #0 0x00000008055ed10a in ?? () (gdb) bt #0 0x00000008055ed10a in ?? () #1 0x00000008055ed0db in ?? () #2 0x0000000000018d38 in ?? () #3 0x8979efeec3bd9290 in ?? () #4 0x00007fffffffd2a4 in ?? () #5 0x00000008020f6020 in ?? () #6 0x00007fffffffd2c0 in ?? () #7 0x00000008055ed049 in ?? () #8 0x0000000000000000 in ?? () I guess that doesn't help much.... (debug option enabled in Samba port) Disabled following lines in /etc/make.conf and recompiled Samba # WITHOUT_DEBUG=YES # MK_PROFILE=no /usr/ports/net/samba44 # gdb /usr/local/sbin/smbd /var/log/samba4/smbd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `smbd'. Program terminated with signal 6, Aborted. #0 0x0000000805ce110a in ?? () (gdb) bt #0 0x0000000805ce110a in ?? () #1 0x0000000805ce10db in ?? () #2 0x0000000000018d31 in ?? () #3 0x3a0c606c1a35133b in ?? () #4 0x00007fffffffce04 in ?? () #5 0x0000000000000006 in ?? () #6 0x00007fffffffce20 in ?? () #7 0x0000000805ce1049 in ?? () #8 0x0000000000000000 in ?? () I have the following in /etc/src.conf MALLOC_PRODUCTION=yes WITHOUT_DEBUG_FILES=1 WITHOUT_LIB32=1 WITHOUT_KERNEL_SYMBOLS=yes and disabled the following in kernel config #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support # Debugging support. Always need this: #options KDB # Enable kernel debugger support. #options KDB_TRACE # Print a stack trace for a panic. # For full debugger support use (turn off in stable branch): #options DDB # Support DDB. #options GDB # Support remote GDB. #options DEADLKRES # Enable the deadlock resolver #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed #options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones So I guess I need to turn all this on again and recompile everything *sigh*, I'll do that and in the meantime try to replicate this in a VM. Best regards, Daniel From owner-freebsd-current@freebsd.org Sun Jun 19 09:17:23 2016 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 CA748A781A8 for ; Sun, 19 Jun 2016 09:17:23 +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 6535E2657 for ; Sun, 19 Jun 2016 09:17:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5J9HInL072774 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 19 Jun 2016 12:17:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5J9HInL072774 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5J9HIpW072773; Sun, 19 Jun 2016 12:17:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 19 Jun 2016 12:17:18 +0300 From: Konstantin Belousov To: Daniel Engberg Cc: freebsd-current@freebsd.org Subject: Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4 Message-ID: <20160619091718.GM38613@kib.kiev.ua> References: <0092113e-6ad6-575c-2127-f211ba9aef50@pyret.net> <20160619080644.GL38613@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 19 Jun 2016 09:17:23 -0000 On Sun, Jun 19, 2016 at 11:09:02AM +0200, Daniel Engberg wrote: > I have the following in /etc/src.conf > > MALLOC_PRODUCTION=yes > WITHOUT_DEBUG_FILES=1 Most important is to remove WITHOUT_DEBUG_FILES and recompile the world. From owner-freebsd-current@freebsd.org Sun Jun 19 04:11:23 2016 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 C9391A7A9EE for ; Sun, 19 Jun 2016 04:11:23 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 8FEC01E06 for ; Sun, 19 Jun 2016 04:11:23 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x22a.google.com with SMTP id p204so169132506oih.3 for ; Sat, 18 Jun 2016 21:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QHTNodRfZcCvJD0wabBaMbsFj8qNBkLmfD5R6J3BNp4=; b=PgOqgX+iwL01VhfM8HaynGH9tpDI8zayqxlitBZdgQRijFRO12WJRJNLKpmeY7rFgp NKYklc57iSadzUXwRTgTNopwg/aKflwuHQcIsdPKJ8psq/vP9mtSQ3aIH9+yGa/0cfpj ZNhxdgKPCZlAt42+aJR2LM0IpkbrILslAv0nF09xywaECI1f04+kK//DEMWvBVmPhOM9 qghesx7vRYam8XBWqutBzHhYRZF3QOjTbCkjHTQI6SE5EU4ffIg2kBGfdOeLlhsHxBkC Jd7EWIux3PTfKdMFHvWLv3OMAojXIuTBWPlvYSpHzz4r5yXzG1tlh6QSyP6XfXmnL1JV 6NlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QHTNodRfZcCvJD0wabBaMbsFj8qNBkLmfD5R6J3BNp4=; b=e6aqVNNC8XqH0Uc9HCFTTncJSNpGrrfgtZEtXV6ovt4tKFJLkfCnTAI81zuJOOqCRK gBXQeadgwifTQ3JEJDWlRENEmJzaP7rgQlPcBKNoIBvaW19vD8snIiEefRWAxo7G2u13 a63dgrRrXmvlnL/qGAamySQGcMWBXBh4XABk2la0K+b4LlEvRTg1H4LWLZgngPiUqmnc nmfCO8ucJ4c/CKVEXDgtqeTCthaoPWrCB7MD8pi6F+6CGFFmi7Aa0+y7q1R40B43OAsT Hkw7EFj8ZW4t9PVDM79DuyEf+HS/yMyGI6EUm+KgHhoIZuicZjoRqDbSfD8/Qjb+/Q9y GZKw== X-Gm-Message-State: ALyK8tJzZAnBw9Ew1/dOxZbDSQvq+Y/CAdSoFhpgWITiOkqbjD0tCvVOD+0qXhieyqX6YU3McyLEtG3A3iGyZWG0 X-Received: by 10.157.29.236 with SMTP id w41mr5304536otw.44.1466309482250; Sat, 18 Jun 2016 21:11:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.209 with HTTP; Sat, 18 Jun 2016 21:11:21 -0700 (PDT) In-Reply-To: References: <83A18C0E-FA89-4009-A8D5-3185FB27A688@netgate.com> From: Maxim Sobolev Date: Sat, 18 Jun 2016 21:11:21 -0700 Message-ID: Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current To: Jim Thompson , Luiz Otavio O Souza Cc: Svatopluk Kraus , "freebsd-arm@freebsd.org" , FreeBSD Current X-Mailman-Approved-At: Sun, 19 Jun 2016 11:04:10 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Jun 2016 04:11:23 -0000 Jim, some update from here. Running r283287 of the driver, I still see the same "watchdog timeout" messages, but they do not lead to the interface lockout. The traffic resumes momentarily. Which is probably why I never paid much attention to those warnings before. Therefore, I suspect that the new MAC code does not deal with watchdog-triggered interface reset as good as the old code. Does it give you any ideas about what could be wrong there by any chance? 03:54:50 CPSW watchdog cpsw0: watchdog timeout cpsw0: Unable to cleanly shutdown transmitter 03:58:03 CPSW watchdog cpsw0: watchdog timeout cpsw0: Unable to cleanly shutdown transmitter On Sat, Jun 18, 2016 at 2:09 PM, Maxim Sobolev wrote: > Jim, > > Yes, I've seen those. There were just handful of revision into the driver > between my old good kernel and now, most of them are from you guys: > > r299477 | gonzo | 2016-05-11 11:20:02 -0700 (=D1=81=D1=80, 11 =D0=BC=D0= =B0=D0=B9 2016) | 16 lines > r298352 | pfg | 2016-04-20 08:45:55 -0700 (=D1=81=D1=80, 20 =D0=B0=D0=BF= =D1=80 2016) | 6 lines > r297132 | loos | 2016-03-20 20:16:56 -0700 (=D0=B2=D1=81, 20 =D0=BC=D0=B0= =D1=80 2016) | 5 lines > r297043 | loos | 2016-03-18 13:24:31 -0700 (=D0=BF=D1=82, 18 =D0=BC=D0=B0= =D1=80 2016) | 4 lines > r297042 | loos | 2016-03-18 13:09:54 -0700 (=D0=BF=D1=82, 18 =D0=BC=D0=B0= =D1=80 2016) | 4 lines > r297041 | loos | 2016-03-18 13:04:34 -0700 (=D0=BF=D1=82, 18 =D0=BC=D0=B0= =D1=80 2016) | 4 lines > r296993 | loos | 2016-03-17 12:35:08 -0700 (=D1=87=D1=82, 17 =D0=BC=D0=B0= =D1=80 2016) | 24 lines > r296980 | loos | 2016-03-16 23:23:48 -0700 (=D1=81=D1=80, 16 =D0=BC=D0=B0= =D1=80 2016) | 6 lines > r283287 | andrew | 2015-05-22 07:25:23 -0700 (=D0=BF=D1=82, 22 =D0=BC=D0= =B0=D0=B9 2015) | 4 lines > (last known good one) > > I've reverted the driver to the state all way down to r283287, while > keeping the rest of the kernel intact and soon will see if it works bette= r. > If that works fine, I'll try to bi-sect it to a single troublesome revisi= on. > > -Max > > On Sat, Jun 18, 2016 at 12:26 PM, Jim Thompson wrote: > >> There are recent changes to enable the switch and two port MAC mode. >> >> These were lightly tested on BBB prior to being committed. >> >> -- Jim >> >> > On Jun 18, 2016, at 11:49 AM, Maxim Sobolev >> wrote: >> > >> > Well, I am not sure either as I don't have any issue restarting it >> > afterwards. >> > >> > Yes, it seems to be happening fairly reliably here. :( Happened for me >> > again, I left it running overnight. I am 99% positive it was not the >> case >> > before kernel upgrade.. >> > >> > 07:11:52 CPSW watchdog cpswss0: watchdog timeout >> > cpswss0: Unable to cleanly shutdown transmitter >> > >> > >> >> On Sat, Jun 18, 2016 at 1:09 AM, Svatopluk Kraus >> wrote: >> >> >> >> On Sat, Jun 18, 2016 at 8:50 AM, Maxim Sobolev >> >> wrote: >> >>> Updated my BBB to the latest -current, immediately got this while >> trying >> >> to >> >>> make world over ssh console: >> >>> >> >>> 06:02:17 CPSW watchdog cpswss0: watchdog timeout >> >>> cpswss0: Unable to cleanly shutdown transmitter >> >> >> >> My BBB stucks in cpsw0 during boot rarely, and even soft reset (reset >> >> button) does not help. Only hard reset (power-off) helps. I have neve= r >> >> had time to discover where a problem is. I'm not even sure if this is >> >> related to your problem as I did not remember exact dmesg in my case. >> >> >> >> Svata >> >> >> >> >> >>> >> >>> Interface seems to be locked after that, no traffic comes in or out. >> >>> >> >>> This is: >> >>> >> >>> FreeBSD 11.0-ALPHA3 #1 ba7edef(tps65217x)-dirty: Fri Jun 17 16:22:07 >> PDT >> >>> 2016, svn revision 301898 >> >>> >> >>> The previous version that was rock-solid was: >> >>> >> >>> FreeBSD 11.0-CURRENT #0 9d390ee(tps65217x)-dirty: Mon Jul 6 19:31:3= 0 >> PDT >> >>> 2015, svn revision 284878 >> >>> >> >>> I've been running buildworlds for literally days on that board, >> because >> >>> it's how long it takes to build on that hardware. :) >> >>> >> >>> I'll run it again and see if the issue re-appears. >> >>> >> >>> If anyone seen this or if it's known issue please let me know. >> >>> >> >>> Thanks! >> >>> >> >>> -Max >> >>> _______________________________________________ >> >>> freebsd-arm@freebsd.org mailing list >> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.or= g >> " >> > _______________________________________________ >> > freebsd-arm@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> >> > --=20 Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-current@freebsd.org Sun Jun 19 17:49:05 2016 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 6AE70A7AFB4 for ; Sun, 19 Jun 2016 17:49:05 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 229651DDF for ; Sun, 19 Jun 2016 17:49:05 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qk0-x234.google.com with SMTP id c73so137364511qkg.2 for ; Sun, 19 Jun 2016 10:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gAQbMI/iiAkRX6JpoKbpVF5zfWrXPKBXzfe6Y8sZsq0=; b=WieUq8K9j8Jdy2/J8vQu5T54U2f8lqQakMbidYGy81QVsVYsVBmpAupH7fpoGR0QKV Lh2GrWSrZwsJTl2LxE2yRgXzAWrSSGPUBapkNS6DCtPVlkJbcQC4YElUtOgkOkfOK39v sGADTnanyuIUSEn12hsnLpvgrfhpSqT2eu+nvRMci2T3wLsLNLaSzv5hfn2awjUuSfrN /veXirzi5F7oPO+VrVpe+Br9+VbRYbWMgq682LTyWKI0K2TcKSL0mhUYh4nL22D4GFAf RV23X/C+eOFeA723OfUF+K3WNQ0WbIYuCAfAxb1bKZTzncAWixeWxZL2vdayyVQ1pJKw XDQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gAQbMI/iiAkRX6JpoKbpVF5zfWrXPKBXzfe6Y8sZsq0=; b=VqcK3apOf+qyMIT+q2Ce0ii5dC0Lj1uOej8zBEFewvlpkUV2JtL+mJvFAISIORscSB TEkxn6v1pULdfWr3z9HtgJ+MM9oEyKjkvmdeTe7kXcMXOz7RCY29cVqCeINrSjSNTwWP iPC1qmNRymV0QtqdrhbkwT6GOdVJhEY2cEeGWstbV0g1iVnVPbTgUBpE1UGzkQnANfSj 40J29yiPgS/i8EIIAqLYLvde7WIM+I63vpBTRR4pKW4Ox8/JFfeWFUUVsa4LiJdjtrR2 p4iT1gKE+s46Eex/IoLotrQ2N1fRuB0rZUgF8QpEZxV3IDEGroaZ+/tLapKoxEFKszxo 4ECg== X-Gm-Message-State: ALyK8tLNXRxPDN733j4ivjOstcIoZ73hZvagx1jqFskltvm8BEaH37lB6OsNhNAgZrbR4UQlBftMdM6mRUe1Nw== X-Received: by 10.55.165.69 with SMTP id o66mr16703378qke.153.1466358544128; Sun, 19 Jun 2016 10:49:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.148.131 with HTTP; Sun, 19 Jun 2016 10:49:03 -0700 (PDT) In-Reply-To: References: <64CF176D-910E-417D-98E2-9B2C64521444@gmail.com> <20150408023559.GN2379@kib.kiev.ua> <4D7C5AA4-0E7A-4470-983A-32D6EF605A1F@gmail.com> From: Ngie Cooper Date: Sun, 19 Jun 2016 10:49:03 -0700 Message-ID: Subject: Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i To: Mehmet Erol Sanliturk Cc: Konstantin Belousov , freebsd-current Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Jun 2016 17:49:05 -0000 On Thu, Apr 9, 2015 at 12:10 AM, Garrett Cooper wro= te: ... > It booted both FreeBSD/Linux without my controller =E2=80=94 the hardware= compatibility with it just sucks. > > Email back from ASUS, =E2=80=9Cit=E2=80=99s not in our compatibility list= . Use another card=E2=80=9D. Uh, yeah=E2=80=A6 right. Not going to dump ano= ther $300 in an LSI card and redo my RAID. Guess I=E2=80=99ll purchase anot= her motherboard. > > Thank you for the input everyone. I=E2=80=99ll leave a helpful review on = Newegg so others don=E2=80=99t stumble on this either. (following up/closing out the thread from last year on a more constructive = note) I recently had to replace my P6T-WS motherboard/CPU because it finally bit the dust (it was 7 years old). I found a ASUS desktop board that worked with the before mentioned LSI card -- ASUS Z170M-E D3. The compatibility list didn't mention my LSI card specifically, but it said that they validated the 9260-4i card, which was "close enough" apparently. The card's detected properly at POST, it attaches in FreeBSD, and the volume looks AOK. The only thing that's slightly annoying is that the chipset does some silly things with the onboard graphics when I plug it in initially (I believe it thinks it's a graphics card..), so I had to tweak some BIOS settings. Thanks! -Ngie From owner-freebsd-current@freebsd.org Sun Jun 19 18:36:40 2016 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 58F2EA7ACD7 for ; Sun, 19 Jun 2016 18:36:40 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 1C98A17CF for ; Sun, 19 Jun 2016 18:36:39 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x230.google.com with SMTP id t129so172338974vka.1 for ; Sun, 19 Jun 2016 11:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=9NCPtjOhQ9gtLJhDzdu+L6fs8uTMOnZ3U/PtsAFz988=; b=ENHP4cNB4etGZH2TsttpsM2yEsJJBUgRj4l5bFAKVo3POgFQyExqp7mPvTFYpa+8MG 2Y6E05ug+/wjbL8cbNHfOLfZHgo8YmgZ/nEM/BXlvQGtXJMthkN/ANgd/l76t3uFxwK+ Nrcn2cURSL9nRNTDHxahB0PqTw3VWHytnVmQcSQm6p+REoD+kLwuYl2f8x4hYDJ02Vwv IwKG9hR8y/5NecPZ/xAGwyCRd3OzxaqMspI9Ah3B4PSLnO3k7i6s1e6Xp3v7RI8mZsHo b3Z0WKgcQdKe/E+SsB6I1fV07wub2teL8DBj6g5IsDvM+Yr6JQEjn1F6HCl/RgxBC6gY IMxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9NCPtjOhQ9gtLJhDzdu+L6fs8uTMOnZ3U/PtsAFz988=; b=euD1m7/sn2KPb+1vOq5Fksx0Etu5PR1BFa0b+iMB0806FfApifkhDMDw5hg8xChqTX 6tQ+V1SqQH5ASpm07/b+9Ya3sS1c2trSDiB4T6nxFY3d0XPwjh+b5TbpvlxL6UEvVD2z Z+IkxFdFmJPV/Atb1r0qvYxuanoSnRrDG6+3zJ/5QzT8klHJrMBpj6+oqZoNH9eBqvxm FcFOO0D8JUY2tMJvKgYd9nDuAehL6Dzigp21/00kvXG6gszekHZiqNgkglY4WSy7oW0d pHQoG/5zFOZkmB0ZfcRcxKkeM8NalySfhNAyEX0GoI1SLbFo0H7bcbtKmaOopOXRSUhp wKIQ== X-Gm-Message-State: ALyK8tJlwA6WyZquca+b4dBFU+Mxawqw+bsneTqMp/iqgf8r3ct9qeltfIYT/O4cnU20bCs3rlr9IHPWvC/kMewIBQ9/7PaPAKmIZGiXTBdLax8vn1Y1hMkX2z6Zh3wI1XXoVjThEJDfiCz6xtbTR7djPHA= X-Received: by 10.176.2.177 with SMTP id 46mr5223757uah.7.1466361393727; Sun, 19 Jun 2016 11:36:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.33 with HTTP; Sun, 19 Jun 2016 11:36:19 -0700 (PDT) From: "Lundberg, Johannes" Date: Sun, 19 Jun 2016 11:36:19 -0700 Message-ID: Subject: Intel Atom I2C To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Jun 2016 18:36:40 -0000 Hi I am trying to figure out how to get I2C support on Intel Atom x5 (Cherryview), which should be same for Baytrail platforms. On the Serial I/O device (PCI device 24) there are 8 devices. #0 is DMA controller #1-7 are I2C controllers (1 & 2 available on GPIO pins). I assume that all traffic to/from the I2C controllers must go via the DMA controller although I'm not 100% sure. In page 23 in the atom-z8000-datasheet-vol-2 there is a nice table of the PCI configuration space. On Linux they have i2c/busses/i2c-designware-* and dma/dw/* that takes care of the I2C and DMA parts. The ichiic (ig4) driver seems to be working on this platform and looking through the registers it seems to be basically the same as i2c-designware driver, but it doesn't not detect any devices on the I2C bus (/dev/smbx). (I have confirmed that the devices are recognized on Linux on the same device.) We also need a Mailbox (IOSF-SB MBI) driver and it is quite simple so I have already ported this. What is left to do I guess would be to implement a DMA driver that works with ig4 or create a new ig4 driver that is extended to use the DMA controller, and implement the DMA controller driver. Implementing from scratch would be quite the undertaking. Can we leverage any existing DMA infrastructure for this? Any one interested in helping? I have a board called "UP" which is very similar to Raspberry Pi but Intel SoC. It has IC20 and IC21 available on the 40-pin connector. Since it's Intel most stuff just works. Thanks to mmacy accelerated graphics is also working (on separate branch). It really is a great board for anyone who likes to tinker :) References: http://www.up-board.org/ http://lxr.linux.no/#linux+v4.6.2/drivers/i2c/busses http://lxr.linux.no/#linux+v4.6.2/drivers/dma/dw http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-datasheet= -vol-1.html http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-datasheet= -vol-2.html Other TODO stuff: Port Imer's GPIO driver from DragonFly Add support for S0ix sleep states (would be useful for all new Intel low power laptops since Haswell) And more... Thanks! /Johannes --=20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-current@freebsd.org Sun Jun 19 19:11:48 2016 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 E10ADA7A603 for ; Sun, 19 Jun 2016 19:11:48 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 C77FA1CE5 for ; Sun, 19 Jun 2016 19:11:48 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: b6342906-3651-11e6-a0ff-e511cd071b9b X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 19 Jun 2016 19:12:05 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u5JJBf0x001676; Sun, 19 Jun 2016 13:11:41 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1466363501.34556.33.camel@freebsd.org> Subject: Re: Intel Atom I2C From: Ian Lepore To: "Lundberg, Johannes" , FreeBSD Current Date: Sun, 19 Jun 2016 13:11:41 -0600 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Jun 2016 19:11:49 -0000 On Sun, 2016-06-19 at 11:36 -0700, Lundberg, Johannes wrote: > Hi > > I am trying to figure out how to get I2C support on Intel Atom x5 > (Cherryview), which should be same for Baytrail platforms. > > On the Serial I/O device (PCI device 24) there are 8 devices. > #0 is DMA controller > #1-7 are I2C controllers (1 & 2 available on GPIO pins). > > I assume that all traffic to/from the I2C controllers must go via the > DMA > controller although I'm not 100% sure. > > In page 23 in the atom-z8000-datasheet-vol-2 there is a nice table of > the > PCI configuration space. > > On Linux they have > i2c/busses/i2c-designware-* > and > dma/dw/* > that takes care of the I2C and DMA parts. > > The ichiic (ig4) driver seems to be working on this platform and > looking > through the registers it seems to be basically the same as i2c > -designware > driver, but it doesn't not detect any devices on the I2C bus > (/dev/smbx). > (I have confirmed that the devices are recognized on Linux on the > same > device.) > There is no way to automatically detect devices on an i2c bus. You can, with some incomplete success, detect which addresses are in use. Even when you can detect there is a device at a given address, there is no way to figure out what that device is (and in some rare cases, even probing for the address being in use can perturb the device). So, in the linux case, something must be telling the OS which drivers to attach to which addresses. I have no idea what that mechanism might be, if it's not FDT. In freebsd, you can specify i2c devices using FDT data, or hints. -- Ian > We also need a Mailbox (IOSF-SB MBI) driver and it is quite simple so > I > have already ported this. > > What is left to do I guess would be to implement a DMA driver that > works > with ig4 or create a new ig4 driver that is extended to use the DMA > controller, and implement the DMA controller driver. > > Implementing from scratch would be quite the undertaking. Can we > leverage > any existing DMA infrastructure for this? > > Any one interested in helping? > > I have a board called "UP" which is very similar to Raspberry Pi but > Intel > SoC. It has IC20 and IC21 available on the 40-pin connector. > Since it's Intel most stuff just works. Thanks to mmacy accelerated > graphics is also working (on separate branch). > It really is a great board for anyone who likes to tinker :) > > > References: > http://www.up-board.org/ > http://lxr.linux.no/#linux+v4.6.2/drivers/i2c/busses > http://lxr.linux.no/#linux+v4.6.2/drivers/dma/dw > http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat > asheet-vol-1.html > http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat > asheet-vol-2.html > > Other TODO stuff: > Port Imer's GPIO driver from DragonFly > Add support for S0ix sleep states (would be useful for all new Intel > low > power laptops since Haswell) > And more... > > Thanks! > /Johannes > From owner-freebsd-current@freebsd.org Sun Jun 19 19:23:15 2016 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 E4D8DA7AAA1 for ; Sun, 19 Jun 2016 19:23:15 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 9CBA92240 for ; Sun, 19 Jun 2016 19:23:15 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x235.google.com with SMTP id d185so173064112vkg.0 for ; Sun, 19 Jun 2016 12:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=NMnNgPVpVlwN+JrJH9Iu/3icbY+xyyvpaSJUISBRG3c=; b=YR5g+6GeDMLpOaLwbsypdu1mU0gkVeytg6jwprL90FtMJKxjY2MaWl0oetyC1c5Ros SxxwvyEYVA6GbQiXJ63wSf1ePpdxWY9NdLc1V/LzESMN3IiKyhCh/Rf4HsFh8IqBj+mm wlWVs9gJhpZdYGOdNCl24HU7UVXaQ3IufOjaAO2m7zA8EVYtERPu915RyeEPyz+HaGqh /Uc4BF5FNtkB4SrUgCnou6sSwEipJ6OZg9fidwRM5d7FRamxaNlMVDddl26bqrlC3ZJj uW7UgK/SRpoxApkLtfqp2OwmHUoR6G7+NlpZ0PQ8mrX5kiNM48HKWg8FbjEkB8eWXWhZ 1u1A== 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; bh=NMnNgPVpVlwN+JrJH9Iu/3icbY+xyyvpaSJUISBRG3c=; b=SQJMdTHc9FULbvlV/h4ebnJgkJnYvCyWhJgqGIsApjwjmaJIZcZVJd9C7x7YAmWj2V KTT9k34w5jK0m7SbX6AominT3NXtrDGcDs+4e+eWfMM3b7nyZwgshaWJCDYuo2dxl5sE t/cBJcGbqRrUoWppxMlwqqobdzp2PkTd0aSu3KpNvAngYSacZKS4QYz4qHXsj37Zpi6Q X6Ez4NK/PfiTQ52xfhpxqBVWe7oKsVhM4/HIuSft5F0u8eez2Ub5HDhkR0kCdjuLsW+f 4Tl1aIEPnsQHm172b8uUNCZsnZgMXj3E0wuugRzAM5JaPMcNds4kQ1R0MP3l4FM7iTLI /07A== X-Gm-Message-State: ALyK8tKFoY1WRb9+f/xh1rvqUgGtGIswqxTxYJbqZ5SHnLKHk6/Qw/4CtEV3uShLvHVMcR2JQr5cMq8cy9HOr688X3rp7coD58A4xn57tG532+mmJRdoTAgzCYYA6hNpgqCO5dNrc4hSyY8VHEHNVcsexH0= MIME-Version: 1.0 X-Received: by 10.159.37.66 with SMTP id 60mr4024870uaz.56.1466364194594; Sun, 19 Jun 2016 12:23:14 -0700 (PDT) Received: by 10.159.40.33 with HTTP; Sun, 19 Jun 2016 12:23:14 -0700 (PDT) In-Reply-To: <1466363501.34556.33.camel@freebsd.org> References: <1466363501.34556.33.camel@freebsd.org> Date: Sun, 19 Jun 2016 12:23:14 -0700 Message-ID: Subject: Re: Intel Atom I2C From: "Lundberg, Johannes" To: Ian Lepore Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Jun 2016 19:23:16 -0000 Hi Ian Thanks for the info. I'll give it a try and see if I have more success. I'm still uncertain about the role of the DMA controller though. If data has to be relayed through it or if using it is optional.. Maybe some further testing will reveal the truth.. On Sunday, June 19, 2016, Ian Lepore wrote: > On Sun, 2016-06-19 at 11:36 -0700, Lundberg, Johannes wrote: > > Hi > > > > I am trying to figure out how to get I2C support on Intel Atom x5 > > (Cherryview), which should be same for Baytrail platforms. > > > > On the Serial I/O device (PCI device 24) there are 8 devices. > > #0 is DMA controller > > #1-7 are I2C controllers (1 & 2 available on GPIO pins). > > > > I assume that all traffic to/from the I2C controllers must go via the > > DMA > > controller although I'm not 100% sure. > > > > In page 23 in the atom-z8000-datasheet-vol-2 there is a nice table of > > the > > PCI configuration space. > > > > On Linux they have > > i2c/busses/i2c-designware-* > > and > > dma/dw/* > > that takes care of the I2C and DMA parts. > > > > The ichiic (ig4) driver seems to be working on this platform and > > looking > > through the registers it seems to be basically the same as i2c > > -designware > > driver, but it doesn't not detect any devices on the I2C bus > > (/dev/smbx). > > (I have confirmed that the devices are recognized on Linux on the > > same > > device.) > > > > There is no way to automatically detect devices on an i2c bus. You > can, with some incomplete success, detect which addresses are in use. > Even when you can detect there is a device at a given address, there > is no way to figure out what that device is (and in some rare cases, > even probing for the address being in use can perturb the device). > > So, in the linux case, something must be telling the OS which drivers > to attach to which addresses. I have no idea what that mechanism might > be, if it's not FDT. > > In freebsd, you can specify i2c devices using FDT data, or hints. > > -- Ian > > > We also need a Mailbox (IOSF-SB MBI) driver and it is quite simple so > > I > > have already ported this. > > > > What is left to do I guess would be to implement a DMA driver that > > works > > with ig4 or create a new ig4 driver that is extended to use the DMA > > controller, and implement the DMA controller driver. > > > > Implementing from scratch would be quite the undertaking. Can we > > leverage > > any existing DMA infrastructure for this? > > > > Any one interested in helping? > > > > I have a board called "UP" which is very similar to Raspberry Pi but > > Intel > > SoC. It has IC20 and IC21 available on the 40-pin connector. > > Since it's Intel most stuff just works. Thanks to mmacy accelerated > > graphics is also working (on separate branch). > > It really is a great board for anyone who likes to tinker :) > > > > > > References: > > http://www.up-board.org/ > > http://lxr.linux.no/#linux+v4.6.2/drivers/i2c/busses > > http://lxr.linux.no/#linux+v4.6.2/drivers/dma/dw > > http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat > > asheet-vol-1.html > > http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat > > asheet-vol-2.html > > > > Other TODO stuff: > > Port Imer's GPIO driver from DragonFly > > Add support for S0ix sleep states (would be useful for all new Intel > > low > > power laptops since Haswell) > > And more... > > > > Thanks! > > /Johannes > > > --=20 Sent from Gmail Mobile --=20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-current@freebsd.org Sun Jun 19 20:08:58 2016 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 BCA6AA7966C; Sun, 19 Jun 2016 20:08:58 +0000 (UTC) (envelope-from gjb@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 A2EF21A4E; Sun, 19 Jun 2016 20:08:58 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 4E04F162C; Sun, 19 Jun 2016 20:08:58 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sun, 19 Jun 2016 20:08:57 +0000 From: Glen Barber To: Ivan Klymenko Cc: freebsd-snapshots@freebsd.org, freebsd-current@freebsd.org, FreeBSD Release Engineering Team Subject: Re: New FreeBSD snapshots available: head (20160617 r301975) Message-ID: <20160619200857.GI28666@FreeBSD.org> References: <20160618055811.GA35283@FreeBSD.org> <1466233842.650879797.mfv3fjy1@frv33.fwdcdn.com> <20160618140250.GB28666@FreeBSD.org> <20160618230722.GC28666@FreeBSD.org> <20160619104802.236aa92b@nonamehost.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cf0hFtnykp6aONGL" Content-Disposition: inline In-Reply-To: <20160619104802.236aa92b@nonamehost.local> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Jun 2016 20:08:58 -0000 --cf0hFtnykp6aONGL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 19, 2016 at 10:48:02AM +0300, Ivan Klymenko wrote: > On Sat, 18 Jun 2016 23:07:22 +0000 > Glen Barber wrote: >=20 > > On Sat, Jun 18, 2016 at 02:02:50PM +0000, Glen Barber wrote: > > > On Sat, Jun 18, 2016 at 10:12:07AM +0300, fidaj wrote: =20 > > > > =3D=3D=3D Installation ISOs =3D=3D=3D > > > >=20 > > > > Installation images are available for: > > > >=20 > > > > o 11.0-ALPHA4 amd64 GENERIC > > > > o 11.0-ALPHA4 i386 GENERIC > > > > o 11.0-ALPHA4 powerpc GENERIC > > > > o 11.0-ALPHA4 powerpc64 GENERIC64 > > > > o 11.0-ALPHA4 sparc64 GENERIC > > > > o 11.0-ALPHA4 armv6 BANANAPI > > > > o 11.0-ALPHA4 armv6 BEAGLEBONE > > > > o 11.0-ALPHA4 armv6 CUBIEBOARD > > > > o 11.0-ALPHA4 armv6 CUBIEBOARD2 > > > > o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD > > > > o 11.0-ALPHA4 armv6 GUMSTIX > > > > o 11.0-ALPHA4 armv6 RPI-B > > > > o 11.0-ALPHA4 armv6 RPI2 > > > > o 11.0-ALPHA4 armv6 PANDABOARD > > > > o 11.0-ALPHA4 armv6 WANDBOARD > > > > o 11.0-ALPHA4 aarch64 GENERIC > > > > =20 > > > > Hello.=20 > > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ > > > > not have manifest file.=20 > > >=20 > > > Huh. Yep, this is a problem. > > >=20 > > > Thank you for the report. I'll investigate what happened here. > > > =20 > >=20 > > This doesn't make sense. The MANIFEST exists on the build machine, > > and should have been copied as result of the distribution to the > > mirrors. > >=20 > > I don't understand how it did not make it to the mirrors. > >=20 > > So I know, how did you discover this? > >=20 > > I *do* see the MANIFEST for amd64, so something very bizarre happened > > here. > >=20 > > Glen > >=20 >=20 > It breaks my poudriere. > poudriere jail -c -v 11.0-ALPHA4 -a i386 -j 11_ALPHA4_i386 -m > url=3Dftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ This is even stranger than originally thought. The MANIFEST file *does* exist now, but I did not manually put it there. I don't think anyone else did either. So, I have no idea what happened, but thank you for this report. One more thing to double-check before sending these emails. Glen --cf0hFtnykp6aONGL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXZvvZAAoJEAMUWKVHj+KTNDwP/j/2wmRecfr+pHBhnslHwPBJ UWDKqYmbEtfLthSvoWi+0cq1pV57E7xwSSPfknQfeINHfF4vtW3ynV+a9YAQGDU7 D1otPmjQPR5HIPyzxLT67A7JCuYdMemzZYzBe1zoMW/xxhV7LY4gE/21FQ/4jOcy FZ5cmiUQELBQJ+iyaEhdEHr14PaNaEcuECopVU30b9Kb6B2hHiX28+6IsPjSGF04 HY/oxCZkB8skeX1Z5EafcYUItCN6852kibEN7Zm+eyJhBX5M1sPXDMujFOHNVV4G KIcnx/AxbVz3kXDRxlOQoRMzAZjwACf/mXWNKAAsSctIwaVBkdwrEolJPmgF1oO8 IizL4A7bPrIG1w82I4M4tDjicqHz5xbBZj61eQaFjtfZo0sV6tBGBUWqOxdftIhq 2Tk6QlXGI32iw57U5/9thKMoVl4k8FkPDmBAGi2la7wG8/fqoY0uU/Q9TNJxngfQ U8AP25N488I6JLaPynS+Z5mNR0bAebBxEf/lrFMfY6fvW1MaNKnVAP1QYLo/58Aj 4dGtyRIHTLpE9uPUrC0KgE/yXYB6N+UVwk7wFaGxfXZLOcpK45FwpVUGkCSwq96Z pFBIYs00VJnovnMp4xmwjZje+MksAzI4ZMWS9G3I1OY8bFjIHoZYwjp8/F/XZGvm QlN/+5N5enQ5R1uFrIC7 =slIO -----END PGP SIGNATURE----- --cf0hFtnykp6aONGL-- From owner-freebsd-current@freebsd.org Sun Jun 19 23:38:55 2016 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 EB384A7A394 for ; Sun, 19 Jun 2016 23:38:55 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 CDCDB1675 for ; Sun, 19 Jun 2016 23:38:55 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=c/eXoWMgcE/HMYO/xiMszi0yf7xRVyN2uUPaSZOkI5A=; b=wMmv8CGoXcfUv1K3kjh+hE3BqH AqmEV7/L9058ib7hV1IVlgZC3NjILREQKLNWgt82F9sgWD0w+2HGVoEbJOUvfh/Ii/Wz6/svZ49D7 +nj/NPr13utO1dSa4nRtvXIDqfqqkAFxyphNoymJ2DY+vtHyx+LZoY9vhnmYh2wcVlXU=; Received: from [114.121.237.114] (port=43918 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bEmIi-002Jr7-Va for freebsd-current@freebsd.org; Sun, 19 Jun 2016 17:38:49 -0600 Date: Mon, 20 Jun 2016 07:38:40 +0800 From: Erich Dollansky To: FreeBSD Current Subject: Compiling 11 on a Raspberry B+ 2 failes Message-ID: <20160620073840.6741172a@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Authenticated-Sender: sl-508-2.slc.westdc.net: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 19 Jun 2016 23:38:56 -0000 Hi, I am trying to compile HEAD on a Raspberry and get always the following error. Of course, compiling revision 302017 on amd64 works. Erich Last Changed Rev: 301974 /usr/src/lib/csu/arm/crt1.c:(.text+0xb4): relocation truncated to fit: R_ARM_CALL against symbol `atexit' defined in .text section in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xbc): relocation truncated to fit: R_ARM_CALL against symbol `_init_tls' defined in .text section in /usr/lib/libc.a(tls.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xcc): relocation truncated to fit: R_ARM_CALL against symbol `atexit' defined in .text section in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0x174): relocation truncated to fit: R_ARM_CALL against symbol `exit' defined in .text section in /usr/lib/libc.a(exit.o) /usr/lib/crt1.o: In function `finalizer': /usr/src/lib/csu/arm/crt1.c:(.text+0x1ec): relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini' defined in .fini section in /usr/lib/crti.o c++: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[4]: stopped in /usr/src.head/usr.bin/clang/clang *** Error code 1 Stop. bmake[3]: stopped in /usr/src.head/usr.bin/clang *** Error code 1 Stop. bmake[2]: stopped in /usr/src.head *** Error code 1 Stop. bmake[1]: stopped in /usr/src.head *** Error code 1 Stop. make: stopped in /usr/src.head [raspberry2]~/System (root) > _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Jun 20 02:41:58 2016 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 ADC27A7B63B for ; Mon, 20 Jun 2016 02:41:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 6F0D717CA for ; Mon, 20 Jun 2016 02:41:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1226 invoked from network); 20 Jun 2016 02:42:32 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 20 Jun 2016 02:42:32 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sun, 19 Jun 2016 22:42:40 -0400 (EDT) Received: (qmail 25473 invoked from network); 20 Jun 2016 02:42:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Jun 2016 02:42:40 -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.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 2F4C0B1E001; Sun, 19 Jun 2016 19:41:50 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Compiling 11 on a Raspberry B+ 2 failes [not in my experience for -r301975] Message-Id: Date: Sun, 19 Jun 2016 19:41:54 -0700 To: erichsfreebsdlist@alogt.com, freebsd-arm , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 02:41:58 -0000 Quoting Erich Dollansky erichsfreebsdlist at alogt.com Sun Jun 19 = 23:38:56 UTC 2016 : > I am trying to compile HEAD on a Raspberry and get always the = following > error. >=20 > Of course, compiling revision 302017 on amd64 works. >=20 > Erich >=20 > Last Changed Rev: 301974 >=20 > /usr/src/lib/csu/arm/crt1.c:(.text+0xb4): relocation truncated to > fit: R_ARM_CALL against symbol `atexit' defined in .text section > in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xbc): > relocation truncated to fit: R_ARM_CALL against symbol `_init_tls' > defined in .text section > in /usr/lib/libc.a(tls.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xcc): > relocation truncated to fit: R_ARM_CALL against symbol `atexit' = defined > in .text section > in /usr/lib/libc.a(atexit.o) = /usr/src/lib/csu/arm/crt1.c:(.text+0x174): > relocation truncated to fit: R_ARM_CALL against symbol `exit' defined > in .text section in /usr/lib/libc.a(exit.o) /usr/lib/crt1.o: In > function `finalizer': /usr/src/lib/csu/arm/crt1.c:(.text+0x1ec): > relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini' > defined in .fini section in /usr/lib/crti.o c++: error: linker command > failed with exit code 1 (use -v to see invocation) *** Error code 1 >=20 > Stop. > bmake[4]: stopped in /usr/src.head/usr.bin/clang/clang > *** Error code 1 >=20 > Stop. > bmake[3]: stopped in /usr/src.head/usr.bin/clang > *** Error code 1 >=20 > Stop. > bmake[2]: stopped in /usr/src.head > *** Error code 1 >=20 > Stop. > bmake[1]: stopped in /usr/src.head > *** Error code 1 >=20 > Stop. > make: stopped in /usr/src.head > [raspberry2]~/System (root) >=20 I've done buildworld buildkernel for -r301975 on an rpi2 (not using = WITH_META_MODE=3Dyes) with no problem. The rpi2 was already running = -r301975 via a amd64 -> rpi2 cross build. You do not mention what vintage of 11.0 your -r301974 build was started = from. A uname -apKU output would be appropriate to post as one way of indicating that. My WITH_META_MODE=3Dyes buidlworld buildkernel is still in process. Later below list my src.conf showing my slightly odd choices targeting = armv7-a/cortex-a7 explicitly. I'd be surprised if that makes a = difference for this issue. You have not provided your src.conf or = make.conf or other such context. My -r301975 cross builds on amd64 targeting an rpi2 [armv7-a/cortex-a7] = have all worked fine (no matter if WITH_META_MODE_yes was in use or = not). I've only used the system clang 3.8.0 to target armv6 in modern times. My src.conf for rpi2 self hosted builds looks like: > # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host=20 > TO_TYPE=3Darmv6 > # > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > #WITH_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > # > #CPUTYPE=3Dsoft > WITH_LIBSOFT=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > #WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > # There is no XCPPFLAGS but XCPP ets XCFLAGS content. The ~/src.configs/make.conf is empty. The amd64 -> rpi2 cross builds are only different for src.conf by: > # diff ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host = ~/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host=20 > 10,11c10,11 > < #WITH_CROSS_COMPILER=3D > < WITH_SYSTEM_COMPILER=3D > --- > > WITH_CROSS_COMPILER=3D > > WITHOUT_SYSTEM_COMPILER=3D > 17c17 > < #WITHOUT_CLANG_BOOTSTRAP=3D > --- > > WITH_CLANG_BOOTSTRAP=3D Showing the "on a rpi2" script that runs make for using = WITH_META_MODE=3Dyes : > # more = ~/sys_build_scripts.rpi2-host/make_rpi2_nodebug_clang_bootstrap-rpi2-host.= sh=20 > kldload -n filemon && \ > script = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-rpi2-host-$= (date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host"= \ > WITH_META_MODE=3Dyes \ > MAKEOBJDIRPREFIX=3D"/usr/obj/clang/arm.armv6" \ > make $* My /usr/src tree has some changes/additions --but mostly for powerpc64 = and powerpc issues: > # svnlite status /usr/src/ > M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp > M /usr/src/lib/csu/powerpc64/Makefile > ? /usr/src/sys/amd64/include/include > ? /usr/src/sys/arm/conf/RPI2-NODBG > ? /usr/src/sys/arm/include/include > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/Makefile.powerpc > M /usr/src/sys/conf/kern.mk > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c > M /usr/src/sys/dev/cxgbe/tom/t4_listen.c > ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > ? /usr/src/sys/powerpc/include/include > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/exec_machdep.c > ? /usr/src/sys/x86/include/include (The include/include ones are from something making links pointing back = up to the parent include/ . I did not explicitly create these.) (The cxbg and cxbge ones were from trying to have amd64 target amd64 via = xtoolchain (devel/amd64-gcc). But other places also stopped it and I = quit trying that for now.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Jun 20 05:09:12 2016 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 A9439A7A1CE for ; Mon, 20 Jun 2016 05:09:12 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from mippet.ci.com.au (mippet.ci.com.au [192.65.182.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mippet.ci.com.au", Issuer "mippet.ci.com.au" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F8262EF5 for ; Mon, 20 Jun 2016 05:09:11 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from jodi.ci.com.au (jodi.ci.com.au [192.168.1.21]) by mippet.ci.com.au (8.15.2/8.15.2/CE160407) with ESMTPS id u5K4sUZ2004362 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 20 Jun 2016 14:54:31 +1000 (AEST) (envelope-from rpp@ci.com.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ci.com.au; s=jun2016; t=1466398471; bh=IcVNcmFoLBgOb6y/04NmzRRrtMhlV52lcoRFFLgXRLM=; h=Date:From:To:Subject; b=YO278fZ3UN35clehm272dRXrEpxnP5ZMz0m1fSmXYaJjEJzzO4Z7p6Z0Cx6TJb0Yl qMk8l9w6tv9KoKVSVtvN4kv5LzxeXLfC3Bnou00vOdxXrahdrdswBba3zgbPea+0Nj cKhKsyArboVua9nIaAvgQ11TeoASz4PW8eWb9DgLBlON4OrnEcn+uPTbQb5o1fOO7v 4La0CsvdoEodxM6MoIWqhnd0xzXk6nGBR4dYoH/Mt0XliTYt5EDR/WiVkE0L1xRZg1 OyiQpVLwRqcwY4UxlTVuwOE7ygW+0k4lSDcNSIWUA4gnoDpOTPbBa7IzIrwNTxlIgx LwY4PqmbE1DyQ== Received: from jodi.ci.com.au (localhost [127.0.0.1]) by jodi.ci.com.au (8.15.2/8.15.2) with ESMTP id u5K4sUrL047555 for ; Mon, 20 Jun 2016 14:54:30 +1000 (AEST) (envelope-from rpp@jodi.ci.com.au) Received: (from rpp@localhost) by jodi.ci.com.au (8.15.2/8.15.2/Submit) id u5K4sUS4047553 for freebsd-current@freebsd.org; Mon, 20 Jun 2016 14:54:30 +1000 (AEST) (envelope-from rpp) Date: Mon, 20 Jun 2016 14:54:30 +1000 From: Richard Perini To: freebsd-current@freebsd.org Subject: Reproducible igb related panic 11.0-ALPHA4 Message-ID: <20160620045430.GA47444@jodi.ci.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 05:09:12 -0000 Reproducible igb related panic 11.0-ALPHA4 OS: FreeBSD 11.0-ALPHA4 #6 r302022 Hardware: Asus P9D C224 (integrated , dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533 #2 0xffffffff8039ec79 in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:440 #3 0xffffffff8039e9d4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xffffffff803a19bb in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff80b3e3d3 in kdb_trap (type=, code=, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff8100fa95 in trap (frame=0xfffffe07c6777140) at /usr/src/sys/amd64/amd64/trap.c:556 #7 0xffffffff80ff2421 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #8 0xffffffff80b3da7b in kdb_enter (why=0xffffffff81533552 "panic", msg=0xffffffff81a960f8 " \035\027\201ÿÿÿÿ") at cpufunc.h:63 #9 0xffffffff80af52bf in vpanic (fmt=, ap=0xfffffe07c67772d0) at /usr/src/sys/kern/kern_shutdown.c:752 #10 0xffffffff80af5113 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:690 #11 0xffffffff80b8f78a in sbsndptr (sb=, off=, len=, moff=) at /usr/src/sys/kern/uipc_sockbuf.c:1196 #12 0xffffffff80d27fb5 in tcp_output (tp=) at /usr/src/sys/netinet/tcp_output.c:1045 #13 0xffffffff80d24f01 in tcp_do_segment (m=, th=, so=0xfffff800a3e3d9a8, tp=, drop_hdrlen=52, tlen=, iptos=, ti_locked=Cannot access memory at address 0x1 ) at /usr/src/sys/netinet/tcp_input.c:3161 #14 0xffffffff80d2152c in tcp_input (mp=, offp=, proto=) at /usr/src/sys/netinet/tcp_input.c:1442 #15 0xffffffff80c929cf in ip_input (m=Cannot access memory at address 0x0 ) at /usr/src/sys/netinet/ip_input.c:798 #16 0xffffffff80c24505 in netisr_dispatch_src (proto=1, source=, m=0x12) at /usr/src/sys/net/netisr.c:1121 #17 0xffffffff80c0bb0a in ether_demux (ifp=, m=0xffffffff81a960f8) at /usr/src/sys/net/if_ethersubr.c:850 #18 0xffffffff80c0c762 in ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:639 #19 0xffffffff80c24505 in netisr_dispatch_src (proto=5, source=, m=0x12) at /usr/src/sys/net/netisr.c:1121 #20 0xffffffff80c0bd86 in ether_input (ifp=, m=0x0) at /usr/src/sys/net/if_ethersubr.c:759 #21 0xffffffff80564d1c in igb_rxeof (count=-1543849472) at /usr/src/sys/dev/e1000/if_igb.c:4956 #22 0xffffffff80564072 in igb_msix_que (arg=0xfffff800096e50d0) at /usr/src/sys/dev/e1000/if_igb.c:1611 #23 0xffffffff80aadcff in intr_event_execute_handlers ( p=, ie=) at /usr/src/sys/kern/kern_intr.c:1262 #24 0xffffffff80aae316 in ithread_loop (arg=) at /usr/src/sys/kern/kern_intr.c:1275 #25 0xffffffff80aaa945 in fork_exit ( callout=0xffffffff80aae250 , arg=0xfffff80006e80040, frame=0xfffffe07c6777ac0) at /usr/src/sys/kern/kern_fork.c:1038 #26 0xffffffff80ff295e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #27 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) dmesg Copyright (c) 1992-2016 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-ALPHA3 #5 r301877: Tue Jun 14 15:48:23 AEST 2016 root@fmaster.ci.com.au:/u0/obj/usr/src/sys/LOCAL amd64 FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) can't re-use a leaf (ixl_rx_miss_bufs)! VT(vga): resolution 640x480 CPU: Intel(R) Xeon(R) CPU E3-1271 v3 @ 3.60GHz (3591.75-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3 Features=0xbfebfbff Features2=0x7ffafbff AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x2fbb XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33250164736 (31709 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-23 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff81076900, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 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 0x1808-0x180b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 xhci0: mem 0xdc300000-0xdc30ffff irq 16 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA xhci0: Port routing mask set to 0xffffffff usbus0 on xhci0 ehci0: mem 0xdc314000-0xdc3143ff irq 20 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 igb0: port 0xe000-0xe01f mem 0xdc200000-0xdc27ffff,0xdc280000-0xdc283fff irq 16 at device 0.0 on pci1 igb0: Using MSIX interrupts with 5 vectors igb0: Ethernet address: 14:dd:a9:4d:c7:b8 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb0: netmap queues/slots: TX 4/1024, RX 4/1024 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 igb1: port 0xd000-0xd01f mem 0xdc100000-0xdc17ffff,0xdc180000-0xdc183fff irq 17 at device 0.0 on pci2 igb1: Using MSIX interrupts with 5 vectors igb1: Ethernet address: 14:dd:a9:4d:c7:b9 igb1: Bound queue 0 to cpu 4 igb1: Bound queue 1 to cpu 5 igb1: Bound queue 2 to cpu 6 igb1: Bound queue 3 to cpu 7 igb1: netmap queues/slots: TX 4/1024, RX 4/1024 pcib3: irq 18 at device 28.2 on pci0 pci3: on pcib3 pcib4: irq 18 at device 0.0 on pci3 pci4: on pcib4 vgapci0: port 0xc000-0xc07f mem 0xd8000000-0xdbffffff,0xdc000000-0xdc01ffff irq 18 at device 0.0 on pci4 vgapci0: Boot video device pcib5: irq 19 at device 28.3 on pci0 pci5: on pcib5 pcib6: irq 19 at device 0.0 on pci5 pci6: on pcib6 ehci1: mem 0xdc313000-0xdc3133ff irq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xdc312000-0xdc3127ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ahciem0: on ahci0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 est4: on cpu4 est5: on cpu5 est6: on cpu6 est7: on cpu7 Timecounters tick every 1.000 msec nvme cam probe device init usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: <0x8086> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub2: on usbus2 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA8-ACS SATA 2.x device ada0: Serial Number 5VJ7J98V ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ACS-2 ATA SATA 3.x device ada1: Serial Number PHDA4084001E1207GN ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 114473MB (234441648 512 byte sectors) ada1: quirks=0x1<4K> ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 ses0: SEMB S-E-S 2.00 device uhub1: 2 ports with 2 removable, self powered ses0: SEMB SES Device SMP: AP CPU #1 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #5 Launched! Timecounter "TSC-low" frequency 1795876737 Hz quality 1000 Trying to mount root from ufs:/dev/gpt/ssdroot [rw]... uhub2: 2 ports with 2 removable, self powered WARNING: / was not properly dismounted sysctl: oid 'debug.ddb.capture.maxbufsize' is read only at line 13 Setting hostuuid: 709109c0-5bcb-11d9-8a6e-54a05085d521. Setting hostid: 0xcd1c5563. Starting ddb. eval: limits: not found /etc/rc: WARNING: failed to start ddb Starting file system checks: uhub0: 21 ports with 21 removable, self powered ugen1.2: at usbus1 uhub3: on usbus1 ugen2.2: at usbus2 uhub4: on usbus2 uhub3: 6 ports with 6 removable, self powered /dev/gpt/ssdroot: 157812 files, 310588 used, 197195 free (139 frags, 24632 blocks, 0.0% fragmentation) /dev/gpt/ssdvar: DEFER FOR BACKGROUND CHECKING /dev/gpt/ssdtmp: DEFER FOR BACKGROUND CHECKING /dev/gpt/ssdusr: DEFER FOR BACKGROUND CHECKING /dev/gpt/ssdhome: DEFER FOR BACKGROUND CHECKING /dev/gpt/ssdu0: DEFER FOR BACKGROUND CHECKING ugen0.2: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 From owner-freebsd-current@freebsd.org Mon Jun 20 06:50:12 2016 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 EC285A7B62B for ; Mon, 20 Jun 2016 06:50:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 AE6F31BCB for ; Mon, 20 Jun 2016 06:50:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27040 invoked from network); 20 Jun 2016 06:50:05 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 20 Jun 2016 06:50:05 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 20 Jun 2016 02:50:15 -0400 (EDT) Received: (qmail 27143 invoked from network); 20 Jun 2016 06:50:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Jun 2016 06:50:15 -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.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 383A0B1E001; Sun, 19 Jun 2016 23:50:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Compiling 11 on a Raspberry B+ 2 failes [not in my experience for -r301975] From: Mark Millard In-Reply-To: Date: Sun, 19 Jun 2016 23:50:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71F9C259-E75C-49F0-B7DC-4719E630BD88@dsl-only.net> References: To: erichsfreebsdlist@alogt.com, freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 06:50:13 -0000 On 2016-Jun-19, at 7:41 PM, Mark Millard wrote: > Quoting Erich Dollansky erichsfreebsdlist at alogt.com Sun Jun 19 = 23:38:56 UTC 2016 : >=20 >> I am trying to compile HEAD on a Raspberry and get always the = following >> error. >>=20 >> Of course, compiling revision 302017 on amd64 works. >>=20 >> Erich >>=20 >> Last Changed Rev: 301974 >>=20 >> /usr/src/lib/csu/arm/crt1.c:(.text+0xb4): relocation truncated to >> fit: R_ARM_CALL against symbol `atexit' defined in .text section >> in /usr/lib/libc.a(atexit.o) = /usr/src/lib/csu/arm/crt1.c:(.text+0xbc): >> relocation truncated to fit: R_ARM_CALL against symbol `_init_tls' >> defined in .text section >> in /usr/lib/libc.a(tls.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xcc): >> relocation truncated to fit: R_ARM_CALL against symbol `atexit' = defined >> in .text section >> in /usr/lib/libc.a(atexit.o) = /usr/src/lib/csu/arm/crt1.c:(.text+0x174): >> relocation truncated to fit: R_ARM_CALL against symbol `exit' defined >> in .text section in /usr/lib/libc.a(exit.o) /usr/lib/crt1.o: In >> function `finalizer': /usr/src/lib/csu/arm/crt1.c:(.text+0x1ec): >> relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini' >> defined in .fini section in /usr/lib/crti.o c++: error: linker = command >> failed with exit code 1 (use -v to see invocation) *** Error code 1 >>=20 >> Stop. >> bmake[4]: stopped in /usr/src.head/usr.bin/clang/clang >> *** Error code 1 >>=20 >> Stop. >> bmake[3]: stopped in /usr/src.head/usr.bin/clang >> *** Error code 1 >>=20 >> Stop. >> bmake[2]: stopped in /usr/src.head >> *** Error code 1 >>=20 >> Stop. >> bmake[1]: stopped in /usr/src.head >> *** Error code 1 >>=20 >> Stop. >> make: stopped in /usr/src.head >> [raspberry2]~/System (root) >=20 >=20 >=20 > I've done buildworld buildkernel for -r301975 on an rpi2 (not using = WITH_META_MODE=3Dyes) with no problem. The rpi2 was already running = -r301975 via a amd64 -> rpi2 cross build. >=20 > You do not mention what vintage of 11.0 your -r301974 build was = started from. A >=20 > uname -apKU >=20 > output would be appropriate to post as one way of indicating that. I went back and looked up my old notes from 2016-Jan-18 ( = https://lists.freebsd.org/pipermail/freebsd-arm/2016-January/013053.html = ) and it indicates that one must use 11.0 -r294031 or later to build = clang 3.8.0. The issue is clang 3.8.0 being bigger and needing -mlong-calls compiler = options in more places than the older clang 3.7.1 did. Quoting from the 2016-Jan-18 message. . . > The clang 3.8.0 investigation ran into this for building clang and = lldb. A quick scan of materials checked out from that branch (my = /usr/src is bound to that branch) shows the following as far as what 4 = Makefile* or 2 *.mk files list the option someplace: >=20 > > # find /usr/src/ -name .svn -prune -o -name 'Makefile*' -exec grep = mlong-calls {} \; -print > > STATIC_CXXFLAGS+=3D -mlong-calls > > /usr/src/lib/libc++/Makefile > > STATIC_CFLAGS+=3D -mlong-calls > > /usr/src/lib/csu/arm/Makefile > > CFLAGS+=3D -mlong-calls > > /usr/src/usr.bin/clang/lldb/Makefile > > CFLAGS+=3D -mlong-calls > > /usr/src/usr.bin/clang/clang/Makefile >=20 >=20 > > # find /usr/src/ -name .svn -prune -o -name '*.mk' -exec grep = mlong-calls {} \; -print > > STATIC_CXXFLAGS+=3D -mlong-calls > > /usr/src/lib/clang/clang.lib.mk > > CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls > > /usr/src/sys/conf/kmod.mk >=20 >=20 > (That last one is for mips instead of arm and has been around a long = time.) [Back to quoting the recent message. . .] > My WITH_META_MODE=3Dyes buidlworld buildkernel is still in process. The WITH_META_MODE=3Dyes build also completed fine. [WITH_META_MODE=3Dyes = is a recent addition to the build environment.] > Later below list my src.conf showing my slightly odd choices targeting = armv7-a/cortex-a7 explicitly. I'd be surprised if that makes a = difference for this issue. You have not provided your src.conf or = make.conf or other such context. >=20 > My -r301975 cross builds on amd64 targeting an rpi2 = [armv7-a/cortex-a7] have all worked fine (no matter if = WITH_META_MODE_yes was in use or not). >=20 > I've only used the system clang 3.8.0 to target armv6 in modern times. >=20 > My src.conf for rpi2 self hosted builds looks like: >=20 >> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host=20 >> TO_TYPE=3Darmv6 >> # >> KERNCONF=3DRPI2-NODBG >> TARGET=3Darm >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> #WITH_CROSS_COMPILER=3D >> WITH_SYSTEM_COMPILER=3D >> # >> #CPUTYPE=3Dsoft >> WITH_LIBSOFT=3D >> WITH_LIBCPLUSPLUS=3D >> WITH_BINUTILS_BOOTSTRAP=3D >> #WITHOUT_CLANG_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_CLANG_EXTRAS=3D >> WITH_LLDB=3D >> # >> WITH_BOOT=3D >> WITHOUT_LIB32=3D >> # >> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_GCC=3D >> WITHOUT_GCC_IS_CC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> #WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_DEBUG_FILES=3D >> # >> XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >> XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >> # There is no XCPPFLAGS but XCPP ets XCFLAGS content. >=20 > The ~/src.configs/make.conf is empty. >=20 > The amd64 -> rpi2 cross builds are only different for src.conf by: >=20 >> # diff ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host = ~/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host=20 >> 10,11c10,11 >> < #WITH_CROSS_COMPILER=3D >> < WITH_SYSTEM_COMPILER=3D >> --- >>> WITH_CROSS_COMPILER=3D >>> WITHOUT_SYSTEM_COMPILER=3D >> 17c17 >> < #WITHOUT_CLANG_BOOTSTRAP=3D >> --- >>> WITH_CLANG_BOOTSTRAP=3D >=20 >=20 > Showing the "on a rpi2" script that runs make for using = WITH_META_MODE=3Dyes : >=20 >> # more = ~/sys_build_scripts.rpi2-host/make_rpi2_nodebug_clang_bootstrap-rpi2-host.= sh=20 >> kldload -n filemon && \ >> script = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-rpi2-host-$= (date +%Y-%m-%d:%H:%M:%S) \ >> env __MAKE_CONF=3D"/root/src.configs/make.conf" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host"= \ >> WITH_META_MODE=3Dyes \ >> MAKEOBJDIRPREFIX=3D"/usr/obj/clang/arm.armv6" \ >> make $* >=20 > My /usr/src tree has some changes/additions --but mostly for powerpc64 = and powerpc issues: >=20 >> # svnlite status /usr/src/ >> M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >> M /usr/src/lib/csu/powerpc64/Makefile >> ? /usr/src/sys/amd64/include/include >> ? /usr/src/sys/arm/conf/RPI2-NODBG >> ? /usr/src/sys/arm/include/include >> M /usr/src/sys/boot/ofw/Makefile.inc >> M /usr/src/sys/boot/powerpc/Makefile >> M /usr/src/sys/boot/powerpc/Makefile.inc >> M /usr/src/sys/boot/uboot/Makefile.inc >> M /usr/src/sys/conf/Makefile.powerpc >> M /usr/src/sys/conf/kern.mk >> M /usr/src/sys/conf/kmod.mk >> M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c >> M /usr/src/sys/dev/cxgbe/tom/t4_listen.c >> ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >> ? /usr/src/sys/powerpc/include/include >> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >> M /usr/src/sys/powerpc/powerpc/exec_machdep.c >> ? /usr/src/sys/x86/include/include >=20 > (The include/include ones are from something making links pointing = back up to the parent include/ . I did not explicitly create these.) >=20 > (The cxbg and cxbge ones were from trying to have amd64 target amd64 = via xtoolchain (devel/amd64-gcc). But other places also stopped it and I = quit trying that for now.) >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Jun 20 07:39:24 2016 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 1834EA7A93D for ; Mon, 20 Jun 2016 07:39:24 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 03E68174E for ; Mon, 20 Jun 2016 07:39:24 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 00045A7A93B; Mon, 20 Jun 2016 07:39:24 +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 F3A80A7A93A; Mon, 20 Jun 2016 07:39:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E0BC0174C; Mon, 20 Jun 2016 07:39:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id u5K7dHNO093644 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jun 2016 00:39:17 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id u5K7dHwj093643; Mon, 20 Jun 2016 00:39:17 -0700 (PDT) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 20 Jun 2016 00:39:17 -0700 From: Gleb Smirnoff To: rrs@FreeBSD.org Cc: Julien Charbon , hselasky@FreeBSD.org, rrs@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org Subject: Re: panic with tcp timers Message-ID: <20160620073917.GI1076@FreeBSD.org> References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 07:39:24 -0000 Hi! On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: J> > Comparing stable/10 and head, I see two changes that could J> > affect that: J> > J> > - callout_async_drain J> > - switch to READ lock for inp info in tcp timers J> > J> > That's why you are in To, Julien and Hans :) J> > J> > We continue investigating, and I will keep you updated. J> > However, any help is welcome. I can share cores. Now, spending some time with cores and adding a bunch of extra CTRs, I have a sequence of events that lead to the panic. In short, the bug is in the callout system. It seems to be not relevant to the callout_async_drain, at least for now. The transition to READ lock unmasked the problem, that's why NetflixBSD 10 doesn't panic. The panic requires heavy contention on the TCP info lock. [CPU 1] the callout fires, tcp_timer_keep entered [CPU 1] blocks on INP_INFO_RLOCK(&V_tcbinfo); [CPU 2] schedules the callout [CPU 2] tcp_discardcb called [CPU 2] callout successfully canceled [CPU 2] tcpcb freed [CPU 1] unblocks... panic When the lock was WLOCK, all contenders were resumed in a sequence they came to the lock. Now, that they are readers, once the lock is released, readers are resumed in a "random" order, and this allows tcp_discardcb to go before the old running callout, and this unmasks the panic. Exact quote from ktrdump: 0xfffff82089867418 <-- faulty tcpcb 0xfffff82089867728 <-- its tt_keep glebius@piston:~/cores:|>grep 0xfffff82089867418 ktr 19012192 11 scheduled 0xfffff820898677a8 func 0xffffffff80628740 arg 0xfffff82089867418 in 20553.1e3ff819 19012190 11 rescheduled 0xfffff82089867728 func 0xffffffff80628bb0 arg 0xfffff82089867418 in 20613.04a6193d 19009551 11 rescheduled 0xfffff82089867728 func 0xffffffff80628bb0 arg 0xfffff82089867418 in 20613.042306cf 19009549 11 scheduled 0xfffff82089867728 func 0xffffffff80628bb0 arg 0xfffff82089867418 in 20563.0423409f 19009545 11 tcp_newtcpcb: 0xfffff82089867418 18962842 11 tcp_discardcb: free 0xfffff82089867418 18962830 11 tcp_discardcb: 0xfffff82089867418 draincnt 0 18962826 11 failed to stop 0xfffff820898677a8 func 0xffffffff80628740 arg 0xfffff82089867418 18962822 11 cancelled3 0xfffff82089867768 func 0xffffffff806288e0 arg 0xfffff82089867418 18962808 11 cancelled3 0xfffff82089867728 func 0xffffffff80628bb0 arg 0xfffff82089867418 18962804 11 failed to stop 0xfffff820898676e8 func 0xffffffff80628fa0 arg 0xfffff82089867418 18962792 11 failed to stop 0xfffff820898676a8 func 0xffffffff806291e0 arg 0xfffff82089867418 18962755 11 tcp_discardcb: 0xfffff82089867418 18962742 11 scheduled 0xfffff82089867768 func 0xffffffff806288e0 arg 0xfffff82089867418 in 20632.ffc8d308 18962703 11 cancelled3 0xfffff820898676a8 func 0xffffffff806291e0 arg 0xfffff82089867418 18962695 11 scheduled 0xfffff82089867728 func 0xffffffff80628bb0 arg 0xfffff82089867418 in 20612.ffc8ea28 18923275 6 tcp_timer_keep: 0xfffff82089867418 18923274 6 callout 0xfffff82089867728 func 0xffffffff80628bb0 arg 0xfffff82089867418 17850361 9 scheduled 0xfffff820898676a8 func 0xffffffff806291e0 arg 0xfffff82089867418 in 20553.5aec0004 -- Totus tuus, Glebius. From owner-freebsd-current@freebsd.org Mon Jun 20 08:15:32 2016 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 94A50A7B6C9 for ; Mon, 20 Jun 2016 08:15:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 3D3C72B7A for ; Mon, 20 Jun 2016 08:15:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1413 invoked from network); 20 Jun 2016 08:15:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 Jun 2016 08:15:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 20 Jun 2016 04:15:26 -0400 (EDT) Received: (qmail 32751 invoked from network); 20 Jun 2016 08:15:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Jun 2016 08:15:25 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id E2A1CB1E001; Mon, 20 Jun 2016 01:15:27 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: FYI: how long for a "nothing new" 11.0 -r301975 WITH_META_MODE=yes build on an rpi2? Message-Id: Date: Mon, 20 Jun 2016 01:15:27 -0700 To: freebsd-arm , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 08:15:32 -0000 [One oddity of the rpi2 context for the below is that the root file = system is on a fast USB SSD drive: it is really a fast USB 3.0 SSD drive = just used on the USB 2 bus via a USB 3.0 capable hub.] I just did the following sort of sequence on an rpi2 for 11.0 -r301975 = rebuilding itself where the .sh script used indicates to use = WITH_META_MODE=3Dyes for the make command : > # = ~/sys_build_scripts.rpi2-host/make_rpi2_nodebug_clang_bootstrap-rpi2-host.= sh -j 5 buildworld buildkernel > # = ~/sys_build_scripts.rpi2-host/make_rpi2_nodebug_clang_bootstrap-rpi2-host.= sh -j 5 buildworld buildkernel (Also the .sh runs script to log all the make output. The first build = was actually more involved than shown above, see later notes.) The 2nd one took about 15 or 16 minutes to go through everything and, in = essence, discover that nothing needed to be rebuilt. This was (still) = using WITH_LIBSOFT=3D in the src.conf file. Also: WITH_CLANG_FULL=3D = WITH_CLANG_EXTRAS=3D WITH_LLDB=3D were in use. . . > # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host=20 > TO_TYPE=3Darmv6 > # > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > #WITH_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > # > #CPUTYPE=3Dsoft > WITH_LIBSOFT=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > #WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > # There is no XCPPFLAGS but XCPP ets XCFLAGS content. ~/src.configs/make.conf was empty. Other notes: I've not had any problems with WITH_META_MODE=3Dyes use for the self = hosting 11.0 -r301975 rpi2 builds. Going from not using WITH_META_MODE=3Dyes to using WITH_META_MODE=3Dyes = in the self-hosting context did not require a cleanworld between the = builds. (Cross build transitions in that direction do require such = still.) I do not report the WITH_META_MODE=3Dyes build time for the first time = because I actually did more. I: A) forced a root file system I/O failure/panic (during what happened to be libxo building) B) then started WITH_META_MODE=3Dyes again (after booting) C) let it run until the incomplete file(s) from the failure caused it to = stop D) did a make clean for libxo E) then started WITH_META_MODE=3Dyes yet again F) let it run to completion The WITH_META_MODE=3Dyes use appears to have worked just fine despite = the abusive nature of the test. I will report that not using WITH_META_MODE=3Dyes took between 15 hr and = 16 hr (no such odd testing sequence involved). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon Jun 20 09:31:40 2016 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 2D155A7ADB6 for ; Mon, 20 Jun 2016 09:31:40 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (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 EA7C51527 for ; Mon, 20 Jun 2016 09:31:39 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from mfilter25-d.gandi.net (mfilter25-d.gandi.net [217.70.178.153]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id F02C9C5A89; Mon, 20 Jun 2016 11:31:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter25-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter25-d.gandi.net (mfilter25-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id B6hTHkF2JXAi; Mon, 20 Jun 2016 11:31:35 +0200 (CEST) X-Originating-IP: 90.231.139.91 Received: from [192.168.1.249] (h91n1-gl-a-a31.ias.bredband.telia.com [90.231.139.91]) (Authenticated sender: daniel.engberg@pyret.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 8BCD0C5A75; Mon, 20 Jun 2016 11:31:35 +0200 (CEST) Subject: Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4 To: Konstantin Belousov References: <0092113e-6ad6-575c-2127-f211ba9aef50@pyret.net> <20160619080644.GL38613@kib.kiev.ua> <20160619091718.GM38613@kib.kiev.ua> Cc: freebsd-current@freebsd.org From: Daniel Engberg Message-ID: Date: Mon, 20 Jun 2016 11:30:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160619091718.GM38613@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 09:31:40 -0000 On 2016-06-19 11:17, Konstantin Belousov wrote: > On Sun, Jun 19, 2016 at 11:09:02AM +0200, Daniel Engberg wrote: >> I have the following in /etc/src.conf >> >> MALLOC_PRODUCTION=yes >> WITHOUT_DEBUG_FILES=1 > > Most important is to remove WITHOUT_DEBUG_FILES and recompile the world. > Hi, My laptop is showing it's age (compiling takes ages), anyhow.... Apparently the ALPHA4 snapshot doesn't contain userland debugging so I'm currently rebuilding which probably will be done tonight. If you want to try it out yourself building Samba 4.4 and running "pdbedit -a -u " also produces a similar crash (no config needed). Best regards, Daniel From owner-freebsd-current@freebsd.org Mon Jun 20 09:56:04 2016 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 326F2A79807 for ; Mon, 20 Jun 2016 09:56:04 +0000 (UTC) (envelope-from julien.charbon@gmail.com) 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 0F39A2105 for ; Mon, 20 Jun 2016 09:56:04 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0E87DA79802; Mon, 20 Jun 2016 09:56:04 +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 0E116A79801; Mon, 20 Jun 2016 09:56:04 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (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 BB2CB2103; Mon, 20 Jun 2016 09:56:03 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: by mail-wm0-f46.google.com with SMTP id v199so61892368wmv.0; Mon, 20 Jun 2016 02:56:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=3R5oeRHX8RbACHoEqf+3o/gYI4UZCkA1gYS8cFHCR0U=; b=LXRMPc35nnTc0GuPTcUFQMNJ2krtP9JxPg10Cjiwamq3K2zJw+1MkAljA1by0CCe4q 3BLTqVgWgzWnnymvzSwquz5M4IU+ndEz6VIj5Uf8618tBH6HNaVYGydJmuv5rTA00JNX /NSmO3K+l7PNNuj1v83hmOL+9svhbP+m+nXZl0a+WwJTpSiheOTfIXHP+1pyDSCw5kvh w30MuD6KuQzHySvdNcb3Thx9xYNESCKyEc+C3pbFMKnTpqwZEkkwa/FV2joFTW/NgchC mfFJO4Av6X6Yme4AWVsfVzSoQBfqpUVMOhGxp4woj6MnbKRDzuNlssKCO6IVqiKSwPyT yCwg== X-Gm-Message-State: ALyK8tLIprB7amIg+uwvZQvTA651fVSjcnlnHTURSPg+nn+7UWCABlaG2gwm5EPuou6RvQ== X-Received: by 10.194.81.72 with SMTP id y8mr14670954wjx.83.1466416561397; Mon, 20 Jun 2016 02:56:01 -0700 (PDT) Received: from [10.100.64.16] ([217.30.88.7]) by smtp.gmail.com with ESMTPSA id e5sm62749343wjj.10.2016.06.20.02.56.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 02:56:00 -0700 (PDT) Subject: Re: panic with tcp timers To: Gleb Smirnoff , rrs@FreeBSD.org References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> Cc: hselasky@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org From: Julien Charbon Message-ID: <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> Date: Mon, 20 Jun 2016 11:55:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160620073917.GI1076@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WRcuaKjPkOnTUAdRFNif3MWmTfBRkeXRe" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 09:56:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WRcuaKjPkOnTUAdRFNif3MWmTfBRkeXRe Content-Type: multipart/mixed; boundary="oQsT0aQmt8QcIiFDCxI7qFMBav9RqDwaE" From: Julien Charbon To: Gleb Smirnoff , rrs@FreeBSD.org Cc: hselasky@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org Message-ID: <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> Subject: Re: panic with tcp timers References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> In-Reply-To: <20160620073917.GI1076@FreeBSD.org> --oQsT0aQmt8QcIiFDCxI7qFMBav9RqDwaE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On 6/20/16 9:39 AM, Gleb Smirnoff wrote: > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: > J> > Comparing stable/10 and head, I see two changes that could > J> > affect that: > J> >=20 > J> > - callout_async_drain > J> > - switch to READ lock for inp info in tcp timers > J> >=20 > J> > That's why you are in To, Julien and Hans :) > J> >=20 > J> > We continue investigating, and I will keep you updated. > J> > However, any help is welcome. I can share cores. >=20 > Now, spending some time with cores and adding a bunch of > extra CTRs, I have a sequence of events that lead to the > panic. In short, the bug is in the callout system. It seems > to be not relevant to the callout_async_drain, at least for > now. The transition to READ lock unmasked the problem, that's > why NetflixBSD 10 doesn't panic. >=20 > The panic requires heavy contention on the TCP info lock. >=20 > [CPU 1] the callout fires, tcp_timer_keep entered > [CPU 1] blocks on INP_INFO_RLOCK(&V_tcbinfo); > [CPU 2] schedules the callout > [CPU 2] tcp_discardcb called > [CPU 2] callout successfully canceled > [CPU 2] tcpcb freed > [CPU 1] unblocks... panic >=20 > When the lock was WLOCK, all contenders were resumed in a > sequence they came to the lock. Now, that they are readers, > once the lock is released, readers are resumed in a "random" > order, and this allows tcp_discardcb to go before the old > running callout, and this unmasks the panic. Highly interesting. I should be able to reproduce that (will be useful for testing the corresponding fix). Fix proposal: If callout_async_drain() returns 0 (fail) (instead of 1 (success) here) when the callout cancellation is a success _but_ the callout is current running, that should fix it. For the history: It comes back to my old callout question: Does _callout_stop_safe() is allowed to return 1 (success) even if the callout is still currently running; a.k.a. it is not because you successfully cancelled a callout that the callout is not currently runnin= g. We did propose a patch to make _callout_stop_safe() returns 0 (fail) when the callout is currently running: callout_stop() should return 0 when the callout is currently being serviced and indeed unstoppable https://reviews.freebsd.org/differential/changeset/?ref=3D62513&whitespac= e=3Dignore-most But this change impacted too many old code paths and was interesting only for TCP timers and thus was abandoned. My 2 cents. -- Julien --oQsT0aQmt8QcIiFDCxI7qFMBav9RqDwaE-- --WRcuaKjPkOnTUAdRFNif3MWmTfBRkeXRe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXZ72vAAoJEKVlQ5Je6dhxZ3sH/2eFfPP334XgUPWLnMPJ1CeQ gGAz8hshDh9Rmrt7tR+XoG0q8fRanTLP75cOODIYiU51bFYys+0NymLTrsDtjUbF fqRp4cjRznhMEoTiUoCLCIfeIJaer3X5FQDyf1md2Mn+CbtiWswXGr0kH1mnCBwq FBLPwCLF2MEZrXdZImhWCCF+i9KJYXL7gOsu/gCg/5x+JnOK5/Rq4SY6SXvqkBYB p9NKU4E4brZYXatLG4EGaHM4nG16gtw6ZrXmJKfiYMm2en9otRwhbfHfC7xpJG2n ONIMU32WJ095xcOFs+ywUkJ8DFWa0+01AoTy/+OHmIqacrJYMb2hy7mh7O7ylSs= =W+6o -----END PGP SIGNATURE----- --WRcuaKjPkOnTUAdRFNif3MWmTfBRkeXRe-- From owner-freebsd-current@freebsd.org Mon Jun 20 09:58:24 2016 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 9F861A799FF for ; Mon, 20 Jun 2016 09:58:24 +0000 (UTC) (envelope-from glebius@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 8A3CD23F7 for ; Mon, 20 Jun 2016 09:58:24 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 857CCA799FB; Mon, 20 Jun 2016 09:58:24 +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 850C9A799FA; Mon, 20 Jun 2016 09:58:24 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BB90A23F5; Mon, 20 Jun 2016 09:58:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id u5K9wM5B094519 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jun 2016 02:58:22 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id u5K9wM4P094518; Mon, 20 Jun 2016 02:58:22 -0700 (PDT) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 20 Jun 2016 02:58:22 -0700 From: Gleb Smirnoff To: Julien Charbon Cc: rrs@FreeBSD.org, hselasky@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org Subject: Re: panic with tcp timers Message-ID: <20160620095822.GJ1076@FreeBSD.org> References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 09:58:24 -0000 On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote: J> > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: J> > J> > Comparing stable/10 and head, I see two changes that could J> > J> > affect that: J> > J> > J> > J> > - callout_async_drain J> > J> > - switch to READ lock for inp info in tcp timers J> > J> > J> > J> > That's why you are in To, Julien and Hans :) J> > J> > J> > J> > We continue investigating, and I will keep you updated. J> > J> > However, any help is welcome. I can share cores. J> > J> > Now, spending some time with cores and adding a bunch of J> > extra CTRs, I have a sequence of events that lead to the J> > panic. In short, the bug is in the callout system. It seems J> > to be not relevant to the callout_async_drain, at least for J> > now. The transition to READ lock unmasked the problem, that's J> > why NetflixBSD 10 doesn't panic. J> > J> > The panic requires heavy contention on the TCP info lock. J> > J> > [CPU 1] the callout fires, tcp_timer_keep entered J> > [CPU 1] blocks on INP_INFO_RLOCK(&V_tcbinfo); J> > [CPU 2] schedules the callout J> > [CPU 2] tcp_discardcb called J> > [CPU 2] callout successfully canceled J> > [CPU 2] tcpcb freed J> > [CPU 1] unblocks... panic J> > J> > When the lock was WLOCK, all contenders were resumed in a J> > sequence they came to the lock. Now, that they are readers, J> > once the lock is released, readers are resumed in a "random" J> > order, and this allows tcp_discardcb to go before the old J> > running callout, and this unmasks the panic. J> J> Highly interesting. I should be able to reproduce that (will be useful J> for testing the corresponding fix). J> J> Fix proposal: If callout_async_drain() returns 0 (fail) (instead of 1 J> (success) here) when the callout cancellation is a success _but_ the J> callout is current running, that should fix it. J> J> For the history: It comes back to my old callout question: J> J> Does _callout_stop_safe() is allowed to return 1 (success) even if the J> callout is still currently running; a.k.a. it is not because you J> successfully cancelled a callout that the callout is not currently running. J> J> We did propose a patch to make _callout_stop_safe() returns 0 (fail) J> when the callout is currently running: J> J> callout_stop() should return 0 when the callout is currently being J> serviced and indeed unstoppable J> https://reviews.freebsd.org/differential/changeset/?ref=62513&whitespace=ignore-most J> J> But this change impacted too many old code paths and was interesting J> only for TCP timers and thus was abandoned. The fix I am working on now is doing exactly that. callout_reset must return 0 if the callout is currently running. What are the old paths impacted? -- Totus tuus, Glebius. From owner-freebsd-current@freebsd.org Mon Jun 20 10:01:14 2016 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 3157FA79C71 for ; Mon, 20 Jun 2016 10:01:14 +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 A503E2674 for ; Mon, 20 Jun 2016 10:01:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5KA14Fe036065 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 Jun 2016 13:01:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5KA14Fe036065 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5KA11R9035695; Mon, 20 Jun 2016 13:01:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 20 Jun 2016 13:01:01 +0300 From: Konstantin Belousov To: Daniel Engberg Cc: freebsd-current@freebsd.org Subject: Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4 Message-ID: <20160620100101.GU38613@kib.kiev.ua> References: <0092113e-6ad6-575c-2127-f211ba9aef50@pyret.net> <20160619080644.GL38613@kib.kiev.ua> <20160619091718.GM38613@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 20 Jun 2016 10:01:14 -0000 On Mon, Jun 20, 2016 at 11:30:38AM +0200, Daniel Engberg wrote: > On 2016-06-19 11:17, Konstantin Belousov wrote: > > On Sun, Jun 19, 2016 at 11:09:02AM +0200, Daniel Engberg wrote: > >> I have the following in /etc/src.conf > >> > >> MALLOC_PRODUCTION=yes > >> WITHOUT_DEBUG_FILES=1 > > > > Most important is to remove WITHOUT_DEBUG_FILES and recompile the world. > > > > Hi, > > My laptop is showing it's age (compiling takes ages), anyhow.... Apparently the ALPHA4 snapshot doesn't contain userland debugging so I'm currently rebuilding > which probably will be done tonight. If you want to try it out yourself building Samba 4.4 and running "pdbedit -a -u " also produces a similar > crash (no config needed). It is enough to rebuild libthr/libc/libthr. cd /usr/src (cd lib/libc && make all install clean DEBUG_FLAGS=-g) (cd lib/libthr && make all install clean DEBUG_FLAGS=-g) (cd libexec/rtld-elf && make all install clean DEBUG_FLAGS=-g) From owner-freebsd-current@freebsd.org Mon Jun 20 10:10:44 2016 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 C2D0EA7B124 for ; Mon, 20 Jun 2016 10:10:44 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id AFBB12CD3 for ; Mon, 20 Jun 2016 10:10:44 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.ysv.freebsd.org (Postfix) id AB865A7B122; Mon, 20 Jun 2016 10:10:44 +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 AB08CA7B11F; Mon, 20 Jun 2016 10:10:44 +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 72C332CD1; Mon, 20 Jun 2016 10:10:43 +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 0FCB81FE023; Mon, 20 Jun 2016 12:10:40 +0200 (CEST) Subject: Re: panic with tcp timers To: Gleb Smirnoff , Julien Charbon References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> <20160620095822.GJ1076@FreeBSD.org> Cc: rrs@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org From: Hans Petter Selasky Message-ID: Date: Mon, 20 Jun 2016 12:14:18 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160620095822.GJ1076@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.22 Precedence: 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, 20 Jun 2016 10:10:44 -0000 On 06/20/16 11:58, Gleb Smirnoff wrote: > The fix I am working on now is doing exactly that. callout_reset must > return 0 if the callout is currently running. > > What are the old paths impacted? Hi, I'll dig into the matter aswell and give some comments. Thanks for the analysis, Gleb. FYI: This class of problems wouldn't exist if the callout could be associated with a mutex! --HPS From owner-freebsd-current@freebsd.org Mon Jun 20 10:30:18 2016 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 138C0A7B536 for ; Mon, 20 Jun 2016 10:30:18 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F1EDE1842 for ; Mon, 20 Jun 2016 10:30:17 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id ED03AA7B534; Mon, 20 Jun 2016 10:30:17 +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 EC966A7B533; Mon, 20 Jun 2016 10:30:17 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A8701840; Mon, 20 Jun 2016 10:30:17 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id u5KAUF67094805 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jun 2016 03:30:15 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id u5KAUFOX094804; Mon, 20 Jun 2016 03:30:15 -0700 (PDT) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 20 Jun 2016 03:30:15 -0700 From: Gleb Smirnoff To: Hans Petter Selasky Cc: Julien Charbon , rrs@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org Subject: Re: panic with tcp timers Message-ID: <20160620103015.GK1076@FreeBSD.org> References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> <20160620095822.GJ1076@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 10:30:18 -0000 On Mon, Jun 20, 2016 at 12:14:18PM +0200, Hans Petter Selasky wrote: H> On 06/20/16 11:58, Gleb Smirnoff wrote: H> > The fix I am working on now is doing exactly that. callout_reset must H> > return 0 if the callout is currently running. H> > H> > What are the old paths impacted? H> H> Hi, H> H> I'll dig into the matter aswell and give some comments. Thanks for the H> analysis, Gleb. H> H> FYI: This class of problems wouldn't exist if the callout could be H> associated with a mutex! Exactly! I am convinced that all callouts should be locked, and non-locked one should simply go away, as well as async drain. What does prevent us from converting TCP timeouts to locked? To my understanding it is the lock order of taking pcbinfo after pcb lock. I'm now trying to understand Julien's conversion from pcbinfo lock to pcbinfo + pcblist locks. It seems to me that we actually can convert TCP timers to locked callouts. What for do we need pcbinfo read lock in a tcp timer? The timer works only on the pcb and doesn't modify global lists, does it? -- Totus tuus, Glebius. From owner-freebsd-current@freebsd.org Mon Jun 20 10:45:43 2016 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 7F346A7B7E0 for ; Mon, 20 Jun 2016 10:45:43 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6A51FA3 for ; Mon, 20 Jun 2016 10:45:43 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.ysv.freebsd.org (Postfix) id 664B3A7B7DE; Mon, 20 Jun 2016 10:45:43 +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 65E4CA7B7DD; Mon, 20 Jun 2016 10:45:43 +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 295551F9D; Mon, 20 Jun 2016 10:45:42 +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 4FC1F1FE023; Mon, 20 Jun 2016 12:45:40 +0200 (CEST) Subject: Re: panic with tcp timers To: Gleb Smirnoff , Julien Charbon References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> <20160620095822.GJ1076@FreeBSD.org> Cc: rrs@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org From: Hans Petter Selasky Message-ID: <4b5d36b0-a20a-8a1b-b346-8761fbc2e9cf@selasky.org> Date: Mon, 20 Jun 2016 12:49:17 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160620095822.GJ1076@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.22 Precedence: 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, 20 Jun 2016 10:45:43 -0000 On 06/20/16 11:58, Gleb Smirnoff wrote: > J> callout_stop() should return 0 when the callout is currently being > J> serviced and indeed unstoppable > J> https://reviews.freebsd.org/differential/changeset/?ref=62513&whitespace=ignore-most > > What are the old paths impacted? > Hi Gleb, Digging through my e-mail archive rephrasing myself and comments about: https://reviews.freebsd.org/D3078 There are two kinds of callouts. So-called MPSAFE callouts which doesn't have a mutex associated with it, and non-MPSAFE which do. When you are associating a mutex with a callout, callout_stop() will _always_ cancel the callback even if it is pending, and this should be reflected by the return value. Your proposed changes will break that ??? The changes in D3078 didn't take into account "use_lock" at least, and so the return values for the non-MPSAFE case becomes incorrect. > Hi, > > I think this patch is incomplete and can break the return value for non-MPSAFE callouts. I think the correct statement should check the value of "use_lock" too: > > not_running = !(cc_exec_curr(cc, direct) == c && use_lock == 0); > > Because if the callback process waits for lock "c_lock" in the callback process then we have above "cc_exec_curr(cc, direct) == c" is satisfied too, and non-MPSAFE callouts are always cancelable, via cc_exec_cancel(cc, direct) = true; --HPS From owner-freebsd-current@freebsd.org Mon Jun 20 10:48:25 2016 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 27EC1A7B8E6 for ; Mon, 20 Jun 2016 10:48:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 0FE8821E3 for ; Mon, 20 Jun 2016 10:48:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 08097A7B8E4; Mon, 20 Jun 2016 10:48: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 07679A7B8E2; Mon, 20 Jun 2016 10:48:25 +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 A479921DF; Mon, 20 Jun 2016 10:48:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5KAmJon046864 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 Jun 2016 13:48:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5KAmJon046864 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5KAmJjv046863; Mon, 20 Jun 2016 13:48:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 20 Jun 2016 13:48:19 +0300 From: Konstantin Belousov To: Julien Charbon Cc: Gleb Smirnoff , rrs@FreeBSD.org, current@FreeBSD.org, hselasky@FreeBSD.org, net@FreeBSD.org Subject: Re: panic with tcp timers Message-ID: <20160620104819.GV38613@kib.kiev.ua> References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 20 Jun 2016 10:48:25 -0000 On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote: > > Hi, > > On 6/20/16 9:39 AM, Gleb Smirnoff wrote: > > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: > > J> > Comparing stable/10 and head, I see two changes that could > > J> > affect that: > > J> > > > J> > - callout_async_drain > > J> > - switch to READ lock for inp info in tcp timers > > J> > > > J> > That's why you are in To, Julien and Hans :) > > J> > > > J> > We continue investigating, and I will keep you updated. > > J> > However, any help is welcome. I can share cores. > > > > Now, spending some time with cores and adding a bunch of > > extra CTRs, I have a sequence of events that lead to the > > panic. In short, the bug is in the callout system. It seems > > to be not relevant to the callout_async_drain, at least for > > now. The transition to READ lock unmasked the problem, that's > > why NetflixBSD 10 doesn't panic. > > > > The panic requires heavy contention on the TCP info lock. > > > > [CPU 1] the callout fires, tcp_timer_keep entered > > [CPU 1] blocks on INP_INFO_RLOCK(&V_tcbinfo); > > [CPU 2] schedules the callout > > [CPU 2] tcp_discardcb called > > [CPU 2] callout successfully canceled > > [CPU 2] tcpcb freed > > [CPU 1] unblocks... panic > > > > When the lock was WLOCK, all contenders were resumed in a > > sequence they came to the lock. Now, that they are readers, > > once the lock is released, readers are resumed in a "random" > > order, and this allows tcp_discardcb to go before the old > > running callout, and this unmasks the panic. > > Highly interesting. I should be able to reproduce that (will be useful > for testing the corresponding fix). > > Fix proposal: If callout_async_drain() returns 0 (fail) (instead of 1 > (success) here) when the callout cancellation is a success _but_ the > callout is current running, that should fix it. > > For the history: It comes back to my old callout question: > > Does _callout_stop_safe() is allowed to return 1 (success) even if the > callout is still currently running; a.k.a. it is not because you > successfully cancelled a callout that the callout is not currently running. > > We did propose a patch to make _callout_stop_safe() returns 0 (fail) > when the callout is currently running: > > callout_stop() should return 0 when the callout is currently being > serviced and indeed unstoppable > https://reviews.freebsd.org/differential/changeset/?ref=62513&whitespace=ignore-most > > But this change impacted too many old code paths and was interesting > only for TCP timers and thus was abandoned. Look at callout_stop CS_MIGRBLOCK flag and the fix in sleepq_check_timeout(). Or, at least, do not allow this use of callout_stop() to rot again, after previous dozen regressions and fixes there. From owner-freebsd-current@freebsd.org Mon Jun 20 10:54:00 2016 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 A55E2A7BB33 for ; Mon, 20 Jun 2016 10:54:00 +0000 (UTC) (envelope-from hps@selasky.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 90F3827DF for ; Mon, 20 Jun 2016 10:54:00 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8CF24A7BB31; Mon, 20 Jun 2016 10:54:00 +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 8A4EBA7BB30; Mon, 20 Jun 2016 10:54:00 +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 4714927DB; Mon, 20 Jun 2016 10:53:59 +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 B98351FE023; Mon, 20 Jun 2016 12:53:57 +0200 (CEST) Subject: Re: panic with tcp timers To: Gleb Smirnoff References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> <20160620095822.GJ1076@FreeBSD.org> <20160620103015.GK1076@FreeBSD.org> Cc: Julien Charbon , rrs@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org From: Hans Petter Selasky Message-ID: Date: Mon, 20 Jun 2016 12:57:35 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160620103015.GK1076@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.22 Precedence: 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, 20 Jun 2016 10:54:00 -0000 On 06/20/16 12:30, Gleb Smirnoff wrote: > Exactly! I am convinced that all callouts should be locked, and non-locked > one should simply go away, as well as async drain. I agree about that that, except you still need the async drain, because it will prevent freeing the lock protecting the callout, which may still be in use after callout_stop(). --HPS From owner-freebsd-current@freebsd.org Mon Jun 20 10:56:42 2016 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 6B8A1A7BC44 for ; Mon, 20 Jun 2016 10:56:42 +0000 (UTC) (envelope-from hps@selasky.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 5761F2AF2 for ; Mon, 20 Jun 2016 10:56:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.ysv.freebsd.org (Postfix) id 502F8A7BC42; Mon, 20 Jun 2016 10:56:42 +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 4FA21A7BC40; Mon, 20 Jun 2016 10:56:42 +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 16E992AF0; Mon, 20 Jun 2016 10:56:41 +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 9270C1FE023; Mon, 20 Jun 2016 12:56:39 +0200 (CEST) Subject: Re: panic with tcp timers To: Gleb Smirnoff References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> <20160620095822.GJ1076@FreeBSD.org> <20160620103015.GK1076@FreeBSD.org> Cc: Julien Charbon , rrs@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org From: Hans Petter Selasky Message-ID: Date: Mon, 20 Jun 2016 13:00:16 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160620103015.GK1076@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.22 Precedence: 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, 20 Jun 2016 10:56:42 -0000 On 06/20/16 12:30, Gleb Smirnoff wrote: > What does prevent us from converting TCP timeouts to locked? To my > understanding it is the lock order of taking pcbinfo after pcb lock. I started this work: https://reviews.freebsd.org/D1563 --HPS From owner-freebsd-current@freebsd.org Mon Jun 20 11:16:09 2016 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 9B7C7A7B419 for ; Mon, 20 Jun 2016 11:16:09 +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 CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5267C1A38 for ; Mon, 20 Jun 2016 11:16:08 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-242-176.lns20.per4.internode.on.net [121.45.242.176]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u5KBG1xw087710 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 20 Jun 2016 04:16:05 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Virtualbox kernel module on 11-CURRENT To: Kevin Oberman , Guido Falsi References: Cc: Rafael Rodrigues Nakano , FreeBSD Current From: Julian Elischer Message-ID: <0fdc268e-ab76-c589-f11f-69852ac7d57f@freebsd.org> Date: Mon, 20 Jun 2016 19:15:56 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 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.22 Precedence: 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, 20 Jun 2016 11:16:09 -0000 On 8/06/2016 5:13 AM, Kevin Oberman wrote: > On Tue, Jun 7, 2016 at 1:04 AM, Guido Falsi wrote: > >> On 06/07/16 02:23, Rafael Rodrigues Nakano wrote: >>> Hello, >>> >>> I tried installing virtualbox from packages, building it from sources, >>> trying the GENERIC kernel but everytime I can't start the kernel module >>> 'vboxdrv', it says: >>> "KLD vboxdrv.ko: depends on kernel - not available or version mismatch. >>> linker_load_file: Unsupported file type" >>> >> The virtualbox module needs to be in full sync with the kernel. Most >> probably the sources being used by the cluster for building packages on >> head are a little different from yours, so the kernel module is not in >> sync. >> >> You will need to build the kernel module yourself to actually match your >> kernel sources. >> >> It's not really a problem or a bug, it's how it works. On head there is >> no warranty about the KBI. This cannot happen on releases and stable >> because the KBI is not going to change there. >> >> -- >> Guido Falsi >> > I don't think this is true. While shareable libraries have fixed ABIs, I > believe the KBI can change even in STABLE branches. If a security fix > requires it, it might even change in a RELEASE. I my be wrong about this, > but I recall having to re-build the VB kmod port even withing a minor > version (i.e. STABLE). We try hard NOT to change the KBI within a single stable branch. we do things like add spare fields before we make a new stable branch to help with this. > In any case, I do strongly recommend the use of PORTS_MODULES in > /etc/src.conf to assure that the kernel modules always get re-built when > the kernel is re-built. so that the sources, the kernel, and the module are > in sync. The PORTS_MODULES are re-installed as a part of the "make > installkernel", so things are almost safe, but beware of "make > reinstallkernel" as it does not do the right thing. (See > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201779) > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > _______________________________________________ > 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 Mon Jun 20 11:42:41 2016 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 7AD83A7BB23 for ; Mon, 20 Jun 2016 11:42:41 +0000 (UTC) (envelope-from david@catwhisker.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 6605F2694 for ; Mon, 20 Jun 2016 11:42:41 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 654B0A7BB22; Mon, 20 Jun 2016 11:42:41 +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 64EC9A7BB21 for ; Mon, 20 Jun 2016 11:42:41 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BCE52692 for ; Mon, 20 Jun 2016 11:42:40 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id u5KBgdiV014502 for ; Mon, 20 Jun 2016 11:42:39 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u5KBgd3S014501 for current@freebsd.org; Mon, 20 Jun 2016 04:42:39 -0700 (PDT) (envelope-from david) Date: Mon, 20 Jun 2016 04:42:39 -0700 From: David Wolfskill To: current@freebsd.org Subject: "_secure_path: cannot stat /etc/login.conf: Not permitted in capability mode" Message-ID: <20160620114239.GQ1359@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yEbVe0JFHWhrOjGA" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 11:42:41 -0000 --yEbVe0JFHWhrOjGA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable After updating my (amd64) build machine from r302018 to r302026, things work OK, but (now that I've re-connected the serial cable so I can actually interact with the serial console -- i.e., this may have occurred a while back, but I wouldn't have noticed), I see: =2E.. Starting devd. add host 127.0.0.1: gateway lo0 fib 0: route already in table add net default: gateway 172.16.8.1 add FreeBSD/amd64 (freebeast.catwhisker.org) (ttyu0) login: Jun 20 11:34:16 freebeast sshd[736]: _secure_path: cannot stat /etc/= login.conf: Not permitted in capability mode Jun 20 11:34:16 freebeast last message repeated 2 times Jun 20 11:34:21 freebeast sshd[810]: _secure_path: cannot stat /etc/login.c= onf: Not permitted in capability mode Jun 20 11:34:21 freebeast last message repeated 2 times Jun 20 11:34:25 freebeast sshd[882]: _secure_path: cannot stat /etc/login.c= onf: Not permitted in capability mode on the serial console. Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --yEbVe0JFHWhrOjGA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXZ9avXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XL+YIAIgcF83xsUFfyBNGrRb2k3+L Ta32lUZXt2yh4OcfGB7ZqyEUlnlmIam5zo9ZkmRczgyGc/F356tY45ryM9RZq1lx XgdLT1Ms9RPJ4dZF5f/qe1dq5w5OEk+NrSXY5sJ7KHGSnlgHDWbUgcMb+DI9/uPO PifJx94HStaFYPRdxWzMTIeJu2vAzPdN1MMedaPfsXsBvrCGm2Gy3qcY+E6reTEX MfEEjfrE00UxNb1h3DIWu2TKwKoCd3FIpV3Dq103BAMsLfUqkdA12lAqqiwW9eBf LVjqt7/ZcMZQbOT/RJ3Q6AAJtOeEahxmvK3yZD6xWCCj5RT04mSJT7BuISgGqfs= =74n5 -----END PGP SIGNATURE----- --yEbVe0JFHWhrOjGA-- From owner-freebsd-current@freebsd.org Mon Jun 20 11:50:08 2016 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 26DA4A7BC4A for ; Mon, 20 Jun 2016 11:50:08 +0000 (UTC) (envelope-from joel@vnode.se) 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 15763287F for ; Mon, 20 Jun 2016 11:50:08 +0000 (UTC) (envelope-from joel@vnode.se) Received: by mailman.ysv.freebsd.org (Postfix) id 10CD0A7BC49; Mon, 20 Jun 2016 11:50:08 +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 1071BA7BC48 for ; Mon, 20 Jun 2016 11:50:08 +0000 (UTC) (envelope-from joel@vnode.se) Received: from smtp.vnode.se (smtp.vnode.se [IPv6:2a07:6c0:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id CE24E287E for ; Mon, 20 Jun 2016 11:50:07 +0000 (UTC) (envelope-from joel@vnode.se) Received: from ymer.vnode.se (81-235-218-96-no20.tbcn.telia.com [81.235.218.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.vnode.se (Postfix) with ESMTPSA id 6DD0D2BA56; Mon, 20 Jun 2016 13:49:59 +0200 (CEST) Date: Mon, 20 Jun 2016 13:49:58 +0200 From: Joel Dahl To: David Wolfskill , current@freebsd.org Subject: Re: "_secure_path: cannot stat /etc/login.conf: Not permitted in capability mode" Message-ID: <20160620114958.GA84024@ymer.vnode.se> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20160620114239.GQ1359@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160620114239.GQ1359@albert.catwhisker.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 11:50:08 -0000 On Mon, Jun 20, 2016 at 04:42:39AM -0700, David Wolfskill wrote: > After updating my (amd64) build machine from r302018 to r302026, things > work OK, but (now that I've re-connected the serial cable so I can > actually interact with the serial console -- i.e., this may have > occurred a while back, but I wouldn't have noticed), I see: > > ... > Starting devd. > add host 127.0.0.1: gateway lo0 fib 0: route already in table > add net default: gateway 172.16.8.1 > add > FreeBSD/amd64 (freebeast.catwhisker.org) (ttyu0) > > login: Jun 20 11:34:16 freebeast sshd[736]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode > Jun 20 11:34:16 freebeast last message repeated 2 times > Jun 20 11:34:21 freebeast sshd[810]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode > Jun 20 11:34:21 freebeast last message repeated 2 times > Jun 20 11:34:25 freebeast sshd[882]: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode Yes, me too. I reported this a few days ago here on current@. -- Joel From owner-freebsd-current@freebsd.org Mon Jun 20 14:18:04 2016 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 98ACAA78A49 for ; Mon, 20 Jun 2016 14:18:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) 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 76E0814B1 for ; Mon, 20 Jun 2016 14:18:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6F25FA78A46; Mon, 20 Jun 2016 14:18:04 +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 6E7BBA78A44; Mon, 20 Jun 2016 14:18:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 36E3814AF; Mon, 20 Jun 2016 14:18:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id f30so122924442ioj.2; Mon, 20 Jun 2016 07:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aSTFxSQHnqXqp0ZxEqAO17TAb9PpagTVJzuXiV0xEbw=; b=HIezpgehjete5ldt32UpVFBjCTzAgoRLWELIb3UD8KY7GHjgtQxb4SVDDe0Mb34uSR YphWiQ2OQ3O3EGOlojwP9Kfu/XGrAAuJLwvjoZKB73leOh+v5/WWpcCutyHguj355DRb IpdrjC+L55QiWwG2i40fXvwKd/KcNw81gHhRXz2OIhm3iCe23NqQud9m6PuzfBuS0VC4 Zht6czzsXZzOe4C4TWGMnNC5wvagq1ps2uUxt3iJoHtqctumc1siZurb6ro3f5m81KeU uYd09prH7xNZRabe0ZZu31Jl80IHfR7xnax+1pcfqoJDyHVU5Ks/xBPTWZ8KQ+uqSxHL wmmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aSTFxSQHnqXqp0ZxEqAO17TAb9PpagTVJzuXiV0xEbw=; b=e5hMQYebCDIjvIsTQGvrfT4LhBtK8yKT9iEolyq6CfVpyOs5cv/3j38uQJmnddcJ0g Vx7uicFKf16C+DJJES21lIh27XYNypdfLCScd7oaW2IJC6XzWR9ry2gPk6ScjBrEZBU0 NUuZCXosXiu8AgzXAkGFX4/FbQJjroqLehJMAHegvCZgmmW0OYET/II7GO7cmT1IBRVU fovKK6ZZsVjcVUksVN4VWq1JhaWRy3HTEfHWlvN8O9YkyLDpPwiK+dJmYOdDMHvOC+ho b5AIQs7Olk/JG+yvp/qVHAYko0GG04Z86k+rJN1QbHnE/3FDp3RjZUUTn/vQ0nSbpQqy Yh3g== X-Gm-Message-State: ALyK8tLjRSirQE9Z5+jC4A+S6tXF0ez2+/tB68AHtNZV034W/p3Zvn97ZcNNQ35Tv530f/7E3biRgX1+X2zWDg== X-Received: by 10.107.37.19 with SMTP id l19mr23129896iol.75.1466432282575; Mon, 20 Jun 2016 07:18:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.210.212 with HTTP; Mon, 20 Jun 2016 07:18:01 -0700 (PDT) In-Reply-To: References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> <20160620095822.GJ1076@FreeBSD.org> <20160620103015.GK1076@FreeBSD.org> From: Adrian Chadd Date: Mon, 20 Jun 2016 07:18:01 -0700 Message-ID: Subject: Re: panic with tcp timers To: Hans Petter Selasky Cc: Gleb Smirnoff , Julien Charbon , "net@freebsd.org" , "current@freebsd.org" , Randall Stewart Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 14:18:04 -0000 There's implications for RSS with how the callout system currently works. If you don't know the RSS bucket ID of a connection in advance, you'll create callouts on the wrong CPUs and then they're not migrated. The initial work here did convert things over, but didn't place the callouts in the right CPU/RSS bucket and there wasn't a mechanism to fix this. :( (But I'm also a firm believer of that too. I'd also finally just like the callout system to not be tied to per-CPU queues, but also per-RSS-bucket callout wheels so we could assign a CPU mask to a given callout wheel and then migrating things around is just "change cpu mask", not "change callout cpu id.") -adrian On 20 June 2016 at 04:00, Hans Petter Selasky wrote: > On 06/20/16 12:30, Gleb Smirnoff wrote: >> >> What does prevent us from converting TCP timeouts to locked? To my >> understanding it is the lock order of taking pcbinfo after pcb lock. > > > I started this work: > > https://reviews.freebsd.org/D1563 > > --HPS > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Jun 20 15:36:09 2016 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 15404AC4D81 for ; Mon, 20 Jun 2016 15:36:09 +0000 (UTC) (envelope-from luzar722@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 D436A2282 for ; Mon, 20 Jun 2016 15:36:08 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-io0-x233.google.com with SMTP id 5so133953031ioy.1 for ; Mon, 20 Jun 2016 08:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-transfer-encoding; bh=kXQyPeXoQL6Og1ag6ODfpR01WLr7ZZya402smzp7n2s=; b=0sjoEsdM6I+RCsQ5ORkwR0UV9YEa+onO/lKaQW9RA14xIfqTkQFolA9bc54H3/CiiF EnA4OhnFOx8sNg1AVsmI4/FdIUZ9z4PjmmS1p+lA6d1KHeVsmGb/8e4SvqQj7/OQojR1 KzQzWdrw5jSB+8otXefyqnguGTEKG3aPCJm3yMVgf58xv9eTSuOADxAqg6naqSl4GWwu PCwMPQ5PCsTIj4Sz00/fU8GPnR0z0BCF7lHGnbDVED+Y7x0Ee2VY3eoOrlQV8zi6wqqc C2LOPSvVnOF9HnV80zTxDm6eWqCL4K2poH7fVB/kAQBipwTaN0WiClCJ0zcTM1njNNXk 8ISg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-transfer-encoding; bh=kXQyPeXoQL6Og1ag6ODfpR01WLr7ZZya402smzp7n2s=; b=RXrc+i+05bQAjvxxtUNoX8sI3szholhoBYka4IN5g7lGdZLccwr3XrMZ8Hh0btTboI cKbZY3WEGZiGjpc2TUXJOk7j4VCXQdpHZ/btbhcdpscf1lsJKeeRHxn0G/v4NRAxYtkn YYdgb/RLXTrktrlBJVkT5192W89zQtFkHXM+Lq1g6hxLQMBct0Z5CHOizRLrLeHSjyGB dXOULblkkA3b54sRLFTHcA7KpRk/bwQnAZdRwgHaDIEUe2q9XHArMdv47H1MspufRy0g /ay8KTdy2iag1ggoc/8MAdKkAwabBLbAWd8FP/0VI/OWA0s6hB0a3YjWNh67akzRe1EY rdzA== X-Gm-Message-State: ALyK8tISaKVnd0h9T3BNMVKGTT9P+2xdSW1zjJExun12HLnw1katabL7EuXuKzUkXE0BuQ== X-Received: by 10.107.17.209 with SMTP id 78mr23210037ior.101.1466436968128; Mon, 20 Jun 2016 08:36:08 -0700 (PDT) Received: from [10.0.10.3] (cpe-184-56-210-236.neo.res.rr.com. [184.56.210.236]) by smtp.googlemail.com with ESMTPSA id e126sm6789787ith.21.2016.06.20.08.36.06 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Jun 2016 08:36:07 -0700 (PDT) Message-ID: <57680D69.7030309@gmail.com> Date: Mon, 20 Jun 2016 11:36:09 -0400 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: console in 11.0-ALPHA4 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.22 Precedence: 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, 20 Jun 2016 15:36:09 -0000 I have installed 11.0-ALPHA4-i386-20160617-r301975. The console looks very different from all previous releases. I find it to be harder to read. This manifests it self with the boot log messages and the normal behavior of the virtual consoles. But the real problem is in the notable hesitation when switching between virtual consoles. From the boot log (ie: dmesg) I see this VT(vga): resolution 640x480 This must be what is making the console display so different from previous releases. Can VT be configured to default to present the same console behavior as previous releases before this version of 11.0 gets published as RELEASE? About the "hesitation when switching between virtual consoles" I am thinking that this reduced performance may be caused by WITNESS being enabled in the ALPHA series of releases. Can anyone verify that this hesitation will not exist in the published RELEASE? In the boot log I get this message 16 times. "vicontrol: setting cursor type: Inappropriate ioctl for device" They don't seem to cause any problems that I have stumbled across. Is anyone else getting these "NOTICE" type messages? From owner-freebsd-current@freebsd.org Mon Jun 20 15:37:57 2016 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 88ADFAC4EE3 for ; Mon, 20 Jun 2016 15:37:57 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 3A48025AA for ; Mon, 20 Jun 2016 15:37:57 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-io0-x232.google.com with SMTP id 5so134001498ioy.1 for ; Mon, 20 Jun 2016 08:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-transfer-encoding; bh=VvxzLewQ05sORXzgjrFq80Rlb8zr0HrIOBoM1+coydc=; b=i/7W0V1XLwQcT+0NHuZeupfzDDqtzoT7rylJ2XfYxEPsCsG37hNw8P95fBvrXvUgeh 8DSArdYo/4zJRXV0ya5zv4zB22BI0wsAoQljRIVHBn922zEqswi7XwTmVgNrQC/bVPxB oWfuO+tN703JVnEbKa0G+zXSfLZh/307qDRByR1x53Y+dJY/+CaEiZuLkoEY6KAHO4ZZ v7NcpKbvJS1DEB732a5cWpWSuta4SBXypgxYMBJt+kKaXkAnYenJ1toc/YTELV1Kk/aK /V3Jd0YYi93m+7CJCBGOWOraaAt/QyU9Z4sidTbcu147lfL2r4DWUzxhr8qXEgfhWpPR 88iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-transfer-encoding; bh=VvxzLewQ05sORXzgjrFq80Rlb8zr0HrIOBoM1+coydc=; b=BIryFuI0j4WEJsSYgbpvEsOByLEmzAUNGzF2XG3vmXP5/IDk7zb5UZ4abD6kX57r/y Wc+oUakwpuOn++Ij+4fFD37wgo3MXZXcZ/L/BiApUnOpu9kM3gXDph37zqZsEZMv3wVP qd9mM/V/Clk47lMpQtRXaZV4tt8QsFZeVMaFGQKKj0/Rq1ig9OvHgGIDq1pgh/W/imHh cIkWT7vswBdWS1loMJZllkHI4CodOJ/rgL2vQ22m9wxzDbcg2j9Bw1bY45ShyRzH/30u V8WFo4goc3EY5dxwUeF2MDib0LCrFG+Z1jOsS7jJmVda5rr/duCyaNitP0j4OqX9ZYAp g8bw== X-Gm-Message-State: ALyK8tI72VZrPv8PhKC74g4CjQUWODitQWg37cl9DaS9oOlRK15vFcIGbwVrKAvXIg01Dg== X-Received: by 10.107.129.150 with SMTP id l22mr25838993ioi.170.1466437071850; Mon, 20 Jun 2016 08:37:51 -0700 (PDT) Received: from [10.0.10.3] (cpe-184-56-210-236.neo.res.rr.com. [184.56.210.236]) by smtp.googlemail.com with ESMTPSA id h125sm29985143ioa.20.2016.06.20.08.37.51 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 08:37:51 -0700 (PDT) Message-ID: <57680DD1.8040808@gmail.com> Date: Mon, 20 Jun 2016 11:37:53 -0400 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: 11.0-ALPHA4 and VIMAGE 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.22 Precedence: 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, 20 Jun 2016 15:37:57 -0000 Hello list; I have installed 11.0-ALPHA4-i386-20160617-r301975 to test VIMAGE. I have read previous list posts saying vimage was going to be part of the base system in 11.0. When I configure a jail with vnet I get a error typical of vimage not being compiled into the kernel. To me it looks like vimage is not part of the base system in 11.0. What is the status of vimage in 11.0? From owner-freebsd-current@freebsd.org Mon Jun 20 16:05:07 2016 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 73409A7B6FB for ; Mon, 20 Jun 2016 16:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B528187F for ; Mon, 20 Jun 2016 16:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CDA8B25D3A12; Mon, 20 Jun 2016 16:05:04 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id EDC30D1F7E0; Mon, 20 Jun 2016 16:05:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id JQffxbUd8God; Mon, 20 Jun 2016 16:05:02 +0000 (UTC) Received: from [192.168.124.1] (fresh-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4920:2ef0:eeff:fe03:ee34]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 91A78D1F7E6; Mon, 20 Jun 2016 16:05:02 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Ernie Luzar" Cc: freebsd-current@freebsd.org Subject: Re: 11.0-ALPHA4 and VIMAGE Date: Mon, 20 Jun 2016 16:05:01 +0000 Message-ID: <2003E00C-236B-4321-980E-474FD6243DD4@lists.zabbadoz.net> In-Reply-To: <57680DD1.8040808@gmail.com> References: <57680DD1.8040808@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate Trial (2.0BETAr6032) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 16:05:07 -0000 Hi, On 20 Jun 2016, at 15:37, Ernie Luzar wrote: > Hello list; > > I have installed 11.0-ALPHA4-i386-20160617-r301975 to test VIMAGE. > I have read previous list posts saying vimage was going to be part of > the base system in 11.0. When I configure a jail with vnet I get a > error typical of vimage not being compiled into the kernel. > > To me it looks like vimage is not part of the base system in 11.0. > > What is the status of vimage in 11.0? I am not sure anyone said that it would be in GENERIC for 11.0. The plan is to have it more stable and leak a lot less memory possibly and some bits made it in to HEAD over the last months already, another patch for a top-down teardown is in the review system, and I am currently working on fixing a lot of pf. /bz From owner-freebsd-current@freebsd.org Mon Jun 20 15:57:04 2016 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 B5CECA7B507; Mon, 20 Jun 2016 15:57:04 +0000 (UTC) (envelope-from loos.br@gmail.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 863DA121E; Mon, 20 Jun 2016 15:57:04 +0000 (UTC) (envelope-from loos.br@gmail.com) Received: by mail-it0-x231.google.com with SMTP id h190so41450371ith.1; Mon, 20 Jun 2016 08:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yhQbL9e6GqDcLLJEh98cqZ467Z+1DtO0B3UmKNgjHrs=; b=h7cRF+kHhyU45Lf7MLcrza1yxSkE7uHa/sSnt1oRnjsInNydxxIB6TnWzJJVUJcb1w 33kdDVkuBagigpa6c9QpjwlkCVRlh231IP2L9RH/ASc8+Yo0DuUPQdVkCyIuglRVIOeq 1GwzzvUZcDaGJwYTzQAxcupp7OF28mU4XsxwB4SX5Rxwb3KZK5cJB/IlyUut+3OAQVzT 3+ZZA+vWDx715pikTvW99idIkBanWLBD80uwX6zUAS9f2M+wB1P08k3dmt1w/3lwrYM9 vvLwaVQerX7fnVRmxuashyc2T16VLB8Pdt5AX00BruPru0FGSP9Qj7MpYhPD0cahLu4Y ra2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yhQbL9e6GqDcLLJEh98cqZ467Z+1DtO0B3UmKNgjHrs=; b=Zxk7pnh6g4aZ4RUCoJBXpUUTbRZdJ1duKiZz5n/Nh2wHd+k1ZvscMomxzWULZ0w2+e r8sGnUQUGTGOSEKjwao0CLAPDSW2kS/HqBPYjS5hmJyeylvKW9wztlBuUHlbC9UNTRlZ Fo5XNA1hQyulLa6BZLfkq4lohtSGLWuQi9P05dNUjyTkD+kyHPEmHvKtBwOs7ywTD8UM VBzWyQ9B2jMygIwZu9EcvGxE2O6EDq49yy8xObon0Uq8PLCb1mzEkUIAnWUQRqOP1hhv lBhqBOZmCYq6eorda7lKvrfHs6UudP0XR59ns0dLt8yJSfE8Z3sVQ32u3dPKLl2UN5Y/ +Vvg== X-Gm-Message-State: ALyK8tK0F4mamNZRQjqRa7MIJr7GWdR4Oij1bwSZPGisFGWfX13aKlwbONo4N3OKEHuvcu39DqEqvj/eoK3eQQ== X-Received: by 10.36.17.131 with SMTP id 125mr8799372itf.81.1466438223884; Mon, 20 Jun 2016 08:57:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.33.132 with HTTP; Mon, 20 Jun 2016 08:57:03 -0700 (PDT) In-Reply-To: References: <83A18C0E-FA89-4009-A8D5-3185FB27A688@netgate.com> From: Luiz Otavio O Souza Date: Mon, 20 Jun 2016 12:57:03 -0300 Message-ID: Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current To: Maxim Sobolev Cc: Jim Thompson , Svatopluk Kraus , "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: multipart/mixed; boundary=001a114452e26b900a0535b7c1e7 X-Mailman-Approved-At: Mon, 20 Jun 2016 16:14:28 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 15:57:04 -0000 --001a114452e26b900a0535b7c1e7 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote: > Jim, some update from here. Running r283287 of the driver, I still see the > same "watchdog timeout" messages, but they do not lead to the interface > lockout. The traffic resumes momentarily. Which is probably why I never paid > much attention to those warnings before. Therefore, I suspect that the new > MAC code does not deal with watchdog-triggered interface reset as good as > the old code. Does it give you any ideas about what could be wrong there by > any chance? Hi Maxim, My recent changes contributed somehow to expose the bug more frequently. There was a condition in tx packet reclamation where we aren't restarting the tx queue in one of the possible stall conditions. Please try the attached patch and let me know if it works for you. Luiz --001a114452e26b900a0535b7c1e7 Content-Type: text/plain; charset=US-ASCII; name="cpsw-eoq-restart.diff" Content-Disposition: attachment; filename="cpsw-eoq-restart.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ipo6vinw0 SW5kZXg6IHN5cy9hcm0vdGkvY3Bzdy9pZl9jcHN3LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2FybS90 aS9jcHN3L2lmX2Nwc3cuYwkocmV2aXNpb24gMzAxOTc1KQorKysgc3lzL2FybS90aS9jcHN3L2lm X2Nwc3cuYwkod29ya2luZyBjb3B5KQpAQCAtMTg3NCw2ICsxODc0LDcgQEAKIAkJcmV0dXJuOwog CX0gZWxzZSBpZiAobGFzdF9vbGRfc2xvdCA9PSBOVUxMKSB7CiAJCS8qIFN0YXJ0IGEgZnJlc2gg cXVldWUuICovCisJCXNjLT5zd3NjLT5sYXN0X2hkcCA9IGNwc3dfY3BkbWFfYmRfcGFkZHIoc2Mt PnN3c2MsIGZpcnN0X25ld19zbG90KTsKIAkJY3Bzd193cml0ZV9oZHBfc2xvdChzYy0+c3dzYywg JnNjLT5zd3NjLT50eCwgZmlyc3RfbmV3X3Nsb3QpOwogCX0gZWxzZSB7CiAJCS8qIEFkZCBidWZm ZXJzIHRvIGVuZCBvZiBjdXJyZW50IHF1ZXVlLiAqLwpAQCAtMTg4Miw2ICsxODgzLDcgQEAKIAkJ LyogSWYgdW5kZXJydW4sIHJlc3RhcnQgcXVldWUuICovCiAJCWlmIChjcHN3X2NwZG1hX3JlYWRf YmRfZmxhZ3Moc2MtPnN3c2MsIGxhc3Rfb2xkX3Nsb3QpICYKIAkJICAgIENQRE1BX0JEX0VPUSkg eworCQkJc2MtPnN3c2MtPmxhc3RfaGRwID0gY3Bzd19jcGRtYV9iZF9wYWRkcihzYy0+c3dzYywg Zmlyc3RfbmV3X3Nsb3QpOwogCQkJY3Bzd193cml0ZV9oZHBfc2xvdChzYy0+c3dzYywgJnNjLT5z d3NjLT50eCwKIAkJCSAgICBmaXJzdF9uZXdfc2xvdCk7CiAJCX0KQEAgLTE4OTcsNiArMTg5OSw3 IEBACiBjcHN3X3R4X2RlcXVldWUoc3RydWN0IGNwc3dfc29mdGMgKnNjKQogewogCXN0cnVjdCBj cHN3X3Nsb3QgKnNsb3QsICpsYXN0X3JlbW92ZWRfc2xvdCA9IE5VTEw7CisJc3RydWN0IGNwc3df Y3BkbWFfYmQgYmQ7CiAJdWludDMyX3QgZmxhZ3MsIHJlbW92ZWQgPSAwOwogCiAJc2xvdCA9IFNU QUlMUV9GSVJTVCgmc2MtPnR4LmFjdGl2ZSk7CkBAIC0xOTMxLDcgKzE5MzQsOCBAQAogCQl9CiAK IAkJLyogVGVhckRvd24gY29tcGxldGUgaXMgb25seSBtYXJrZWQgb24gdGhlIFNPUCBmb3IgdGhl IHBhY2tldC4gKi8KLQkJaWYgKGZsYWdzICYgQ1BETUFfQkRfVERPV05DTVBMVCkgeworCQlpZiAo KGZsYWdzICYgKENQRE1BX0JEX1NPUCB8IENQRE1BX0JEX1RET1dOQ01QTFQpKSA9PQorCQkgICAg KENQRE1BX0JEX0VPUCB8IENQRE1BX0JEX1RET1dOQ01QTFQpKSB7CiAJCQlDUFNXX0RFQlVHRihz YywgKCJUWCB0ZWFyZG93biBpbiBwcm9ncmVzcyIpKTsKIAkJCWNwc3dfd3JpdGVfY3Aoc2MsICZz Yy0+dHgsIDB4ZmZmZmZmZmMpOwogCQkJLy8gVE9ETzogSW5jcmVtZW50IGEgY291bnQgb2YgZHJv cHBlZCBUWCBwYWNrZXRzCkBAIC0xOTM4LDYgKzE5NDIsMTYgQEAKIAkJCXNjLT50eC5ydW5uaW5n ID0gMDsKIAkJCWJyZWFrOwogCQl9CisKKwkJaWYgKChmbGFncyAmIENQRE1BX0JEX0VPUCkgPT0g MCkKKwkJCWZsYWdzID0gY3Bzd19jcGRtYV9yZWFkX2JkX2ZsYWdzKHNjLCBsYXN0X3JlbW92ZWRf c2xvdCk7CisJCWlmICgoZmxhZ3MgJiAoQ1BETUFfQkRfRU9QIHwgQ1BETUFfQkRfRU9RKSkgPT0K KwkJICAgIChDUERNQV9CRF9FT1AgfCBDUERNQV9CRF9FT1EpKSB7CisJCQljcHN3X2NwZG1hX3Jl YWRfYmQoc2MsIGxhc3RfcmVtb3ZlZF9zbG90LCAmYmQpOworCQkJaWYgKGJkLm5leHQgIT0gMCAm JiBiZC5uZXh0ICE9IHNjLT5sYXN0X2hkcCkKKwkJCQkvKiBSZXN0YXJ0IHRoZSBxdWV1ZS4gKi8K KwkJCQljcHN3X3dyaXRlXzQoc2MsIHNjLT50eC5oZHBfb2Zmc2V0LCBiZC5uZXh0KTsKKwkJfQog CX0KIAogCWlmIChyZW1vdmVkICE9IDApIHsKSW5kZXg6IHN5cy9hcm0vdGkvY3Bzdy9pZl9jcHN3 dmFyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gc3lzL2FybS90aS9jcHN3L2lmX2Nwc3d2YXIuaAkocmV2aXNp b24gMzAxOTc1KQorKysgc3lzL2FybS90aS9jcHN3L2lmX2Nwc3d2YXIuaAkod29ya2luZyBjb3B5 KQpAQCAtODMsNiArODMsNyBAQAogCiAJLyogUlggYW5kIFRYIGJ1ZmZlciB0cmFja2luZyAqLwog CXN0cnVjdCBjcHN3X3F1ZXVlIHJ4LCB0eDsKKwl1aW50MzJfdAlsYXN0X2hkcDsKIAogCS8qIFdl IGV4cGVjdCAxIG1lbW9yeSByZXNvdXJjZSBhbmQgNCBpbnRlcnJ1cHRzIGZyb20gdGhlIGRldmlj ZSB0cmVlLiAqLwogCWludAkJbWVtX3JpZDsK --001a114452e26b900a0535b7c1e7-- From owner-freebsd-current@freebsd.org Mon Jun 20 16:40:16 2016 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 07C72A7BE48 for ; Mon, 20 Jun 2016 16:40:16 +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 DE0E32CA9 for ; Mon, 20 Jun 2016 16:40:15 +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 C0B74B96E; Mon, 20 Jun 2016 12:40:14 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Ernie Luzar Subject: Re: console in 11.0-ALPHA4 Date: Mon, 20 Jun 2016 09:26:50 -0700 Message-ID: <10947495.5QBkdNB94e@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <57680D69.7030309@gmail.com> References: <57680D69.7030309@gmail.com> 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); Mon, 20 Jun 2016 12:40:14 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 16:40:16 -0000 On Monday, June 20, 2016 11:36:09 AM Ernie Luzar wrote: > I have installed 11.0-ALPHA4-i386-20160617-r301975. > > The console looks very different from all previous releases. > I find it to be harder to read. This manifests it self with the boot log > messages and the normal behavior of the virtual consoles. > > But the real problem is in the notable hesitation when switching between > virtual consoles. > > From the boot log (ie: dmesg) I see this > VT(vga): resolution 640x480 > > This must be what is making the console display so different from > previous releases. Can VT be configured to default to present the same > console behavior as previous releases before this version of 11.0 gets > published as RELEASE? The difference is that vt(4) (the default console driver) only does software rendering of fonts. The older console driver syscons (sc(4)), used VGA text mode which uses a font in your adapter's BIOS ROM. The two fonts aren't quite the same. There is a 'vgarom' font you can try to use that should more closely match the previous console. > About the "hesitation when switching between virtual consoles" I am > thinking that this reduced performance may be caused by WITNESS being > enabled in the ALPHA series of releases. Can anyone verify that this > hesitation will not exist in the published RELEASE? I suspect this is just due to vt(4) rather than WITNESS. > In the boot log I get this message 16 times. > "vicontrol: setting cursor type: Inappropriate ioctl for device" > They don't seem to cause any problems that I have stumbled across. > Is anyone else getting these "NOTICE" type messages? vt(4) doesn't support several features that sc(4) supports. However, sc(4) doesn't support framebuffer systems very well, and does not support UTF-8, etc. Note that for comparisons you can enable vt(4) on stable/10 by setting 'kern.vty=vt' in loader.conf or at the loader prompt. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Jun 20 16:45:38 2016 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 7A456AC4001 for ; Mon, 20 Jun 2016 16:45:38 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 15E211167 for ; Mon, 20 Jun 2016 16:45:37 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id u5KGjRJ3053708 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jun 2016 18:45:27 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id u5KGjRIe053705; Mon, 20 Jun 2016 18:45:27 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Mon, 20 Jun 2016 18:45:27 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Ernie Luzar cc: FreeBSD current Subject: Re: console in 11.0-ALPHA4 In-Reply-To: <57680D69.7030309@gmail.com> Message-ID: References: <57680D69.7030309@gmail.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.9 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 mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 16:45:38 -0000 On Mon, 20 Jun 2016 11:36-0400, Ernie Luzar wrote: > I have installed 11.0-ALPHA4-i386-20160617-r301975. > > The console looks very different from all previous releases. > I find it to be harder to read. This manifests it self with the boot log > messages and the normal behavior of the virtual consoles. > > But the real problem is in the notable hesitation when switching between > virtual consoles. > > From the boot log (ie: dmesg) I see this > VT(vga): resolution 640x480 > > This must be what is making the console display so different from > previous releases. Can VT be configured to default to present the same > console behavior as previous releases before this version of 11.0 gets > published as RELEASE? If you want textmode like in the old days, add this line to /boot/loader.conf: hw.vga.textmode="1" You can also interrupt the final boot loader, and type: set hw.vga.textmode="1" Then type: menu or: boot > About the "hesitation when switching between virtual consoles" I am > thinking that this reduced performance may be caused by WITNESS being > enabled in the ALPHA series of releases. Can anyone verify that this > hesitation will not exist in the published RELEASE? The "hesitation" is sometimes hardware dependent. A GPU with a KMS driver makes it better. It's even worse in some virtualization environments, e.g. Microsoft Hyper-V. > In the boot log I get this message 16 times. > "vicontrol: setting cursor type: Inappropriate ioctl for device" > They don't seem to cause any problems that I have stumbled across. > Is anyone else getting these "NOTICE" type messages? If you decide to continue with the vt console, you should consider the following: With the new VT console in graphics mode, you don't need to load any fonts. Disable or remove any font lines from /etc/rc.conf. I haven't tried the vt console in text mode lately, so maybe you need the fonts in that case. Look for the appropriate keymap file in /usr/share/vt/keymaps/ and update the keymap line in /etc/rc.conf. Here's the Norwegian keyboard layout as an example: keymap="norwegian.iso" # Old Norwegian keymap for the sc console keymap="no" # New Norwegian keymap for the vt console -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Mon Jun 20 16:48:50 2016 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 D206DAC40DD for ; Mon, 20 Jun 2016 16:48:50 +0000 (UTC) (envelope-from julien.charbon@gmail.com) 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 AA9C11311 for ; Mon, 20 Jun 2016 16:48:50 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A6131AC40DB; Mon, 20 Jun 2016 16:48:50 +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 A58F2AC40DA; Mon, 20 Jun 2016 16:48:50 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) (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 3E2621310; Mon, 20 Jun 2016 16:48:50 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: by mail-wm0-f48.google.com with SMTP id r201so70242096wme.1; Mon, 20 Jun 2016 09:48:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=dspSP47DsoxtDUjUNH0mSVqm+HvYa1GNboskfxte0EI=; b=Btp3NJySvqzKM1XTn8aYcF+knIsTgIf5GIfUWNchIs9Sw3VCFoM/9OcXODBB0/ZHRA lNJLIZQzZ65/FQ+6r3auXjP0OLo4Y21BAnvC9JmTlNAm4sUwqUgpfDIyKuXj3RAGPS3F oPOuKJAJK2NuO4cQ5WLPW8L1b0NM5hSFMiwv4m/jVBfhADpit8VN6s4j43tQ4wvWtomY ibBkIsSudPkn0pFYvxQ++ILWFIMHPdloq62Dp3ymkSejy3vz2XYqdIfX3j6mekNtQvcs iH+mjza6imYON6Uagk0JYEXv44WNaQE6yai4at+f8sJ7UuV72vkTxT1yvllMaO99LY8W D/dw== X-Gm-Message-State: ALyK8tLSWFTWeBZE7oeQ0pNiZYcWHwnx11ar+huVAIQI15PYm5H+Toku8Y+qp5P7wpuB/Q== X-Received: by 10.28.45.201 with SMTP id t192mr12821342wmt.77.1466441317441; Mon, 20 Jun 2016 09:48:37 -0700 (PDT) Received: from [172.20.10.4] (48.228.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch. [178.197.228.48]) by smtp.gmail.com with ESMTPSA id t198sm14394128wmt.16.2016.06.20.09.48.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 09:48:36 -0700 (PDT) Subject: Re: panic with tcp timers To: Gleb Smirnoff , Hans Petter Selasky References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> <20160620095822.GJ1076@FreeBSD.org> <20160620103015.GK1076@FreeBSD.org> Cc: rrs@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org From: Julien Charbon Message-ID: <7294457d-07c0-2d6e-617b-15fa48bf2bb9@freebsd.org> Date: Mon, 20 Jun 2016 18:48:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160620103015.GK1076@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1Ta12WsRFnONHaUgmQbLo6tFj62n4m1rc" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 16:48:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1Ta12WsRFnONHaUgmQbLo6tFj62n4m1rc Content-Type: multipart/mixed; boundary="Mvq9GL89TXjDlopGgmEC0W8JMOWLNG1QO" From: Julien Charbon To: Gleb Smirnoff , Hans Petter Selasky Cc: rrs@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org Message-ID: <7294457d-07c0-2d6e-617b-15fa48bf2bb9@freebsd.org> Subject: Re: panic with tcp timers References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> <20160620095822.GJ1076@FreeBSD.org> <20160620103015.GK1076@FreeBSD.org> In-Reply-To: <20160620103015.GK1076@FreeBSD.org> --Mvq9GL89TXjDlopGgmEC0W8JMOWLNG1QO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On 6/20/16 12:30 PM, Gleb Smirnoff wrote: > On Mon, Jun 20, 2016 at 12:14:18PM +0200, Hans Petter Selasky wrote: > H> On 06/20/16 11:58, Gleb Smirnoff wrote: > H> > The fix I am working on now is doing exactly that. callout_reset m= ust > H> > return 0 if the callout is currently running. > H> > > H> > What are the old paths impacted? > H>=20 > H> I'll dig into the matter aswell and give some comments. Thanks for t= he=20 > H> analysis, Gleb. > H>=20 > H> FYI: This class of problems wouldn't exist if the callout could be=20 > H> associated with a mutex! >=20 > Exactly! I am convinced that all callouts should be locked, and non-loc= ked > one should simply go away, as well as async drain. >=20 > What does prevent us from converting TCP timeouts to locked? To my > understanding it is the lock order of taking pcbinfo after pcb lock. >=20 > I'm now trying to understand Julien's conversion from pcbinfo lock > to pcbinfo + pcblist locks. It seems to me that we actually can convert= > TCP timers to locked callouts. >=20 > What for do we need pcbinfo read lock in a tcp timer? The timer works > only on the pcb and doesn't modify global lists, does it? tcp_timer_keep() for example can modify global pcb list, see the call stack below: tcp_timer_keep() tcp_drop() tcp_close() sofree() tcp_usr_detach() (via pr->pr_usrreqs->pru_detach() in sofree()) tcp_detach() in_pcbfree() in_pcbremlists() Anyway, a bit of history here: o In stable/10 the TCP locking order is: ipi_lock (before) inpcb lock and in stable/10 ipi_lock is protecting the global pcb list. Then, only in the cases where you were absolutely sure you are _not_ going to modify the global pcb list you are allowed to take the inpcb lock only. For all the other cases, you have to take the write lock on ipi_lock first due to lock order. And in context of short-lived TCP connection of the 5 received packets for a TCP connection, 4 require the write ipi_lock lock, and that's does not scale well. Lesson learned: For scaling perspective, in lock ordering always put the most global lock last. It was improved in a lean way in 11: o In 11 the TCP lock order became: ipi_lock (before) inpcb lock (before) ipi_list And in 11 ipi_list protects global pcb list, and only the code actually modifying the global list is protected by a global write lock, e.g.: https://github.com/freebsd/freebsd/blob/master/sys/netinet/in_pcb.c#L1285= Then why keeping the ipi_lock lock at all now? It is solely for one case: When you need the complete stability of the full pcb list while traversing it. These full pcb list traversals are done in functions like: in_pcbnotifyall(), in_pcbpurgeif0(), inp_apply_all(), tcp_ccalgounload(), tcp_drain(), etc. Thus in 11 ipi_lock write lock is required only when you do this full traversal with list stability requirement, and the ipi_lock read lock in all other cases like tcp_input() that then scales better. Sadly in 11, you cannot use the inpcb lock as is for the TCP timers callout, because like tcp_timer_keep() most TCP timers callout can modify the global pcb list and then you need the read lock ipi_lock in top of inpcb lock... o Future/12: The next natural step is to remove the ipi_lock from the picture to get:= inpcb lock (before) ipi_list It /just/ requires a global pcb list that allows addition/deletion while doing a full traversal concurrently. A classical way to achieve that, is to use a RCU-based list. As soon as RCU (or anything equivalent like lwref) are supported in kernel, we will implement this change. Just history here, as I already did a presentation on this exact topic at BSDCan 2015: https://wiki.freebsd.org/201506DevSummit#line-83 It was recorded but I never saw the footage/presentation actually published. :) -- Julien --Mvq9GL89TXjDlopGgmEC0W8JMOWLNG1QO-- --1Ta12WsRFnONHaUgmQbLo6tFj62n4m1rc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXaB5jAAoJEKVlQ5Je6dhxuN8IAKeytbxsVb7bEK4iGl3HDY8X RRD4rBqamc4cVTzzLn75LpOkIXQZhj6SzaZKO5AfTjZ5eUSuabYubM3wcpai9swx UEoBCnjocNWjxJcElRwdN0CNgj0VtGPlNycWe+d8p3hRGqy14IdGEQ74+ru7ryC8 uGg/eJ0e73YmjVOZCthHHqyH1K+JLild16ZSH+1uFJt+KaPJjLBg5iQfXvM7t1HM yP7HvACAaQXFrUdw/L51pffdxOAwG1FHieQMw2Lu8GuoCn7dJ4hlxumETJpcPJY9 Torn0bCwg0fdSLQiHJbGLE5VywXzcIdb0KAxLBO+k6leCKbnU9lEkxkp7uihB6U= =xbUt -----END PGP SIGNATURE----- --1Ta12WsRFnONHaUgmQbLo6tFj62n4m1rc-- From owner-freebsd-current@freebsd.org Mon Jun 20 17:46:04 2016 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 653F2A7A15A for ; Mon, 20 Jun 2016 17:46:04 +0000 (UTC) (envelope-from julien.charbon@gmail.com) 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 484491810 for ; Mon, 20 Jun 2016 17:46:04 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 42EFDA7A157; Mon, 20 Jun 2016 17:46:04 +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 42807A7A156; Mon, 20 Jun 2016 17:46:04 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (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 D9A50180F; Mon, 20 Jun 2016 17:46:03 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: by mail-wm0-f49.google.com with SMTP id a66so89228845wme.0; Mon, 20 Jun 2016 10:46:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=I5fID0TamFhGqwFKXXP2M0uoJBITkuSZcBf7+qEgfMo=; b=BcGz9FqHx9fnP5e+VxXgPXos0tfIb7tYpHJ4OOqi0IohnGCjS9fN+tEOC/5mJy9K2J Ynwlp6ssMdoU+vgbEWeKlOQtsAkJuGBDeoEIZ64u+m7rdZ6BFoaGJavC+nlSyIfJyRqM fWQz6Vc1i8DxRWnR7WeqD1T3SeYrFhndN+DsNTpybm1ubxePTsJINW03yEi+qGXvdWRZ AX1OjIaeFZH6Jxe4tHr9trxWO+1Mb+6wftSEQgP+ORNLp/mqaatL5sAQ3mzQ1lMETpFJ 0HPhat8ZdV8TJE46BSRdXFPfu9i8oiLk0X1qq5H6VO8/p0TaqOrGzXZ8033OVq32EX9M I6XA== X-Gm-Message-State: ALyK8tKA1HntFiEpMIbttz1Rqb5rnlFTZzEIQ/rCtdWXIFCDkaVedxFKvrxLMatHruyq7Q== X-Received: by 10.28.157.1 with SMTP id g1mr12886852wme.34.1466444755441; Mon, 20 Jun 2016 10:45:55 -0700 (PDT) Received: from [10.100.64.16] ([217.30.88.7]) by smtp.gmail.com with ESMTPSA id li10sm20146765wjb.5.2016.06.20.10.45.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 10:45:54 -0700 (PDT) Subject: Re: panic with tcp timers To: Gleb Smirnoff References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> <20160620095822.GJ1076@FreeBSD.org> Cc: rrs@FreeBSD.org, hselasky@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org From: Julien Charbon Message-ID: <74bb31b7-a9f5-3d0c-eea0-681872e6f09b@freebsd.org> Date: Mon, 20 Jun 2016 19:45:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160620095822.GJ1076@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 17:46:04 -0000 Hi, On 6/20/16 11:58 AM, Gleb Smirnoff wrote: > On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote: > J> > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: > J> > J> > Comparing stable/10 and head, I see two changes that could > J> > J> > affect that: > J> > J> > > J> > J> > - callout_async_drain > J> > J> > - switch to READ lock for inp info in tcp timers > J> > J> > > J> > J> > That's why you are in To, Julien and Hans :) > J> > J> > > J> > J> > We continue investigating, and I will keep you updated. > J> > J> > However, any help is welcome. I can share cores. > J> > > J> > Now, spending some time with cores and adding a bunch of > J> > extra CTRs, I have a sequence of events that lead to the > J> > panic. In short, the bug is in the callout system. It seems > J> > to be not relevant to the callout_async_drain, at least for > J> > now. The transition to READ lock unmasked the problem, that's > J> > why NetflixBSD 10 doesn't panic. > J> > > J> > The panic requires heavy contention on the TCP info lock. > J> > > J> > [CPU 1] the callout fires, tcp_timer_keep entered > J> > [CPU 1] blocks on INP_INFO_RLOCK(&V_tcbinfo); > J> > [CPU 2] schedules the callout > J> > [CPU 2] tcp_discardcb called > J> > [CPU 2] callout successfully canceled > J> > [CPU 2] tcpcb freed > J> > [CPU 1] unblocks... panic > J> > > J> > When the lock was WLOCK, all contenders were resumed in a > J> > sequence they came to the lock. Now, that they are readers, > J> > once the lock is released, readers are resumed in a "random" > J> > order, and this allows tcp_discardcb to go before the old > J> > running callout, and this unmasks the panic. > J> > J> Highly interesting. I should be able to reproduce that (will be useful > J> for testing the corresponding fix). > J> > J> Fix proposal: If callout_async_drain() returns 0 (fail) (instead of 1 > J> (success) here) when the callout cancellation is a success _but_ the > J> callout is current running, that should fix it. > J> > J> For the history: It comes back to my old callout question: > J> > J> Does _callout_stop_safe() is allowed to return 1 (success) even if the > J> callout is still currently running; a.k.a. it is not because you > J> successfully cancelled a callout that the callout is not currently running. > J> > J> We did propose a patch to make _callout_stop_safe() returns 0 (fail) > J> when the callout is currently running: > J> > J> callout_stop() should return 0 when the callout is currently being > J> serviced and indeed unstoppable > J> https://reviews.freebsd.org/differential/changeset/?ref=62513&whitespace=ignore-most > J> > J> But this change impacted too many old code paths and was interesting > J> only for TCP timers and thus was abandoned. > > The fix I am working on now is doing exactly that. callout_reset must > return 0 if the callout is currently running. > > What are the old paths impacted? Actually all the paths that check the callout_stop() return value AND call both callout_reset() and callout_stop() AND use mpsafe callout(). And for each path, we would have to check our patch was ok (or not). Thus, if you only do the change in callout_async_drain() context, you don't impact the "old" callout_stop() behavior and get the desired behavior for the TCP timers. Might be a good trade-off... My 2 cents. -- Julien From owner-freebsd-current@freebsd.org Mon Jun 20 18:29:28 2016 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 0211CA7AE7B for ; Mon, 20 Jun 2016 18:29:27 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 B2C6B2E69; Mon, 20 Jun 2016 18:29:27 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-it0-x232.google.com with SMTP id f6so40546499ith.0; Mon, 20 Jun 2016 11:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=LBGualR5UAxNlMQmOKTYSIcPYahpTrOVxKgfo47hkeY=; b=eD7H9Gib8HAjV66a7NEiSTKNvVuiKdf6i9D7/xX4PmwCAIM8fmaoAw3JbzZj+cqx9E dClejUsMBO+6O558weJfWqVPNlVT7DeBdu9D0ZPOp7ReNIHCYKFm/7CxSQDT1+lxZGK5 Po0dnorjFACqEbgvx9XjOazTvn5RjSCDViLfxYrfNeO/pDg0am4ArRqSKdtDHIsMkBYC 2oNa1/UYkqauGWbJSdy3rTPxx4gkyRuXGqEsYkbXN+0P9V4WNGnkbFwOKpPKZODoxkCs kArEROpT+XWJK+4e4meeMAFV1DoU7CckKNLmmBVXXnRif6EZjMCK9PrkJUi8D8kvPyI1 xU0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-transfer-encoding; bh=LBGualR5UAxNlMQmOKTYSIcPYahpTrOVxKgfo47hkeY=; b=Ogih+EMyR0fGSiXu+GUbtnXipqp5bQmg99R1GHo7NGMthE9Lsir+Juin+tV019qrEq 5caV2nasiO/zJccl05MLU+ZmKHPaKzL8WiLEbp4jGJEeRQNCAk3PsUaWys6jT1slkHal /eQ67QduyEIGS5iMp7ZYk1z1d6AOUfMJIwiHb2qVDzTvnA1nR4IniaB0ncSjFMohlrEn D32aHnTZZ1pBu8bf2Db4fR1z36eEVIGGNLienlDt5B5bA1R4DBIXUI9GTmLUwTf2hb1+ gOe/TxK0wyymbEgRgNH1PMdN4dfaETZ8yAolhdYtvFKbdjT7nj+p/znAMKAHRtsS7uOp sWmg== X-Gm-Message-State: ALyK8tLnEu3z9Ykv/Bql+Ds2ND+sb938z6ltol4RftxhoswpB1rCK625CR3Q4ZNoO13kGg== X-Received: by 10.36.146.194 with SMTP id l185mr1195082itd.94.1466447367111; Mon, 20 Jun 2016 11:29:27 -0700 (PDT) Received: from [10.0.10.3] (cpe-184-56-210-236.neo.res.rr.com. [184.56.210.236]) by smtp.googlemail.com with ESMTPSA id f69sm27421064ioj.39.2016.06.20.11.29.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 11:29:26 -0700 (PDT) Message-ID: <57683610.1080402@gmail.com> Date: Mon, 20 Jun 2016 14:29:36 -0400 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Trond_Endrest=F8l?= CC: FreeBSD current , jhb@freebsd.org Subject: Re: console in 11.0-ALPHA4 References: <57680D69.7030309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 18:29:28 -0000 Trond Endrestøl wrote: > On Mon, 20 Jun 2016 11:36-0400, Ernie Luzar wrote: > >> I have installed 11.0-ALPHA4-i386-20160617-r301975. >> >> The console looks very different from all previous releases. >> I find it to be harder to read. This manifests it self with the boot log >> messages and the normal behavior of the virtual consoles. >> >> But the real problem is in the notable hesitation when switching between >> virtual consoles. >> >> From the boot log (ie: dmesg) I see this >> VT(vga): resolution 640x480 >> >> This must be what is making the console display so different from >> previous releases. Can VT be configured to default to present the same >> console behavior as previous releases before this version of 11.0 gets >> published as RELEASE? > > If you want textmode like in the old days, add this line to > /boot/loader.conf: > > hw.vga.textmode="1" > > You can also interrupt the final boot loader, and type: > > set hw.vga.textmode="1" > > Then type: > > menu > > or: > > boot > >> About the "hesitation when switching between virtual consoles" I am >> thinking that this reduced performance may be caused by WITNESS being >> enabled in the ALPHA series of releases. Can anyone verify that this >> hesitation will not exist in the published RELEASE? > > The "hesitation" is sometimes hardware dependent. A GPU with a KMS > driver makes it better. It's even worse in some virtualization > environments, e.g. Microsoft Hyper-V. > >> In the boot log I get this message 16 times. >> "vicontrol: setting cursor type: Inappropriate ioctl for device" >> They don't seem to cause any problems that I have stumbled across. >> Is anyone else getting these "NOTICE" type messages? > > If you decide to continue with the vt console, you should consider the > following: > > With the new VT console in graphics mode, you don't need to load any > fonts. Disable or remove any font lines from /etc/rc.conf. > > I haven't tried the vt console in text mode lately, so maybe you need > the fonts in that case. > > Look for the appropriate keymap file in /usr/share/vt/keymaps/ and > update the keymap line in /etc/rc.conf. > > Here's the Norwegian keyboard layout as an example: > > keymap="norwegian.iso" # Old Norwegian keymap for the sc console > > keymap="no" # New Norwegian keymap for the vt console > On my 10.3-p4 system I added these 2 lines to loader.conf kern.vty=vt hw.vga.textmode=1 This change caused my 10.3 system to use "vt" and returned the console behavior look and feel to be just like the (sc(4) console. The "hesitation when switching between virtual consoles" also no longer happens. I think its a mistake to default the vt console driver to graph mode in 11.0. It should default to hw.vga.textmode=1 mode to be consistent with previous RELEASE versions of FreeBSD. I found the cause of this boot time message "vicontrol: setting cursor type: Inappropriate ioctl for device" In my rc.conf I had this statement vidcontrol -c blink -h 250 From testing it seems that vt does not handle the "blink" option for causing the cursor to blink. Is there a vt option to enable cursor blinking And while we are on fallout from vt becoming the default console driver in 11.0, what about the loader.conf options for "splash" screens and the rc.conf option screen saver "saver= " and the "blanktime= " option. Have these been reviewed? Now here is the real show stopper. My rc.conf has moused_flags="-m 2=3" to enable mouse copy and past. This function on longer works under vt mode. From owner-freebsd-current@freebsd.org Mon Jun 20 18:31:10 2016 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 CC185AC4024 for ; Mon, 20 Jun 2016 18:31:10 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 95D15100F for ; Mon, 20 Jun 2016 18:31:10 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id z189so54379653itg.0 for ; Mon, 20 Jun 2016 11:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Yqu40TL38rglrAzCMvLEN0WeXaIvCLj5Lg5NBOhdPSo=; b=RV/Hc7SCX45Caosd0cRO+531PZOoXnQbl1nnuYOHlulJ91oCWRjY4sLNCfDqIfCBVO uesK7eP3n8GKsgpZKLoRkLpaRZOdL2eBX83jsrABua2wmsIwH7Dt33KWVTdWelE7FTlh 7JkQe6Q2kh87O1+uWagKVh9PQjjgk8m3oKKv3kn7jZu4KR19J07XO54igdNPhmppjkeP TUU86+sFDvqy55d67tK1bZJiuwSnHhYEl+g2pKeyX/CchPL3syEyvoLMlnRCh9ADbDRF gwu9CwsXAs/Q0G0P/6558+852ilhwXLDKKivwrOawoA8/OSE7u5cQAwtP62Pk4ugWto/ PLUw== 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:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=Yqu40TL38rglrAzCMvLEN0WeXaIvCLj5Lg5NBOhdPSo=; b=JO7RMTdfrAm15QSXvjw0qTzunNJ0HXIepwK4XRRiuoQsopNnAmfhsZoZa+iEl4vA+4 kdqk2WsDRnfQE2SE9xS+RKZt0bqkWLyBUlmBHrDARQepk8ASXk1CZq4VsG76NEX1Cc13 M/ea+pq+Ddmz7oQFCbtq7oylfLZXglPF4MG7qT05OMKu0/X8kgKy6CymlRT5T37TzRe+ vj3vLSoA1yPK0t8GjnMIsJPxtKdRX1J535b+FWuclutTipCQUUbPa800B72HuT7WNzKa PzO39zVP6IU4PBO5eLT4qgQtj500q4uUONrxg4cRE377hremxaEvv7RW2pdFoHbv/kcY RJRA== X-Gm-Message-State: ALyK8tLxP1OhzvV0BdtEND83yesVrUBc0ZYrdAmpFB/iuQUSn+nPisFMBRn5wB43sRlMcPxe8NuFWnyP6i+LHA== X-Received: by 10.36.73.3 with SMTP id z3mr1209060ita.68.1466447470058; Mon, 20 Jun 2016 11:31:10 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.6.213 with HTTP; Mon, 20 Jun 2016 11:30:50 -0700 (PDT) In-Reply-To: References: <57680D69.7030309@gmail.com> From: Ed Maste Date: Mon, 20 Jun 2016 14:30:50 -0400 X-Google-Sender-Auth: bUUREFvXGD18Nn9-8AFS9UJDJug Message-ID: Subject: Re: console in 11.0-ALPHA4 To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: Ernie Luzar , FreeBSD current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 18:31:10 -0000 On 20 June 2016 at 12:45, Trond Endrest=C3=B8l wrote: > > If you want textmode like in the old days, add this line to > /boot/loader.conf: > > hw.vga.textmode=3D"1" One note, in textmode vt(4) is limited to cp437. The console still uses Unicode internally but has a fixed lookup table to map to the cp437 character set. From owner-freebsd-current@freebsd.org Mon Jun 20 18:37:43 2016 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 2D004AC41E1; Mon, 20 Jun 2016 18:37:43 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 076A0172F; Mon, 20 Jun 2016 18:37:42 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from [172.27.2.35] (unknown [172.27.2.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 273C2541; Mon, 20 Jun 2016 14:31:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current From: Paul Mather In-Reply-To: Date: Mon, 20 Jun 2016 14:31:39 -0400 Cc: FreeBSD Current , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <71DC2BCB-C486-4772-AE32-CC0816B4E93F@gromit.dlib.vt.edu> References: To: Maxim Sobolev X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 18:37:43 -0000 On Jun 18, 2016, at 2:50 AM, Maxim Sobolev wrote: > Updated my BBB to the latest -current, immediately got this while = trying to > make world over ssh console: >=20 > 06:02:17 CPSW watchdog cpswss0: watchdog timeout > cpswss0: Unable to cleanly shutdown transmitter >=20 > Interface seems to be locked after that, no traffic comes in or out. >=20 > This is: >=20 > FreeBSD 11.0-ALPHA3 #1 ba7edef(tps65217x)-dirty: Fri Jun 17 16:22:07 = PDT > 2016, svn revision 301898 >=20 > The previous version that was rock-solid was: >=20 > FreeBSD 11.0-CURRENT #0 9d390ee(tps65217x)-dirty: Mon Jul 6 19:31:30 = PDT > 2015, svn revision 284878 >=20 > I've been running buildworlds for literally days on that board, = because > it's how long it takes to build on that hardware. :) >=20 > I'll run it again and see if the issue re-appears. >=20 > If anyone seen this or if it's known issue please let me know. I have experienced this problem recently, too, after updating to = 11.0-ALPHA3. I get the watchdog timeout messages you give above when = trying to buildworld with /usr/src and /usr/obj mounted via NFS. My last successful build that did not have this problem is this one: = FreeBSD beaglebone 11.0-ALPHA2 FreeBSD 11.0-ALPHA2 #0 r301779: Mon Jun = 13 01:30:05 EDT 2016 = pmather@beaglebone:/usr/obj/usr/src/sys/BEAGLEBONE-NO_WITNESS arm The build where this started happening for me is this one: FreeBSD = 11.0-ALPHA3 #0 r301876: Wed Jun 15 14:23:28 EDT 2016 That's just two days apart. Maybe that might help track down the = potential revision that caused the problem. I've not been able to = buildworld via NFS since the problem began, so I've reverted back to the = r301779 kernel for now. Cheers, Paul. From owner-freebsd-current@freebsd.org Mon Jun 20 18:57:39 2016 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 438B3AC4608 for ; Mon, 20 Jun 2016 18:57:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 011A820BB; Mon, 20 Jun 2016 18:57:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id g127so1648897ith.1; Mon, 20 Jun 2016 11:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aItqMm4zqTxKlZ0q6ZUiZWcGo2n4vrwyN12McKxcSBo=; b=j2GT10eaaK1Wu3+z8SeVpcImPPDxpK7eGV5AItnKFA+UVdBGwz9aiVqpuunVamHf4u k7zmn7fFYZelrtnNDZlaIXZHOkibKlnb3RrJUj0ZMjGCGU0wnkv9jbqQiSArpI9Lv+Dp RnIX6mjtNS8wvBf3nEcSETq3UY4Phfv9tE4tj+2G7II85CBWDdS86jAT5Z3Hy5R8DUbz qOxNXxfsqiJNv82b1F+JLBSir6RsvQ7NJjSM6s9pEY9u6/CXuTN9sHR7Iu/IYd8bh/qz esD2bc677oDcPoAtEnmyQ4g9WalZYIzTnaIeFxbUraH0JGODecuI4R1tifR1fNERiENI d5Yg== 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:from :date:message-id:subject:to:cc; bh=aItqMm4zqTxKlZ0q6ZUiZWcGo2n4vrwyN12McKxcSBo=; b=k8EMcvoyQ5l7ZC6yNLAhu8R6RUyT2AMBn2OspZvTjK226AIiW1n8Z/K+a72nwfWmoK 1CBPCTuX38b5+vbeWsJFigBsbDSmboD0rc7JHVIcWfKAkzOVIZPSxsTiCYbxOtTLAi9n 0pqIcpWoYDtaSk8vwntFYrEVyDfz9J2Tkmu3yvPJMqN/N4zXPeV0VEUFIJojj1dJIfVD 5yMlYSeLjcLb3B2wbsTAm8p16NxioDrSUmZbPTUw1VEXr5/Gh3lIzi3STRWclvzYR+Pr ilquzOYctCzlBQnBhiNPoxrZspHR9T7NldPGKPJeWYFn2wneQCym1m2UAvzFVS0LBp/I 9eeA== X-Gm-Message-State: ALyK8tIEpBMYbfNAq4/HitpJgLDb5DIY/7DzMfpyOx8qaBAJsBnsT+GX9bB58FEVAN6iOqdp6tlBRypmmZUd6A== X-Received: by 10.36.57.199 with SMTP id l190mr10855378ita.5.1466449058383; Mon, 20 Jun 2016 11:57:38 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.6.213 with HTTP; Mon, 20 Jun 2016 11:57:18 -0700 (PDT) In-Reply-To: <57683610.1080402@gmail.com> References: <57680D69.7030309@gmail.com> <57683610.1080402@gmail.com> From: Ed Maste Date: Mon, 20 Jun 2016 14:57:18 -0400 X-Google-Sender-Auth: 6X8a_JfpQkccjoh9wEHoO_NSdkI Message-ID: Subject: Re: console in 11.0-ALPHA4 To: Ernie Luzar Cc: =?UTF-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD current , John Baldwin Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 18:57:39 -0000 On 20 June 2016 at 14:29, Ernie Luzar wrote: > > I found the cause of this boot time message > "vicontrol: setting cursor type: Inappropriate ioctl for device" > > In my rc.conf I had this statement > vidcontrol -c blink -h 250 > From testing it seems that vt does not handle the "blink" option for causing > the cursor to blink. Is there a vt option to enable cursor blinking I've submitted two PRs for the issues you reported here: Bug 210413 - vidcontrol -c does not work with vt(4) Bug 210415 - vidcontrol -h does not work with vt(4) (edit) There is currently no option to enable cursor blinking. From owner-freebsd-current@freebsd.org Mon Jun 20 20:53:55 2016 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 D54F4AC456E for ; Mon, 20 Jun 2016 20:53:55 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 8F4E1240A; Mon, 20 Jun 2016 20:53:55 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-io0-x232.google.com with SMTP id f30so133519067ioj.2; Mon, 20 Jun 2016 13:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=ttmh1N02SUBMuS231aUS0QgRggibUE+2xkBIcrzx7c4=; b=0FR6WpmKQKWUJYdaFoiys3RuMMmRwT41Vchh52tr2bA0FIFBUFajE0eNtLqb+4y15D HbB9Cgsjs2iXe22OB7YH/q6P+sSwfiy1J5QapA0UPtYn7Das5VEmn6UgjADKeyYzPQ/7 Fwylw7lP2ii7EP9u7TCXfTLFXJGzADVyr4v9zy117tMq+Gc/ByRGywuArIUpFN3rXfyl uDezsFL29yMRO1OgwLpKfYPWx/WvmyMHNGPcThwEq2cyVS3LWzvmOcxsKfZ9CBF7Aq7P /ZsnLF2L8DXliYoWYv1Q4vulB7CY+KE9mJlKtYLkl78aASM6KcwcjzDUy1uuLi8jDTDW 6TYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-transfer-encoding; bh=ttmh1N02SUBMuS231aUS0QgRggibUE+2xkBIcrzx7c4=; b=f/lctvtYznUW51j52/0QiDgUx7RAOvCpW7ruqOZwFs2fAuXeekViewKAngwZjdHkZI PacVzeN1VTAxM+iIFNUE2eEFuWNtpdBxzmd5uolRZyZFgzneyLY8z7JFK9GLOoSkRwn0 0DSq2aX+QQqJmIxOGQuv+wJcHhXOFgKCzmmuq0BtmVestmlEXrcKRT48mD3pJZ5q1YNN D/NmqCkp9I0OpdhD5cE2dOK0Q+IabNh2ciW2Z7blh5DR7QcZGIPa2Waecb3Louza3jKD kdh1u1JLS5j/P9FeuzkTjHHtdYTq8OmH1X0MRfFlXU9nOLCV714NAiFDp43J/pWh8FfK Y8aQ== X-Gm-Message-State: ALyK8tIr6BWqbXfg3S2zbj8N4sDbkJzK+OYEl8PyIFRkZLjibFAGGflcYZzlz8B7Zil61w== X-Received: by 10.107.59.201 with SMTP id i192mr4959115ioa.89.1466456034875; Mon, 20 Jun 2016 13:53:54 -0700 (PDT) Received: from [10.0.10.3] (cpe-184-56-210-236.neo.res.rr.com. [184.56.210.236]) by smtp.googlemail.com with ESMTPSA id y73sm11217750iof.32.2016.06.20.13.53.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 13:53:54 -0700 (PDT) Message-ID: <576857F3.5040102@gmail.com> Date: Mon, 20 Jun 2016 16:54:11 -0400 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ed Maste CC: =?UTF-8?B?VHJvbmQgRW5kcmVzdMO4bA==?= , FreeBSD current , John Baldwin Subject: Re: console in 11.0-ALPHA4 References: <57680D69.7030309@gmail.com> <57683610.1080402@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 20:53:55 -0000 Ed Maste wrote: > On 20 June 2016 at 14:29, Ernie Luzar wrote: >> I found the cause of this boot time message >> "vicontrol: setting cursor type: Inappropriate ioctl for device" >> >> In my rc.conf I had this statement >> vidcontrol -c blink -h 250 >> From testing it seems that vt does not handle the "blink" option for causing >> the cursor to blink. Is there a vt option to enable cursor blinking > > I've submitted two PRs for the issues you reported here: > Bug 210413 - vidcontrol -c does not work with vt(4) > Bug 210415 - vidcontrol -h does not work with vt(4) (edit) > > There is currently no option to enable cursor blinking. Further testing shows that: 1. The rc.conf option screen saver "saver= " and the "blanktime= " options work in vt for both text and graph modes. 2. The cursor copy/paste does not work in vt text mode. It only works in vt graph mode. vt needs to be fixed so copy/paste function also works in text mode. 3. Boot time splash screen does not work in vt at all no matter which mode is enabled. Using this in loader.conf splash_bmp_load="YES" bitmap_name="/boot/splash.bmp" bitload_load="YES" This works in 10.x. The splash screen function can not be allowed to be removed from the base system just because vt can not handle it. This also means any vt changes need to updated in the handbook section on splash screen. In conclusion, vt is not ready to replace the sc console driver yet. vt needs to be fixed before becoming the default in 11.0. Using vt as the default console driver effects every user. It completely changes the FreeBSD experience. It's detrimental to the public relations and the professional image of FreeBSD to publish the 11.0-RELEASE using vt in its current condition. If time doesn't permit to get these vt things fixed before publishing 11.0 then vt should not become the default console driver. From owner-freebsd-current@freebsd.org Mon Jun 20 22:18:38 2016 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 587F0AC4788 for ; Mon, 20 Jun 2016 22:18:38 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from mippet.ci.com.au (mippet.ci.com.au [192.65.182.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mippet.ci.com.au", Issuer "mippet.ci.com.au" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E03D62BE0 for ; Mon, 20 Jun 2016 22:18:37 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from jodi.ci.com.au (jodi.ci.com.au [192.168.1.21]) by mippet.ci.com.au (8.15.2/8.15.2/CE160407) with ESMTPS id u5KMIYce044443 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 21 Jun 2016 08:18:34 +1000 (AEST) (envelope-from rpp@ci.com.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ci.com.au; s=jun2016; t=1466461114; bh=0KgAcVJowt/tknhKxMWJELLYg1BwQJ3NbcRzcZNrwo8=; h=Date:From:To:Subject:References:In-Reply-To; b=SXL0YUXi3jFkFdswiJjE4fWsZT8EWOi4o3JxtRTjSFwjyx6uNQSglRVouplJ8JK7c e24C49zlBwxw/BO2VkNY0oDJkdXT9o9jFSglZn+DKrH+bkWwnlHeoA8+jBJ32TfpSd J7/ypv69rg4O+u3Rlhs8WrL5485lB0ZUwrkmEMRTinFvvikHvJCygvdsh5TD1Ko+PK FUXVo7JX0+d0CFyjDH24o+P2Rb4wnlIEzI1yG3NKLFU0qxhLkwMKRrr58OoFBIkVZN 2ok6YvONTb5goYsy/2FuzO7I2NRQHr0iJwIulo4wr7klhF5Ds6sjN2Wx7eHDiNBZPA BVWfSuKOz49Dg== Received: from jodi.ci.com.au (localhost [127.0.0.1]) by jodi.ci.com.au (8.15.2/8.15.2) with ESMTP id u5KMIXNN069542 for ; Tue, 21 Jun 2016 08:18:33 +1000 (AEST) (envelope-from rpp@jodi.ci.com.au) Received: (from rpp@localhost) by jodi.ci.com.au (8.15.2/8.15.2/Submit) id u5KMIXKW069541 for freebsd-current@freebsd.org; Tue, 21 Jun 2016 08:18:33 +1000 (AEST) (envelope-from rpp) Date: Tue, 21 Jun 2016 08:18:33 +1000 From: Richard Perini To: freebsd-current@freebsd.org Subject: Re: Reproducible igb related panic 11.0-ALPHA4 Message-ID: <20160620221833.GA69507@jodi.ci.com.au> References: <20160620045430.GA47444@jodi.ci.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160620045430.GA47444@jodi.ci.com.au> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 22:18:38 -0000 On Mon, Jun 20, 2016 at 02:54:30PM +1000, Richard Perini wrote: > > Reproducible igb related panic 11.0-ALPHA4 > > OS: FreeBSD 11.0-ALPHA4 #6 r302022 > Hardware: Asus P9D C224 > (integrated > > Hi, > > Kernel panics within a few seconds with heavy network load. Using > "iperf -c another_host" is sufficient to induce the problem. Setting > hw.igb.enable_msix=0 in loader.conf "solves" the problem. Below is the > first few pages of crashinfo, + dmesg. The problem occurs on 2 instances > of similar hardware (with same motherboards). Submitted as PR 210417 --R From owner-freebsd-current@freebsd.org Mon Jun 20 22:21:34 2016 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 1FADFAC48BD for ; Mon, 20 Jun 2016 22:21:34 +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 04BC92F24 for ; Mon, 20 Jun 2016 22:21:33 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.10] (unknown [192.168.1.10]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id C2C3AD7F4 for ; Mon, 20 Jun 2016 22:21:32 +0000 (UTC) Subject: Re: Reproducible igb related panic 11.0-ALPHA4 To: freebsd-current@freebsd.org References: <20160620045430.GA47444@jodi.ci.com.au> <20160620221833.GA69507@jodi.ci.com.au> From: Allan Jude Message-ID: <8a9bdc85-a0bd-162e-bc4a-d0b742d1b8a9@freebsd.org> Date: Mon, 20 Jun 2016 18:21:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160620221833.GA69507@jodi.ci.com.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 22:21:34 -0000 On 2016-06-20 18:18, Richard Perini wrote: > On Mon, Jun 20, 2016 at 02:54:30PM +1000, Richard Perini wrote: >> >> Reproducible igb related panic 11.0-ALPHA4 >> >> OS: FreeBSD 11.0-ALPHA4 #6 r302022 >> Hardware: Asus P9D C224 >> (integrated > >> >> Hi, >> >> Kernel panics within a few seconds with heavy network load. Using >> "iperf -c another_host" is sufficient to induce the problem. Setting >> hw.igb.enable_msix=0 in loader.conf "solves" the problem. Below is the >> first few pages of crashinfo, + dmesg. The problem occurs on 2 instances >> of similar hardware (with same motherboards). > > Submitted as PR 210417 > > --R > _______________________________________________ > 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" > I was not able to reproduce this on my hardware. Can you use 'pciconf -lv' to find your card and get more specifics on which model of igb(4) it is? I am guessing by the C224 chipset, that it is haswell-ish -- Allan Jude From owner-freebsd-current@freebsd.org Mon Jun 20 22:33:32 2016 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 CE454AC4EC2; Mon, 20 Jun 2016 22:33:32 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "courriel.site.uottawa.ca", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93BB21973; Mon, 20 Jun 2016 22:33:31 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from [10.0.2.15] (ppp-66-186-88-176.vianet.ca [66.186.88.176]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id u5KMXMGs006384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jun 2016 18:33:23 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Mon, 20 Jun 2016 18:33:22 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Luiz Otavio O Souza cc: Maxim Sobolev , FreeBSD Current , "freebsd-arm@freebsd.org" Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current In-Reply-To: Message-ID: References: <83A18C0E-FA89-4009-A8D5-3185FB27A688@netgate.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 22:33:32 -0000 On Mon, 20 Jun 2016, Luiz Otavio O Souza wrote: > On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote: >> Jim, some update from here. Running r283287 of the driver, I still see the >> same "watchdog timeout" messages, but they do not lead to the interface >> lockout. The traffic resumes momentarily. Which is probably why I never paid >> much attention to those warnings before. Therefore, I suspect that the new >> MAC code does not deal with watchdog-triggered interface reset as good as >> the old code. Does it give you any ideas about what could be wrong there by >> any chance? > > > Hi Maxim, > > My recent changes contributed somehow to expose the bug more frequently. > > There was a condition in tx packet reclamation where we aren't > restarting the tx queue in one of the possible stall conditions. > > Please try the attached patch and let me know if it works for you. > > Luiz Your patch fixes the problem for me. Thanks! FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302028M: Mon Jun 20 18:19:55 EDT 2016 kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE-LOCAL arm armv6 ...keith From owner-freebsd-current@freebsd.org Mon Jun 20 22:49:51 2016 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 12658AC433F for ; Mon, 20 Jun 2016 22:49:51 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 C5BE923E3 for ; Mon, 20 Jun 2016 22:49:50 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ob0-x236.google.com with SMTP id ru5so684890obc.1 for ; Mon, 20 Jun 2016 15:49:50 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=54ofdZEFdIBKlqGqvy9pSO2qSJNY19Ajp6prF51P4f4=; b=z65MKsv7xzW2zdAaZqo4j6JcplgRvLj43+NBltAC7lkPlZXQBaFQHIGs54CdznqWC9 kZ3/kVvyMBBo0SAoTJrrUcFYmO/TFow+MxiHHmviJ7fuTObNjU1IymjCBdG2b7ddOQRI b4jutsj0AlK6ezEiJSor3OeTXwnf8id1b1Rxb3q8K0Ycrbv91Aa7PhWyFZHw0BpyrgkJ uRHKYKR3eVKv92egXfdPmAO23zlsnAsVPR/KsacV7++9eZAhx1oCgzU08AcuRvTULV0D gwAyhBgNM32CR6M/lwY/jrYjS/LseHZb7IHxogDtjX7hYtuYy6wQ0m3iPGFNiHt6fdQ0 P6wA== 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:from :date:message-id:subject:to:cc; bh=54ofdZEFdIBKlqGqvy9pSO2qSJNY19Ajp6prF51P4f4=; b=HKcLSz3Pc9yxia0m92MbW48STyyvIIcPxjN2t24GL8tQJC9G9WGg62YsfTED4TwSNO v2wp5AyZlPBWmo3hbepZr82LMOfhLLMnskK6GVUM/z57TlSRnWHyijVmOGqRNgFF7lv/ 2plt/AuZxvEDbvOij5Cb2BIxGO5FWrrsBwGa2TRmv843M1SR4v8Wf/E2y47UUwOukbVa MbkILEniKBY8L7hVdmpWEwNS7pJZlVZnvmWqzmt/i/yqBOHQMyV+TrrCMdp8D9yhNhGU v+vX+AWiZ2iCCj1rySDnC7Yc4Uisrs14lmqETewYozHKd50oKYfX2F7BgfIcO6Etgkvb 81RQ== X-Gm-Message-State: ALyK8tIKKVRYjwEbdTxY/sLHFoNIQjDH0srSddAXGJ7gv0k69BEq5O/crvq7jOAS18IYSemyFmUA7omGdzcHIX8m X-Received: by 10.157.1.241 with SMTP id e104mr12578205ote.180.1466462990041; Mon, 20 Jun 2016 15:49:50 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.157.41.209 with HTTP; Mon, 20 Jun 2016 15:49:49 -0700 (PDT) In-Reply-To: References: <83A18C0E-FA89-4009-A8D5-3185FB27A688@netgate.com> From: Maxim Sobolev Date: Mon, 20 Jun 2016 15:49:49 -0700 X-Google-Sender-Auth: gEWYWo7EFwQCgW6_SaSWTR8nC8I Message-ID: Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current To: Keith White Cc: Luiz Otavio O Souza , FreeBSD Current , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 22:49:51 -0000 Nice to hear. I am building it right now. Gotta get you some results in the next few hours. Thanks! -Max On Mon, Jun 20, 2016 at 3:33 PM, Keith White wrote: > On Mon, 20 Jun 2016, Luiz Otavio O Souza wrote: > > On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote: >> >>> Jim, some update from here. Running r283287 of the driver, I still see >>> the >>> same "watchdog timeout" messages, but they do not lead to the interface >>> lockout. The traffic resumes momentarily. Which is probably why I never >>> paid >>> much attention to those warnings before. Therefore, I suspect that the >>> new >>> MAC code does not deal with watchdog-triggered interface reset as good as >>> the old code. Does it give you any ideas about what could be wrong there >>> by >>> any chance? >>> >> >> >> Hi Maxim, >> >> My recent changes contributed somehow to expose the bug more frequently. >> >> There was a condition in tx packet reclamation where we aren't >> restarting the tx queue in one of the possible stall conditions. >> >> Please try the attached patch and let me know if it works for you. >> >> Luiz >> > > Your patch fixes the problem for me. Thanks! > > FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302028M: Mon Jun 20 > 18:19:55 EDT 2016 kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE-LOCAL > arm armv6 > > ...keith > From owner-freebsd-current@freebsd.org Mon Jun 20 23:23:18 2016 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 40FA8AC4F24 for ; Mon, 20 Jun 2016 23:23:18 +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 207A71756; Mon, 20 Jun 2016 23:23:18 +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 6F284B917; Mon, 20 Jun 2016 19:23:16 -0400 (EDT) From: John Baldwin To: Ernie Luzar Cc: Ed Maste , Trond =?ISO-8859-1?Q?Endrest=F8l?= , FreeBSD current Subject: Re: console in 11.0-ALPHA4 Date: Mon, 20 Jun 2016 16:22:53 -0700 Message-ID: <31205295.d0H0JTrSWj@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <576857F3.5040102@gmail.com> References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com> 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); Mon, 20 Jun 2016 19:23:16 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 20 Jun 2016 23:23:18 -0000 On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote: > Ed Maste wrote: > > On 20 June 2016 at 14:29, Ernie Luzar wrote: > >> I found the cause of this boot time message > >> "vicontrol: setting cursor type: Inappropriate ioctl for device" > >> > >> In my rc.conf I had this statement > >> vidcontrol -c blink -h 250 > >> From testing it seems that vt does not handle the "blink" option for causing > >> the cursor to blink. Is there a vt option to enable cursor blinking > > > > I've submitted two PRs for the issues you reported here: > > Bug 210413 - vidcontrol -c does not work with vt(4) > > Bug 210415 - vidcontrol -h does not work with vt(4) (edit) > > > > There is currently no option to enable cursor blinking. > > > Further testing shows that: > > 1. The rc.conf option screen saver "saver= " and the "blanktime= " > options work in vt for both text and graph modes. > > 2. The cursor copy/paste does not work in vt text mode. It only works in > vt graph mode. vt needs to be fixed so copy/paste function also works in > text mode. > > 3. Boot time splash screen does not work in vt at all no matter which > mode is enabled. Using this in loader.conf > splash_bmp_load="YES" > bitmap_name="/boot/splash.bmp" > bitload_load="YES" > > This works in 10.x. The splash screen function can not be allowed to be > removed from the base system just because vt can not handle it. This > also means any vt changes need to updated in the handbook section on > splash screen. > > In conclusion, vt is not ready to replace the sc console driver yet. vt > needs to be fixed before becoming the default in 11.0. Using vt as the > default console driver effects every user. It completely changes the > FreeBSD experience. It's detrimental to the public relations and the > professional image of FreeBSD to publish the 11.0-RELEASE using vt in > its current condition. If time doesn't permit to get these vt things > fixed before publishing 11.0 then vt should not become the default > console driver. OTOH, if you use EFI, then you can't use sc(4). You get no working console with EFI (which is becoming more popular) if you use sc(4). You also do not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable console if you use sc(4). You also do not have a working console after loading the KMS drivers (either by starting X or via explicit kldload) when using sc(4). This affects just about every modern Intel system using an Intel GPU (so more widespread than EFI even). There are tradeoffs in both directions. Neither console is a subset of the other. However, sc(4) is not really extendable to support the things it is missing. vt(4) is actively worked on, and patches for the features it lacks that you need are certainly welcomed. -- John Baldwin From owner-freebsd-current@freebsd.org Tue Jun 21 00:08:01 2016 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 600B5AC4D2C for ; Tue, 21 Jun 2016 00:08:01 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 1A0DC2CE8 for ; Tue, 21 Jun 2016 00:08:01 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22f.google.com with SMTP id a186so491392qkf.0 for ; Mon, 20 Jun 2016 17:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=TrZg6MK6asAik1ndhHaE7KeC9FyDvdsrY4NPAz4wSMw=; b=YVg4xX8b/bHfcBTMw353pmc9t6X5sHWSO9tCxAoDFzChyM8To7Zopx7CG+kUttxEC6 ltn0m5WxhdvLdSTEHs8QyYBCxqU4CHKZERS3XCvJLT7kM+HQBgN6JJwvnlGVY8u2k7G3 +ZqOiix1dv+8+a2H4FOunoHt1lojlY1zY0Nts= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TrZg6MK6asAik1ndhHaE7KeC9FyDvdsrY4NPAz4wSMw=; b=dGrfHY3j5yt1gHAu3iRpCpuXzAAXPhk+2MLpWxbmACUFdNDcpjDfddqu9frv0JwyEi MLJOgsxIFSM5YDmQkkDHA5ExP+0W/tH9SaP+xuWdagLSoxYq53l4iuCHZ1Mu1S+49rWo rPuiKLPUs1EVd6vsgFIHUs/DcxtsTaW04Sbex2GHVBYgZ6QFSVe6b8T4LOwq7MPhEgIM YKvIR3p16kYcqwrGp9es86qbBBJUqCaP1fZD1dtLGsWJET8UDO8CKU8e5HV7x1k1n9kJ mpAr1N10KzzmJ5TCbtaCA+Au1+vjfSU+aJ0WfH3ECbq5u8aCIGOfbIi7jwnESE/jP0KG ld5w== X-Gm-Message-State: ALyK8tL3EMHi/YHAAj5V66s4GUM1aJlMrbfhb3LePRAOZ6B7m/5Vjt0bptODffcdgD0B8Q== X-Received: by 10.55.111.66 with SMTP id k63mr26241860qkc.22.1466467680221; Mon, 20 Jun 2016 17:08:00 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id f13sm17638373qtc.2.2016.06.20.17.07.58 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 17:07:59 -0700 (PDT) Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held References: <1a55f000-eff9-31db-f420-e00278c4c054@bsd.com.br> To: freebsd-current From: =?UTF-8?B?T3RhY8OtbGlv?= X-Forwarded-Message-Id: <1a55f000-eff9-31db-f420-e00278c4c054@bsd.com.br> Message-ID: Date: Mon, 20 Jun 2016 21:07:38 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1a55f000-eff9-31db-f420-e00278c4c054@bsd.com.br> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 00:08:01 -0000 Em 19/06/2016 18:47, Otacílio escreveu: > Em 19/06/2016 18:40, Otacílio escreveu: >> I was installing netperf on a fresh FreeBSD-ALPHA3 >> >> FreeBSD beaglebone 11.0-ALPHA3 FreeBSD 11.0-ALPHA3 #0 r301846: Mon >> Jun 13 19:54:27 BRT 2016 >> ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG >> arm >> >> on BeagleboneBlack using wrtwn when I got this kernel panic: >> >> root@beaglebone:/usr/home/ota # pkg install netperf >> Updating FreeBSD repository catalogue... >> Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 >> Fetching packagesite.txz: 100% 4 MiB 46.0kB/s 01:42 >> Processing entries: 6%lock order reversal: >> 1st 0xc30b35d4 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2048 >> 2nd 0xc319d6f4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 >> stack backtrace: >> Processing entries: 58%Kernel page fault with the following >> non-sleepable locks held: >> exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f9d520) >> locked @ /usr/src/sys/netinet/tcp_syncache.c:494 >> shared rw tcp (tcp) r = 0 (0xc08ef348) locked @ >> /usr/src/sys/netinet/tcp_input.c:1034 >> exclusive rw tcpinp (tcpinp) r = 0 (0xc31ab494) locked @ >> /usr/src/sys/netinet/in_pcb.c:1964 >> stack backtrace: >> Fatal kernel mode data abort: 'Alignment Fault' on read >> trapframe: 0xdcfe58a8 >> FSR=00000001, FAR=c2e7187a, spsr=60000013 >> r0 =c08e7988, r1 =00000004, r2 =c06fa3ad, r3 =000007b6 >> r4 =dcfe5a10, r5 =dcfe5b28, r6 =c2e71876, r7 =c2f9d520 >> r8 =c2f9d520, r9 =c2e71876, r10=dcfe5b28, r11=dcfe5970 >> r12=00000000, ssp=dcfe5938, slr=c2d34370, pc =c053d8e8 >> >> [ thread pid 13 tid 100036 ] >> Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} >> db> >> >> >> []'s >> >> -Otacílio >> > The kernel panic is totally reproducible. I need only do a ssh in the > beaglebone using ptty on windows or ssh on freebsd and the kernel > panic is raised. > > FreeBSD/arm (beaglebone) (ttyu0) > > login: Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f95480) > locked @ /usr/src/sys/netinet/tcp_syncache.c:494 > shared rw tcp (tcp) r = 0 (0xc08ef348) locked @ > /usr/src/sys/netinet/tcp_input.c:1034 > exclusive rw tcpinp (tcpinp) r = 0 (0xc341e494) locked @ > /usr/src/sys/netinet/in_pcb.c:1964 > stack backtrace: > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xdcfe58a8 > FSR=00000001, FAR=c2e7807a, spsr=60000013 > r0 =c08e7988, r1 =00000004, r2 =c06fa3ad, r3 =000007b6 > r4 =dcfe5a10, r5 =dcfe5b28, r6 =c2e78076, r7 =c2f95480 > r8 =c2f95480, r9 =c2e78076, r10=dcfe5b28, r11=dcfe5970 > r12=00000000, ssp=dcfe5938, slr=c2d34370, pc =c053d8e8 > > [ thread pid 13 tid 100036 ] > Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} > db> > FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need to raise the fault is ssh in the beaglebone. root@beaglebone:~ # uname -a FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r301975: Fri Jun 17 13:32:55 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm root@beaglebone:~ # Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f98740) locked @ /usr/src/sys/netinet/tcp_syncache.c:494 shared rw tcp (tcp) r = 0 (0xc08ef348) locked @ /usr/src/sys/netinet/tcp_input.c:1034 exclusive rw tcpinp (tcpinp) r = 0 (0xc33e4494) locked @ /usr/src/sys/netinet/in_pcb.c:1964 stack backtrace: Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xdcfe58c0 FSR=00000001, FAR=c2e7a07a, spsr=60000013 r0 =c08e7988, r1 =00000004, r2 =c06fabe6, r3 =000007b6 r4 =dcfe5a28, r5 =dcfe5b40, r6 =c2e7a076, r7 =c2f98740 r8 =c2f98740, r9 =c2e7a076, r10=dcfe5b40, r11=dcfe5988 r12=00000000, ssp=dcfe5950, slr=c2d33370, pc =c053df7c [ thread pid 13 tid 100036 ] Stopped at syncookie_lookup+0x38: ldmib r6, {r1-r2} db> From owner-freebsd-current@freebsd.org Tue Jun 21 01:01:16 2016 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 BC546A7AC6D for ; Tue, 21 Jun 2016 01:01:16 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 840D7184D; Tue, 21 Jun 2016 01:01:16 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-io0-x234.google.com with SMTP id n127so3374734iof.3; Mon, 20 Jun 2016 18:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=pqH1lyTXiuGn/01Xo0ZjI94qZ1QWmm/MiNrOjwtsr2E=; b=Rjckyv/ERTsgWbiOGHNqVTq/oLZR9bZ8H7/PX6HfambsyumvHOKQwomoGFPDlrsMUO gIT9hnmxKt9B2Sq7i8XPiLyBeADheVKyyutaAQ5OYjmliQjb2WvozMFIYbg5ehmFnl6G /KarQQICsC4jIagtGafvN6z0sGtzFnyfNRsTGkIwAezL+g1gUXfMDMJqPoXa3prxqB6c YtFDMpqlaN0ocNDl387FfZe6U9/UoEiwCVjnhsQeSNS0r5DRvEyDnDRWhA1ck5T13J5j DTQaOV17C0ZCpUYNbzNG0NQCeVhCsVeCssIwAKnesqvMB6hb0sXWNpDLzd+KhY/fj5m9 B8iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-transfer-encoding; bh=pqH1lyTXiuGn/01Xo0ZjI94qZ1QWmm/MiNrOjwtsr2E=; b=NZxM58ZnwZm0kI/0dPRwcOq+3QFQrLaJs4dE+JLMpa2v76ii49SqSMbDW8wYAEH69J pmYsTAHLxDCJshafSOaggHqLmb9iD0MfE68Vn22A7kBWy0ZSbSdeLXm5OdyqjTNKa7/K kO74IKSyB+GoCoMlUE8h38J8b3v6Iy0yEfOT/c/fs7J6Uu/EIog+zTmhXA2qvkoTySYV jf7sLyPkEtO/wtkKwZ3oD4vDAydsHYsT4DZw4O5etQcy71XyrYBJqIEyOaVF65kXVSkV Lasl08TVFno0FMISj0qv7yNSML4og0edoz5naavXaU4/JbAfPtrygKsyFNIl6wdyawD5 HJKQ== X-Gm-Message-State: ALyK8tIS1rsbG2YVo03skly0f0Vc5Z5/ZuiogYPf5ERsGg1CcdhCZt4Na4I3q/HPEeDqxg== X-Received: by 10.107.26.76 with SMTP id a73mr1265544ioa.13.1466470875819; Mon, 20 Jun 2016 18:01:15 -0700 (PDT) Received: from [10.0.10.3] (cpe-184-56-210-236.neo.res.rr.com. [184.56.210.236]) by smtp.googlemail.com with ESMTPSA id o2sm164567ith.7.2016.06.20.18.01.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 18:01:15 -0700 (PDT) Message-ID: <576891F8.1010200@gmail.com> Date: Mon, 20 Jun 2016 21:01:44 -0400 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Baldwin CC: Ed Maste , =?ISO-8859-1?Q?Trond_Endrest=F8l?= , FreeBSD current Subject: Re: console in 11.0-ALPHA4 References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com> <31205295.d0H0JTrSWj@ralph.baldwin.cx> In-Reply-To: <31205295.d0H0JTrSWj@ralph.baldwin.cx> 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.22 Precedence: 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, 21 Jun 2016 01:01:16 -0000 John Baldwin wrote: > On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote: >> Ed Maste wrote: >>> On 20 June 2016 at 14:29, Ernie Luzar wrote: >>>> I found the cause of this boot time message >>>> "vicontrol: setting cursor type: Inappropriate ioctl for device" >>>> >>>> In my rc.conf I had this statement >>>> vidcontrol -c blink -h 250 >>>> From testing it seems that vt does not handle the "blink" option for causing >>>> the cursor to blink. Is there a vt option to enable cursor blinking >>> I've submitted two PRs for the issues you reported here: >>> Bug 210413 - vidcontrol -c does not work with vt(4) >>> Bug 210415 - vidcontrol -h does not work with vt(4) (edit) >>> >>> There is currently no option to enable cursor blinking. >> >> Further testing shows that: >> >> 1. The rc.conf option screen saver "saver= " and the "blanktime= " >> options work in vt for both text and graph modes. >> >> 2. The cursor copy/paste does not work in vt text mode. It only works in >> vt graph mode. vt needs to be fixed so copy/paste function also works in >> text mode. >> >> 3. Boot time splash screen does not work in vt at all no matter which >> mode is enabled. Using this in loader.conf >> splash_bmp_load="YES" >> bitmap_name="/boot/splash.bmp" >> bitload_load="YES" >> >> This works in 10.x. The splash screen function can not be allowed to be >> removed from the base system just because vt can not handle it. This >> also means any vt changes need to updated in the handbook section on >> splash screen. >> >> In conclusion, vt is not ready to replace the sc console driver yet. vt >> needs to be fixed before becoming the default in 11.0. Using vt as the >> default console driver effects every user. It completely changes the >> FreeBSD experience. It's detrimental to the public relations and the >> professional image of FreeBSD to publish the 11.0-RELEASE using vt in >> its current condition. If time doesn't permit to get these vt things >> fixed before publishing 11.0 then vt should not become the default >> console driver. > > OTOH, if you use EFI, then you can't use sc(4). You get no working console > with EFI (which is becoming more popular) if you use sc(4). You also do > not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable > console if you use sc(4). You also do not have a working console after > loading the KMS drivers (either by starting X or via explicit kldload) when > using sc(4). This affects just about every modern Intel system using an > Intel GPU (so more widespread than EFI even). > > There are trade offs in both directions. Neither console is a subset of the > other. However, sc(4) is not really expendable to support the things it is > missing. vt(4) is actively worked on, and patches for the features it lacks > that you need are certainly welcomed. > This sounds like a integration design error. From your description of the hardware that vt is designed for and sc is designed for indicates the need for some code to be added to the boot process that inspects the hardware and decides whether vt or sc is to be launched. Or maybe bsdinstall should inspect the hardware and give the installer the option to select what console is best for his hardware. Just forcing this version of vt that lacks long time functions as the default console driver is not the professional way to handle such conflicts. I am at a lost to understand how any development administrator would approve making vt the default console driver in light of the standard functions missing from it. And furthermore what kind of vt testing was done that these problems were missed. Any one of these problems is enough cause to reverse the decision to make vt the default console driver for 11.0. This would give time for these problems to be address and correctly tested and when ready then be paced in some other 11.x release. From owner-freebsd-current@freebsd.org Tue Jun 21 03:47:43 2016 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 2BAFBAC5DA5 for ; Tue, 21 Jun 2016 03:47:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 E9A212D2F; Tue, 21 Jun 2016 03:47:42 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id f6so5169721ith.0; Mon, 20 Jun 2016 20:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wsexcICofs5LtCWi3MSkG4PcrmPsJr9cQGH5Vqg95Gc=; b=brhvbdW3ABVMV9RPP75qMceHVYZOQCVq0WQudRHyntUwB2MDFfB8Jd8EPGvsfmVZf0 tEeZgPnIKI+gVqXBcQceLgPl/0PId7JGUv2e1bRAYGj5+qBYdHrvtpCKvE4I6O6xl9DJ qsPwJSfmNqAUkMogOIIdvKQU5YPt7UfdC+tXi3vlDPEpoStbzEPKMYCoBCbzdqK9oilC 6669W9mEM5RAhUsfFf7MooSMoKgcHZW5Kv/p7HohMhQCHXkZXQbtvkoWb8tPMsOmPr1j /ZfaokbSUFuTWPhQHCpJSr2+goLUSFWawMJfX4aGJaVkJ+UyOsT/ZGNU1gyXG3F9p+tr WAfg== 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:from :date:message-id:subject:to:cc; bh=wsexcICofs5LtCWi3MSkG4PcrmPsJr9cQGH5Vqg95Gc=; b=lEI55vX0q5dRb2EA157lf2bZlnXB1aBmiSz3V93Pwip83ofKN37SYQpnufSlgVsMn5 VaxjFDlGpij8Zkx86/27qgzXsmT0hj5hWBFa0FJVEygg7nrytcf3qcWipetFCDWX8X8/ Dv/RHi69JVt9licpVT2FbQHT/w+GmxTeBfoaNxo+Do9NbokoQ3nMpMNLNemdEFt2L4Cg klQIFoRF7jsFVwkX9skkluV8nRo+tiTEbE+ofvIZ7fcEXcr9iiSGQCMf7yNb2pAWWZKf 3JTl8JXLCyj5MiYbwQQTHCkAg5eIPWQbk5ZoSBTuHjfHUJPEB6FV6WBxIeQVT0n8f/yf PtXg== X-Gm-Message-State: ALyK8tJQ+xPZcNJy6O/myBJwucpl0AAy4hgJY2/78XibBxHc0KJkigJg9vJJhAa4RNrlXbJKoTUbsM6505Cb2A== X-Received: by 10.36.239.70 with SMTP id i67mr1973372ith.59.1466480862421; Mon, 20 Jun 2016 20:47:42 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.6.213 with HTTP; Mon, 20 Jun 2016 20:47:22 -0700 (PDT) In-Reply-To: <31205295.d0H0JTrSWj@ralph.baldwin.cx> References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com> <31205295.d0H0JTrSWj@ralph.baldwin.cx> From: Ed Maste Date: Tue, 21 Jun 2016 03:47:22 +0000 X-Google-Sender-Auth: FaWjWIJR45PYuMNV5PCS9HhZMR0 Message-ID: Subject: Re: console in 11.0-ALPHA4 To: John Baldwin Cc: Ernie Luzar , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 03:47:43 -0000 On 20 June 2016 at 23:22, John Baldwin wrote: > > There are tradeoffs in both directions. Neither console is a subset of the > other. However, sc(4) is not really extendable to support the things it is > missing. vt(4) is actively worked on, and patches for the features it lacks > that you need are certainly welcomed. You may also switch back to sc(4) by adding "kern.vty=sc" to /boot/loader.conf. From owner-freebsd-current@freebsd.org Tue Jun 21 04:03:02 2016 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 68598A7A226; Tue, 21 Jun 2016 04:03:02 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 04E5F1693; Tue, 21 Jun 2016 04:03:01 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-993ff70000005c19-32-5768bc7287d2 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id EC.10.23577.27CB8675; Tue, 21 Jun 2016 00:02:59 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u5L42wJ0002724; Tue, 21 Jun 2016 00:02:58 -0400 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 u5L42tZc004807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jun 2016 00:02:57 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u5L42s6A013482; Tue, 21 Jun 2016 00:02:54 -0400 (EDT) Date: Tue, 21 Jun 2016 00:02:54 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: Call for 2016Q2 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+NgFrrIIsWRmVeSWpSXmKPExsUixG6nolu8JyPc4NAlBYs5bz4wWWzf/I/R gcljxqf5LAGMUVw2Kak5mWWpRfp2CVwZnz4vYSs4zlWxs+UTUwPjI44uRk4OCQETiXMnHzN2 MXJxCAm0MUlc2HuUFcLZyCgxZe0RKOcQk8T9g5vYIZwGRol9J+azgfSzCGhLLDy8hgXEZhNQ k1i/4hozxFxFic2nJoHZIgLyEvua3rOD2MxA9pbVk8F6hQUMJXZfvcUIYvMKOEosOdPPBGKL CuhIrN4/hQUiLihxcuYTFoheLYnl07exTGDkn4UkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLk xLy81CJdI73czBK91JTSTYygkOOU5N3B+O+u1yFGAQ5GJR7eCsOMcCHWxLLiytxDjJIcTEqi vMzKQCG+pPyUyozE4oz4otKc1OJDjBIczEoivB7bgXK8KYmVValF+TApaQ4WJXHemJtHw4QE 0hNLUrNTUwtSi2CyMhwcShK8cbuBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGbwKp4S0uSMwtzkyH yJ9iVJQS510KkhAASWSU5sH1glPCbibVV4ziQK8I86qDVPEA0wlc9yugwUxAg5f1p4MMLklE SEk1MN5bsqb61kFrq64VmrsjBKuPMdi1RidemG0672o1Q8jcZxfUhcKrjJbn1H29IVv9gmVH 5vztR8+v+lth7NL379yE0t3fz99W0k4r0NrD1D1rXXHl5Ig5jxbXtQpJLD0hva7WR8/1jvRG 7Z51PLmmP3eXJ4TvMGGSWKQbIfKJse7apj7l1I610UosxRmJhlrMRcWJADNJCrrkAgAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 04:03:02 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is July 7, 2016, for work done in April through June. 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 2016Q2 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-10-2015-12.html [4] http://www.freebsd.org/news/status/report-2016-01-2016-03.html From owner-freebsd-current@freebsd.org Tue Jun 21 04:10:12 2016 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 F2548A7A5AC for ; Tue, 21 Jun 2016 04:10:12 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 B99EB1B09; Tue, 21 Jun 2016 04:10:12 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-it0-x235.google.com with SMTP id h190so5499747ith.1; Mon, 20 Jun 2016 21:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ukf7gnlXaYkti8W/I1mXAfzF+GdNonqLUmPRfk9bF4k=; b=zQwSyK2hxXu5u910oCoq9oupI56j9SrWXSHzN4EZd89E1B3ei1aN9KloM2CNP0ggXU Rkj2GqbR0JvMR3XdIo5+z+Wd8VfiCybuQBUlf+B3iw22DibWYObHdMaYQXGWAzOZL5Vh G6bJcdeAalA0SKc9Hex5wdemcO9+1aEWyd0jn2KqmdnQQ/gcG/FNMLHouv4GVdazEFhM ocICLfhz4BHhQwBflERbUGKH5bpW00JaeJ8Atit/fPOkCVKnjavpmLggtYLwjzrG9b+P S0TZYIZPOEb9CtWydfqPPvPAa/5VRAc2DTswbOGfY/k8mlUP33oRnk6iVvNi+EqeemHW OrFA== 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:from :date:message-id:subject:to:cc; bh=Ukf7gnlXaYkti8W/I1mXAfzF+GdNonqLUmPRfk9bF4k=; b=QvQypPv20l0q3OkbzbK3cqD1FhKtH9eYzAyWn+XqZhnVqALWgq8uiC5KD/KquKB12N wqTshLcjk237eZA/krcYOpVT4S93QPdXtXkQoRbcVvU1H83jDkxzGOwdEh4giPZIq3S/ PIP+MtznhTuUyIOV5Dfg+0F60kRTsb5sdQ2NiRRbQAkGJHdwGohBw4nJeIfJIf07v+Yy e8Ka49vv44BCoytzXHBaqFzZeS8P/v9MxClGc0+lGRPJq3uflmxhf75I33Nkc6s4hNtW V/4irtW/9Noab83Jv681ELFQ7nDJGLZ49VhYqG7Bdc+k/hmqeq6efSnZk5kgChufNqbI 2xwA== X-Gm-Message-State: ALyK8tLB6CShpm/C4xVINsHjaN6k65tB+NwkwGxICsAQdK1GUyjjP8c6ASvW5cWPzmJlvZ//DrRW+wyk1CAYag== X-Received: by 10.36.64.73 with SMTP id n70mr1936126ita.53.1466482212123; Mon, 20 Jun 2016 21:10:12 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.79.102.5 with HTTP; Mon, 20 Jun 2016 21:10:11 -0700 (PDT) In-Reply-To: <576891F8.1010200@gmail.com> References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com> <31205295.d0H0JTrSWj@ralph.baldwin.cx> <576891F8.1010200@gmail.com> From: Kevin Oberman Date: Mon, 20 Jun 2016 21:10:11 -0700 X-Google-Sender-Auth: 0IvXrsytdUkuyrbPDtB7Q9gjngA Message-ID: Subject: Re: console in 11.0-ALPHA4 To: Ernie Luzar Cc: John Baldwin , Ed Maste , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 04:10:13 -0000 On Mon, Jun 20, 2016 at 6:01 PM, Ernie Luzar wrote: > John Baldwin wrote: > >> On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote: >> >>> Ed Maste wrote: >>> >>>> On 20 June 2016 at 14:29, Ernie Luzar wrote: >>>> >>>>> I found the cause of this boot time message >>>>> "vicontrol: setting cursor type: Inappropriate ioctl for device" >>>>> >>>>> In my rc.conf I had this statement >>>>> vidcontrol -c blink -h 250 >>>>> From testing it seems that vt does not handle the "blink" option for >>>>> causing >>>>> the cursor to blink. Is there a vt option to enable cursor blinking >>>>> >>>> I've submitted two PRs for the issues you reported here: >>>> Bug 210413 - vidcontrol -c does not work >>>> with vt(4) >>>> Bug 210415 - vidcontrol -h does not work with vt(4) >>>> (edit) >>>> >>>> There is currently no option to enable cursor blinking. >>>> >>> >>> Further testing shows that: >>> >>> 1. The rc.conf option screen saver "saver= " and the "blanktime= " >>> options work in vt for both text and graph modes. >>> >>> 2. The cursor copy/paste does not work in vt text mode. It only works in >>> vt graph mode. vt needs to be fixed so copy/paste function also works in >>> text mode. >>> >>> 3. Boot time splash screen does not work in vt at all no matter which >>> mode is enabled. Using this in loader.conf >>> splash_bmp_load="YES" >>> bitmap_name="/boot/splash.bmp" >>> bitload_load="YES" >>> >>> This works in 10.x. The splash screen function can not be allowed to be >>> removed from the base system just because vt can not handle it. This also >>> means any vt changes need to updated in the handbook section on splash >>> screen. >>> >>> In conclusion, vt is not ready to replace the sc console driver yet. vt >>> needs to be fixed before becoming the default in 11.0. Using vt as the >>> default console driver effects every user. It completely changes the >>> FreeBSD experience. It's detrimental to the public relations and the >>> professional image of FreeBSD to publish the 11.0-RELEASE using vt in its >>> current condition. If time doesn't permit to get these vt things fixed >>> before publishing 11.0 then vt should not become the default console driver. >>> >> >> OTOH, if you use EFI, then you can't use sc(4). You get no working >> console >> with EFI (which is becoming more popular) if you use sc(4). You also do >> not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable >> console if you use sc(4). You also do not have a working console after >> loading the KMS drivers (either by starting X or via explicit kldload) >> when >> using sc(4). This affects just about every modern Intel system using an >> Intel GPU (so more widespread than EFI even). >> >> There are trade offs in both directions. Neither console is a subset of >> the >> other. However, sc(4) is not really expendable to support the things it >> is >> missing. vt(4) is actively worked on, and patches for the features it >> lacks >> that you need are certainly welcomed. >> >> > This sounds like a integration design error. From your description of the > hardware that vt is designed for and sc is designed for indicates the need > for some code to be added to the boot process that inspects the hardware > and decides whether vt or sc is to be launched. Or maybe bsdinstall should > inspect the hardware and give the installer the option to select what > console is best for his hardware. Just forcing this version of vt that > lacks long time functions as the default console driver is not the > professional way to handle such conflicts. > > I am at a lost to understand how any development administrator would > approve making vt the default console driver in light of the standard > functions missing from it. And furthermore what kind of vt testing was done > that these problems were missed. Any one of these problems is enough cause > to reverse the decision to make vt the default console driver for 11.0. > This would give time for these problems to be address and correctly tested > and when ready then be paced in some other 11.x release. There is really no choice. vt(4) will work as a basic console on all platforms. sc(4) works on old hardware, but not on an increasingly large portion of "modern" hardware. Since being able to boot on most hardware is critical as well as supporting non-CP437 languages. It' pretty much a no-brainer. And, since switching back to SC(4) is trivial (add "kern.vty=sc" to /boot/loader.conf), I believe any other option would be totally unacceptable. It is important that the release notes for 11 clarify these changes and make it clear how to switch. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Tue Jun 21 05:11:28 2016 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 A3214AC430A for ; Tue, 21 Jun 2016 05:11:28 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 8889318E3 for ; Tue, 21 Jun 2016 05:11:27 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u5L5Biin079033 for ; Mon, 20 Jun 2016 22:11:52 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <31205295.d0H0JTrSWj@ralph.baldwin.cx> References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com>, <31205295.d0H0JTrSWj@ralph.baldwin.cx> From: "Chris H" Subject: Re: console in 11.0-ALPHA4 Date: Mon, 20 Jun 2016 22:11:52 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-Milter: Spamilter (Reciever: udns.ultimatedns.net; Sender-ip: 127.0.0.1; Sender-helo: ultimatedns.net; ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 05:11:28 -0000 On Mon, 20 Jun 2016 16:22:53 -0700 John Baldwin wrote > On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote: > > Ed Maste wrote: > > > On 20 June 2016 at 14:29, Ernie Luzar wrote: > > >> I found the cause of this boot time message > > >> "vicontrol: setting cursor type: Inappropriate ioctl for device" > > >> > > >> In my rc.conf I had this statement > > >> vidcontrol -c blink -h 250 > > >> From testing it seems that vt does not handle the "blink" option for > > >> causing the cursor to blink. Is there a vt option to enable cursor > > >> blinking > > > > > I've submitted two PRs for the issues you reported here: > > > Bug 210413 - vidcontrol -c does not work with > > > vt(4) Bug 210415 - vidcontrol -h does not work with vt(4) > > > (edit) > > > There is currently no option to enable cursor blinking. > > > > > > Further testing shows that: > > > > 1. The rc.conf option screen saver "saver= " and the "blanktime= " > > options work in vt for both text and graph modes. > > > > 2. The cursor copy/paste does not work in vt text mode. It only works in > > vt graph mode. vt needs to be fixed so copy/paste function also works in > > text mode. > > > > 3. Boot time splash screen does not work in vt at all no matter which > > mode is enabled. Using this in loader.conf > > splash_bmp_load="YES" > > bitmap_name="/boot/splash.bmp" > > bitload_load="YES" > > > > This works in 10.x. The splash screen function can not be allowed to be > > removed from the base system just because vt can not handle it. This > > also means any vt changes need to updated in the handbook section on > > splash screen. > > > > In conclusion, vt is not ready to replace the sc console driver yet. vt > > needs to be fixed before becoming the default in 11.0. Using vt as the > > default console driver effects every user. It completely changes the > > FreeBSD experience. It's detrimental to the public relations and the > > professional image of FreeBSD to publish the 11.0-RELEASE using vt in > > its current condition. If time doesn't permit to get these vt things > > fixed before publishing 11.0 then vt should not become the default > > console driver. > > OTOH, if you use EFI, then you can't use sc(4). You get no working console > with EFI (which is becoming more popular) if you use sc(4). You also do > not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable > console if you use sc(4). You also do not have a working console after > loading the KMS drivers (either by starting X or via explicit kldload) when > using sc(4). This affects just about every modern Intel system using an > Intel GPU (so more widespread than EFI even). > > There are tradeoffs in both directions. Neither console is a subset of the > other. However, sc(4) is not really extendable to support the things it is > missing. vt(4) is actively worked on, and patches for the features it lacks > that you need are certainly welcomed. AMD, and ATI are also quite popular, as well as nVidia. In the case of nVidia, vt(4) is nearly as good as sc(4) on/in [U]EFI. I think the [original] point here was; for all that vt(4) intends to provide, it's just not ready for prime time, and as such, shouldn't be made default, just yet. :-) --Chris > > -- > John Baldwin From owner-freebsd-current@freebsd.org Tue Jun 21 05:26:45 2016 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 C3BBEAC4976 for ; Tue, 21 Jun 2016 05:26:45 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 8E371252D for ; Tue, 21 Jun 2016 05:26:45 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ob0-x231.google.com with SMTP id ru5so7393375obc.1 for ; Mon, 20 Jun 2016 22:26:45 -0700 (PDT) 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; bh=JJpOan/XGdHYdD65bHy7liwkkeNhxPMaTldJ1MYty2U=; b=u0D8hS9IbulzUdyhDboKzZFZsnE3LmvjTf0FdXZmFkGJawqzPFBX+vz3SZNhPzoLCb 0uOjpDV31kUXD+JKaIBazSB77HQq4jXg/KFzhNhd0T9rn0rLC6fVKUIvUzNLmZUkLS/J hOqJJ3HFnC5MZh47WycS5sUynTWBLJFrVU92lxN5mOcvKt9kvljvWjGgXOWHi2Qlr5ov dhI/aqv0B+1YvD8vIC4ZHrRb45Z2sc0hPe9+jcu9uvOqqhAf+dFDwfzcQZie/wi9T2yN HsUXwUt9FUqIrs1XcCXuhbFLnHETrJz/sUSoww3UitDUL1Ok7E4gUw3IsL8OtPRq7iXH q+Jw== 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; bh=JJpOan/XGdHYdD65bHy7liwkkeNhxPMaTldJ1MYty2U=; b=XqyaH/czCd2+6uV7Jvh7B6unIF/cglwt/rAeDIhEYY9Kvmv4P/W4fA2i1RRD7tBPqw yAbq7ZU0kAGyWtJwf1tvXw/ooROCLGtcbpLY42EUebHsgtP1wTR74vzRLi7bznCdhkY2 zC5EjutNddn6we7RYGayxF35bEXxhAVimfIFYWHL1sLnCpwmBFgEaF/ZfhYa51ioLTnH 0KmvmwVzvj+n8Qr2VTfn8qIlDg6Ux81XiBA91e69bKt3b1C7bXlbBdxSBM+ylXq/7p5K zN3fsY8/sbtiqgwyqAq2q/Fg2dLmsDbuBhsoD1/SYYKKwXswJ7Yg9oK37oEP8lIOnwnd VJ/A== X-Gm-Message-State: ALyK8tJuHcH9pR31PlcGspWoqUfnzrHcmvWe3DppbcJpfgz6ldZ9ShVwVOQWKDG3UlIucCM3Ky5XmJrU8ReRnegx MIME-Version: 1.0 X-Received: by 10.157.29.236 with SMTP id w41mr12537790otw.44.1466486804735; Mon, 20 Jun 2016 22:26:44 -0700 (PDT) Sender: sobomax@sippysoft.com Received: by 10.157.41.209 with HTTP; Mon, 20 Jun 2016 22:26:44 -0700 (PDT) Received: by 10.157.41.209 with HTTP; Mon, 20 Jun 2016 22:26:44 -0700 (PDT) In-Reply-To: References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com> <31205295.d0H0JTrSWj@ralph.baldwin.cx> Date: Mon, 20 Jun 2016 22:26:44 -0700 X-Google-Sender-Auth: vYDqbYeBaFuIi47SZxqoUyx7ExQ Message-ID: Subject: Re: console in 11.0-ALPHA4 From: Maxim Sobolev To: Chris H Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 05:26:45 -0000 For what it's worth: my two biggest grievances with the vt(4) vs. sc(4) is the unordered updates in the graphics mode which makes watching quickly scrolling text on something like virtual machine console funky and lack of support in the libvgl(3). The latter I find particularly hard to explain, since vt is supposed to be designed around graphics mode, so it should have easier to interface that to userland. People built apps around those interfaces, so unless we are going to replace libvgl with something else or depreciate it, we better support both console backends in there. -Max On Jun 20, 2016 10:11 PM, "Chris H" wrote: > On Mon, 20 Jun 2016 16:22:53 -0700 John Baldwin wrote > > > On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote: > > > Ed Maste wrote: > > > > On 20 June 2016 at 14:29, Ernie Luzar wrote: > > > >> I found the cause of this boot time message > > > >> "vicontrol: setting cursor type: Inappropriate ioctl for device" > > > >> > > > >> In my rc.conf I had this statement > > > >> vidcontrol -c blink -h 250 > > > >> From testing it seems that vt does not handle the "blink" option for > > > >> causing the cursor to blink. Is there a vt option to enable cursor > > > >> blinking > > > > > > I've submitted two PRs for the issues you reported here: > > > > Bug 210413 - vidcontrol -c does not work > with > > > > vt(4) Bug 210415 - vidcontrol -h does not work with > vt(4) > > > > (edit) > > > > There is currently no option to enable cursor blinking. > > > > > > > > > Further testing shows that: > > > > > > 1. The rc.conf option screen saver "saver= " and the "blanktime= " > > > options work in vt for both text and graph modes. > > > > > > 2. The cursor copy/paste does not work in vt text mode. It only works > in > > > vt graph mode. vt needs to be fixed so copy/paste function also works > in > > > text mode. > > > > > > 3. Boot time splash screen does not work in vt at all no matter which > > > mode is enabled. Using this in loader.conf > > > splash_bmp_load="YES" > > > bitmap_name="/boot/splash.bmp" > > > bitload_load="YES" > > > > > > This works in 10.x. The splash screen function can not be allowed to be > > > removed from the base system just because vt can not handle it. This > > > also means any vt changes need to updated in the handbook section on > > > splash screen. > > > > > > In conclusion, vt is not ready to replace the sc console driver yet. vt > > > needs to be fixed before becoming the default in 11.0. Using vt as the > > > default console driver effects every user. It completely changes the > > > FreeBSD experience. It's detrimental to the public relations and the > > > professional image of FreeBSD to publish the 11.0-RELEASE using vt in > > > its current condition. If time doesn't permit to get these vt things > > > fixed before publishing 11.0 then vt should not become the default > > > console driver. > > > > OTOH, if you use EFI, then you can't use sc(4). You get no working > console > > with EFI (which is becoming more popular) if you use sc(4). You also do > > not get non-ASCII characters with sc(4), so you don't have a UTF-8 > capable > > console if you use sc(4). You also do not have a working console after > > loading the KMS drivers (either by starting X or via explicit kldload) > when > > using sc(4). This affects just about every modern Intel system using an > > Intel GPU (so more widespread than EFI even). > > > > There are tradeoffs in both directions. Neither console is a subset of > the > > other. However, sc(4) is not really extendable to support the things it > is > > missing. vt(4) is actively worked on, and patches for the features it > lacks > > that you need are certainly welcomed. > AMD, and ATI are also quite popular, as well as nVidia. In the case of > nVidia, vt(4) is nearly as good as sc(4) on/in [U]EFI. > > I think the [original] point here was; for all that vt(4) intends to > provide, it's just not ready for prime time, and as such, shouldn't > be made default, just yet. :-) > > --Chris > > > > -- > > 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 Jun 21 06:28:22 2016 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 D2C73A7B578 for ; Tue, 21 Jun 2016 06:28:22 +0000 (UTC) (envelope-from raycherng@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 8E7E92236 for ; Tue, 21 Jun 2016 06:28:22 +0000 (UTC) (envelope-from raycherng@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id s63so3943709ioi.3 for ; Mon, 20 Jun 2016 23:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=A4Sbk6d9WyjmIIsKEarkMVXfKDLPONfdUJCgq08iFdw=; b=mOA8qXF6LKCI1pNJYhUxsijlzuKhQsQWMg0ulnU83N9zktZHUNtM5yAniWl4xI021r VwvDgP8qkxxdJFfxjJVVQdtKr9u7TYzQCBOmms5C7DGt3oHNOZxZ5x1dYDKGpuUldGzo jBKk2Vs0a+UrAG1OWBstA8z36ennQ71BEJ62XICGUlqM99pdLgC1x8TE3bQ9g+y2Qr5q cIZKq4TY9mxjWr5gk6mx2Ic4oHPKxG9bF+XcFpqkYvUZeUufI2azPmrZxbS1+voyo2px tsOuJt9gnAmX7ZeUYuTRJfBTIHb4fEsn0zLK8JRbbfPaqZ/8A4+1zzthnIdf/2vcHsZ5 j1vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=A4Sbk6d9WyjmIIsKEarkMVXfKDLPONfdUJCgq08iFdw=; b=g+US6M1yG3VkW5EevGddBElRRA8JPQMdvocUAsNB+6u6HsIppIorsMYkgtrabVdjUu q3phaJ9aUti76JNRVANMLaxqehyzQvDI47FkKdgz/f8VgFM4NY+7efn6miWJLLG/5fYX eFl9zinj5C0iLFceaUoMLj5JmH1oHNrjdd74nWntLNegr+L4ghOkGLBfrIoxeK5Scyt3 QqFY7ZDxDsrDAMi1+VKjHwSNylzbFmmzKkS7OTPysr7ohRBMOeCfVUQHrpJbeFyLwWBP 8o+jsZ/tMIDT92u8pnlFnKRutkmcQSthMdKPerrLhUfjeF3pIcN14TVrz1wqjEXpaaxU 23Eg== X-Gm-Message-State: ALyK8tLy8BJuYZ7Ljv3plOskZBWCQjTuC4VAsxh58XBy5RFcz/jZvT+T1F4UoGYYFUX67uyE6bMZf4+UAd1WgA== X-Received: by 10.107.137.95 with SMTP id l92mr28831735iod.177.1466490501990; Mon, 20 Jun 2016 23:28:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.19 with HTTP; Mon, 20 Jun 2016 23:28:21 -0700 (PDT) From: RayCherng Yu Date: Tue, 21 Jun 2016 14:28:21 +0800 Message-ID: Subject: pkg install error in FreeBSD-11.0-ALPHA4 To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 06:28:22 -0000 After clean install, I pkg install these packages: vim, irssi, tmux, zh-auto-tw-l10n, docproj, sudo, asciidoc, source-highlight, intel-backlight http://imgur.com/kZbfTS5 During install process, I got "Cannot solve problem using SAT solver, trying another plan" http://imgur.com/nMnwumv Finally, I get this error message: http://imgur.com/CKK9LUy Then I pkg install these packages separately (pkg install half of them 2 times). It works without error messages. My laptop is Macbook Pro 13 2011 early. It also occurs on my Lenovo Thinkpad W550s. --=20 "Life is like a snowball. The important thing is finding wet snow and a really long hill." "Price is what you pay. Value is what you get." "The first rule of Investing is don't lose money; the second rule is don't forget rule #1..." "Wall Street is the only place that people ride to work in a Rolls-Royce to get advice from those who take the subway..." =E2=80=94 Warren Buffett. =E4=B8=8D=E5=90=AB=E7=97=85=E6=AF=92=E3=80=82www.avast.com <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> From owner-freebsd-current@freebsd.org Tue Jun 21 08:14:26 2016 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 D0DB4AC4012 for ; Tue, 21 Jun 2016 08:14:26 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 8EB131B01 for ; Tue, 21 Jun 2016 08:14:26 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bFGp7-002ubI-7l>; Tue, 21 Jun 2016 10:14:17 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bFGp6-00204x-Qu>; Tue, 21 Jun 2016 10:14:17 +0200 Date: Tue, 21 Jun 2016 10:14:07 +0200 From: "O. Hartmann" To: "Chris H" Cc: Subject: Re: console in 11.0-ALPHA4 Message-ID: <20160621101407.56ca3fc0@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com> <31205295.d0H0JTrSWj@ralph.baldwin.cx> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 08:14:26 -0000 On Mon, 20 Jun 2016 22:11:52 -0700 "Chris H" wrote: > On Mon, 20 Jun 2016 16:22:53 -0700 John Baldwin wrote > > > On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote: > > > Ed Maste wrote: > > > > On 20 June 2016 at 14:29, Ernie Luzar wrote: > > > >> I found the cause of this boot time message > > > >> "vicontrol: setting cursor type: Inappropriate ioctl for device" > > > >> > > > >> In my rc.conf I had this statement > > > >> vidcontrol -c blink -h 250 > > > >> From testing it seems that vt does not handle the "blink" option for > > > >> causing the cursor to blink. Is there a vt option to enable cursor > > > >> blinking > > > > > > I've submitted two PRs for the issues you reported here: > > > > Bug 210413 - vidcontrol -c does not work with > > > > vt(4) Bug 210415 - vidcontrol -h does not work with vt(4) > > > > (edit) > > > > There is currently no option to enable cursor blinking. > > > > > > > > > Further testing shows that: > > > > > > 1. The rc.conf option screen saver "saver= " and the "blanktime= " > > > options work in vt for both text and graph modes. > > > > > > 2. The cursor copy/paste does not work in vt text mode. It only works in > > > vt graph mode. vt needs to be fixed so copy/paste function also works in > > > text mode. > > > > > > 3. Boot time splash screen does not work in vt at all no matter which > > > mode is enabled. Using this in loader.conf > > > splash_bmp_load="YES" > > > bitmap_name="/boot/splash.bmp" > > > bitload_load="YES" > > > > > > This works in 10.x. The splash screen function can not be allowed to be > > > removed from the base system just because vt can not handle it. This > > > also means any vt changes need to updated in the handbook section on > > > splash screen. > > > > > > In conclusion, vt is not ready to replace the sc console driver yet. vt > > > needs to be fixed before becoming the default in 11.0. Using vt as the > > > default console driver effects every user. It completely changes the > > > FreeBSD experience. It's detrimental to the public relations and the > > > professional image of FreeBSD to publish the 11.0-RELEASE using vt in > > > its current condition. If time doesn't permit to get these vt things > > > fixed before publishing 11.0 then vt should not become the default > > > console driver. > > > > OTOH, if you use EFI, then you can't use sc(4). You get no working console > > with EFI (which is becoming more popular) if you use sc(4). You also do > > not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable > > console if you use sc(4). You also do not have a working console after > > loading the KMS drivers (either by starting X or via explicit kldload) when > > using sc(4). This affects just about every modern Intel system using an > > Intel GPU (so more widespread than EFI even). > > > > There are tradeoffs in both directions. Neither console is a subset of the > > other. However, sc(4) is not really extendable to support the things it is > > missing. vt(4) is actively worked on, and patches for the features it lacks > > that you need are certainly welcomed. > AMD, and ATI are also quite popular, as well as nVidia. In the case of > nVidia, vt(4) is nearly as good as sc(4) on/in [U]EFI. most recent nVidia BLOBs (starting with the separation of the kernel module in nvidia-modset.ko and nvidia.ko kernel object modules) do not work properly nor with sc(4), neither vt(4) on most recent CURRENT! See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201340 With non-UEFI, die console is unusable due to some weird 1980s blocky-coloured signs in 80x25 col/rows, with UEFI there is simply black screen when switching to console - this is the fact as long the nvidia-modeset.ko is loaded. After unloading, the problems disappear. And by the way: at the moment nVidia's offering of a BLOB is the only, and THE only way to provide acceptable support and performnce for recent and modern GPUs. Since many people or those making decissions are not inclined to purchase "old" but working stuff for a perspective of 3-5 years, a working console seemes to me to be important. > > I think the [original] point here was; for all that vt(4) intends to > provide, it's just not ready for prime time, and as such, shouldn't > be made default, just yet. :-) > > --Chris > > > > -- > > 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 Jun 21 08:55:21 2016 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 1D267AC520F for ; Tue, 21 Jun 2016 08:55:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 D719F13BE for ; Tue, 21 Jun 2016 08:55:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1713 invoked from network); 21 Jun 2016 08:55:49 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 21 Jun 2016 08:55:49 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 21 Jun 2016 04:55:09 -0400 (EDT) Received: (qmail 24229 invoked from network); 21 Jun 2016 08:55:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jun 2016 08:55:09 -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.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id A9FED1C407A; Tue, 21 Jun 2016 01:55:11 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] Message-Id: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> Date: Tue, 21 Jun 2016 01:55:11 -0700 To: otacilio.neto@bsd.com.br, freebsd-arm , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 08:55:21 -0000 Otac=C3=ADlio otacilio.neto at bsd.com.br wrote on Tue Jun 21 00:06:39 = UTC 2016 : > > The kernel panic is totally reproducible. I need only do a ssh in = the > > beaglebone using ptty on windows or ssh on freebsd and the kernel=20 > > panic is raised. . . . > FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need = to=20 > raise the fault is ssh in the beaglebone. (After this quotes are command input/output from my test activity.) Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . . > # uname -apKU > FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun 16 = 18:12:02 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = armv6 1100117 1100117 This is a no-debug kernel build (but with symbols). Details are given = later below. > # ssh markmi@192.168.0.105 > Password: > Last login: Tue Jun 21 01:04:46 2016 > markmi$=20 Similarly I can ssh into the rpi2 from outside, here using new remote = connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . . > Password for markmi@rpi2: > Last login: Mon May 9 19:27:33 2016 from 192.168.2.1 > FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT = 2016 >=20 > Welcome to FreeBSD! >=20 > Release Notes, Errata: https://www.FreeBSD.org/releases/ > Security Advisories: https://www.FreeBSD.org/security/ > FreeBSD Handbook: https://www.FreeBSD.org/handbook/ > FreeBSD FAQ: https://www.FreeBSD.org/faq/ > Questions List: = https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ > FreeBSD Forums: https://forums.FreeBSD.org/ >=20 > Documents installed with the system are in the = /usr/local/share/doc/freebsd/ > directory, or can be installed later with: pkg install en-freebsd-doc > For other languages, replace "en" with a language code like de or fr. >=20 > Show the version of FreeBSD installed: freebsd-version ; uname -a > Please include that output and any error messages when posting = questions. > Introduction to manual pages: man man > FreeBSD directory layout: man hier >=20 > Edit /etc/motd to change this login announcement. > To determine whether a file is a text file, executable, or some other = type > of file, use >=20 > file filename > -- Dru > $=20 No panics or other odd notices. The problem is apparently not general to all armv6 contexts. Various context details follow. . . > # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host=20 > TO_TYPE=3Darmv6 > # > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > #WITH_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > # > #CPUTYPE=3Dsoft > WITH_LIBSOFT=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > #WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > # There is no XCPPFLAGS but XCPP ets XCFLAGS content. ~/src.configs/make.conf was empty. > # more /usr/src/sys/arm/conf/RPI2-NODBG > # > # RPI2 -- Custom configuration for the Raspberry Pi 2 > # > # For more information on this file, please read the config(5) manual = page, > # and/or the handbook section on Kernel Configuration Files: > # > # = http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-con= fig.html > # > # The handbook is also available locally in /usr/share/doc/handbook > # if you've installed the doc distribution, otherwise always see the > # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the > # latest information. > # > # An exhaustive list of options and more detailed explanations of the > # device lines is also present in the ../../conf/NOTES and NOTES = files. > # If you are in doubt as to the purpose or necessity of a line, check = first > # in NOTES. > # > =20 > ident RPI2-NODBG > =20 > include "RPI2" > =20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols > options ALT_BREAK_TO_DEBUGGER > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages > =20 > options KDB # Enable kernel debugger = support > =20 > # For minimum debugger support (stable branch) use: > #options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger > =20 > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC My /usr/src tree has some changes/additions --but mostly for powerpc64 = and powerpc issues: > # svnlite status /usr/src/ > M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp > M /usr/src/lib/csu/powerpc64/Makefile > ? /usr/src/sys/amd64/include/include > ? /usr/src/sys/arm/conf/RPI2-NODBG > ? /usr/src/sys/arm/include/include > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/Makefile.powerpc > M /usr/src/sys/conf/kern.mk > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c > M /usr/src/sys/dev/cxgbe/tom/t4_listen.c > ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > ? /usr/src/sys/powerpc/include/include > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/exec_machdep.c > ? /usr/src/sys/x86/include/include (The include/include ones are from something making links pointing back = up to the parent include/ . I did not explicitly create these.) (The cxbg and cxbge ones were from trying to have amd64 target amd64 via = xtoolchain (devel/amd64-gcc). But other places also stopped it and I = quit trying that for now.) > # more /etc/rc.conf > hostname=3D"rpi2" > ifconfig_ue0=3D"DHCP" > sshd_enable=3D"YES" > =20 > powerd_enable=3D"YES" > =20 > # Nice if you have a network, else annoying. > ntpd_enable=3D"YES" > ntpd_sync_on_start=3D"YES" > =20 > # Uncomment to disable common services (more memory) > #cron_enable=3D"NO" > #syslogd_enable=3D"NO" > sendmail_enable=3D"NONE" > sendmail_submit_enable=3D"NO" > sendmail_outbound_enable=3D"NO" > sendmail_msp_queue_enable=3D"NO" > # > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev=3D"AUTO" > # > dbus_enable=3D"YES" > hald_enable=3D"YES" > # > rpcbind_enable=3D"YES" > nfs_server_enable=3D"YES" > mountd_flags=3D"-r" > # > nfs_client_enable=3D"YES" > # more /etc/sysctl.conf=20 > # $FreeBSD: head/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ > # > # This file is read when going to multi-user and its contents piped = thru > # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for = details. > # > =20 > # Uncomment this to prevent users from seeing information about = processes that > # are being run under another UID. > #security.bsd.see_other_uids=3D0 > =20 > kern.nodump_coredump=3D1 > kern.capmode_coredump=3D1 > kern.sugid_coredump=3D1 > kern.corefile=3D/var/crash/%N.%P.core /etc/fstab , /etc/exports , /etc/resolv.conf are very simple but = non-default. Other than password files and the like the rest of /etc/. . = . is just defaults. > # more /boot/loader.conf=20 > kern.cam.boot_delay=3D"10000" =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Jun 21 10:34:06 2016 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 A0D11A7ADC6; Tue, 21 Jun 2016 10:34:06 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "courriel.site.uottawa.ca", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DA9F2701; Tue, 21 Jun 2016 10:34:05 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from [10.0.2.15] (ppp-66-186-88-176.vianet.ca [66.186.88.176]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id u5LAXxOv038927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jun 2016 06:34:00 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Tue, 21 Jun 2016 06:33:58 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Mark Millard cc: otacilio.neto@bsd.com.br, freebsd-arm , FreeBSD Current Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] In-Reply-To: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> Message-ID: References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 10:34:06 -0000 On Tue, 21 Jun 2016, Mark Millard wrote: > Otacílio otacilio.neto at bsd.com.br wrote on Tue Jun 21 00:06:39 UTC 2016 : > >> > The kernel panic is totally reproducible. I need only do a ssh in the >> > beaglebone using ptty on windows or ssh on freebsd and the kernel >> > panic is raised. > . . . >> FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need to >> raise the fault is ssh in the beaglebone. > > (After this quotes are command input/output from my test activity.) > > Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . . > >> # uname -apKU >> FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun 16 18:12:02 PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm armv6 1100117 1100117 > > > This is a no-debug kernel build (but with symbols). Details are given later below. > >> # ssh markmi@192.168.0.105 >> Password: >> Last login: Tue Jun 21 01:04:46 2016 >> markmi$ > > Similarly I can ssh into the rpi2 from outside, here using new remote connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . . > >> Password for markmi@rpi2: >> Last login: Mon May 9 19:27:33 2016 from 192.168.2.1 >> FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT 2016 >> >> Welcome to FreeBSD! >> >> Release Notes, Errata: https://www.FreeBSD.org/releases/ >> Security Advisories: https://www.FreeBSD.org/security/ >> FreeBSD Handbook: https://www.FreeBSD.org/handbook/ >> FreeBSD FAQ: https://www.FreeBSD.org/faq/ >> Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ >> FreeBSD Forums: https://forums.FreeBSD.org/ >> >> Documents installed with the system are in the /usr/local/share/doc/freebsd/ >> directory, or can be installed later with: pkg install en-freebsd-doc >> For other languages, replace "en" with a language code like de or fr. >> >> Show the version of FreeBSD installed: freebsd-version ; uname -a >> Please include that output and any error messages when posting questions. >> Introduction to manual pages: man man >> FreeBSD directory layout: man hier >> >> Edit /etc/motd to change this login announcement. >> To determine whether a file is a text file, executable, or some other type >> of file, use >> >> file filename >> -- Dru >> $ > > No panics or other odd notices. > > The problem is apparently not general to all armv6 contexts. > > Various context details follow. . . > >> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host >> TO_TYPE=armv6 >> # >> KERNCONF=RPI2-NODBG >> TARGET=arm >> .if ${.MAKE.LEVEL} == 0 >> TARGET_ARCH=${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> #WITH_CROSS_COMPILER= >> WITH_SYSTEM_COMPILER= >> # >> #CPUTYPE=soft >> WITH_LIBSOFT= >> WITH_LIBCPLUSPLUS= >> WITH_BINUTILS_BOOTSTRAP= >> #WITHOUT_CLANG_BOOTSTRAP= >> WITH_CLANG= >> WITH_CLANG_IS_CC= >> WITH_CLANG_FULL= >> WITH_CLANG_EXTRAS= >> WITH_LLDB= >> # >> WITH_BOOT= >> WITHOUT_LIB32= >> # >> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP= >> WITHOUT_GCC_BOOTSTRAP= >> WITHOUT_GCC= >> WITHOUT_GCC_IS_CC= >> WITHOUT_GNUCXX= >> # >> NO_WERROR= >> #WERROR= >> MALLOC_PRODUCTION= >> # >> WITH_DEBUG_FILES= >> # >> XCFLAGS+= -march=armv7-a -mcpu=cortex-a7 >> XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7 >> # There is no XCPPFLAGS but XCPP ets XCFLAGS content. > > ~/src.configs/make.conf was empty. > >> # more /usr/src/sys/arm/conf/RPI2-NODBG >> # >> # RPI2 -- Custom configuration for the Raspberry Pi 2 >> # >> # For more information on this file, please read the config(5) manual page, >> # and/or the handbook section on Kernel Configuration Files: >> # >> # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html >> # >> # The handbook is also available locally in /usr/share/doc/handbook >> # if you've installed the doc distribution, otherwise always see the >> # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the >> # latest information. >> # >> # An exhaustive list of options and more detailed explanations of the >> # device lines is also present in the ../../conf/NOTES and NOTES files. >> # If you are in doubt as to the purpose or necessity of a line, check first >> # in NOTES. >> # >> >> ident RPI2-NODBG >> >> include "RPI2" >> >> makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols >> options ALT_BREAK_TO_DEBUGGER >> #options VERBOSE_SYSINIT # Enable verbose sysinit messages >> >> options KDB # Enable kernel debugger support >> >> # For minimum debugger support (stable branch) use: >> #options KDB_TRACE # Print a stack trace for a panic >> options DDB # Enable the kernel debugger >> >> nooptions INVARIANTS # Enable calls of extra sanity checking >> nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS >> nooptions WITNESS # Enable checks to detect deadlocks and cycles >> nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed >> nooptions DIAGNOSTIC > > > My /usr/src tree has some changes/additions --but mostly for powerpc64 and powerpc issues: > >> # svnlite status /usr/src/ >> M /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >> M /usr/src/lib/csu/powerpc64/Makefile >> ? /usr/src/sys/amd64/include/include >> ? /usr/src/sys/arm/conf/RPI2-NODBG >> ? /usr/src/sys/arm/include/include >> M /usr/src/sys/boot/ofw/Makefile.inc >> M /usr/src/sys/boot/powerpc/Makefile >> M /usr/src/sys/boot/powerpc/Makefile.inc >> M /usr/src/sys/boot/uboot/Makefile.inc >> M /usr/src/sys/conf/Makefile.powerpc >> M /usr/src/sys/conf/kern.mk >> M /usr/src/sys/conf/kmod.mk >> M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c >> M /usr/src/sys/dev/cxgbe/tom/t4_listen.c >> ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >> ? /usr/src/sys/powerpc/include/include >> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >> M /usr/src/sys/powerpc/powerpc/exec_machdep.c >> ? /usr/src/sys/x86/include/include > > (The include/include ones are from something making links pointing back up to the parent include/ . I did not explicitly create these.) > > (The cxbg and cxbge ones were from trying to have amd64 target amd64 via xtoolchain (devel/amd64-gcc). But other places also stopped it and I quit trying that for now.) > >> # more /etc/rc.conf >> hostname="rpi2" >> ifconfig_ue0="DHCP" >> sshd_enable="YES" >> >> powerd_enable="YES" >> >> # Nice if you have a network, else annoying. >> ntpd_enable="YES" >> ntpd_sync_on_start="YES" >> >> # Uncomment to disable common services (more memory) >> #cron_enable="NO" >> #syslogd_enable="NO" >> sendmail_enable="NONE" >> sendmail_submit_enable="NO" >> sendmail_outbound_enable="NO" >> sendmail_msp_queue_enable="NO" >> # >> # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable >> dumpdev="AUTO" >> # >> dbus_enable="YES" >> hald_enable="YES" >> # >> rpcbind_enable="YES" >> nfs_server_enable="YES" >> mountd_flags="-r" >> # >> nfs_client_enable="YES" > >> # more /etc/sysctl.conf >> # $FreeBSD: head/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ >> # >> # This file is read when going to multi-user and its contents piped thru >> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. >> # >> >> # Uncomment this to prevent users from seeing information about processes that >> # are being run under another UID. >> #security.bsd.see_other_uids=0 >> >> kern.nodump_coredump=1 >> kern.capmode_coredump=1 >> kern.sugid_coredump=1 >> kern.corefile=/var/crash/%N.%P.core > > > /etc/fstab , /etc/exports , /etc/resolv.conf are very simple but non-default. Other than password files and the like the rest of /etc/. . . is just defaults. > >> # more /boot/loader.conf >> kern.cam.boot_delay="10000" > > > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" I'm using an RPI-B rather than RPI2, but my symptoms are similar. Did you use the wired or wireless interface on the RPI2? I only get the panic on the RPI-B when using wireless. Wired works fine. In an earlier message Ian said that he thought he knew what the problem was... ...keith From owner-freebsd-current@freebsd.org Tue Jun 21 11:11:31 2016 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 9388CAC4760 for ; Tue, 21 Jun 2016 11:11:31 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 53B9F1A39 for ; Tue, 21 Jun 2016 11:11:31 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x235.google.com with SMTP id p10so15259803qke.3 for ; Tue, 21 Jun 2016 04:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=7+yyYS0H/RCGAjBzJ/j/Cwrd6JwfVwpcLdMnm+8zR/I=; b=EXi5mPXVEplIo6Yz28vEYT1sh6mDhtDN73ZT8IQKKnans/HLAlERzin/2j2Qea+POg AgBzO+8YuN5IwzhkO1c+B8VLwLDo/iM04JVhWt1XmPyKwwW20tyGCS930b+/RJBPhc16 wfX52s/b6LKssSGVaDsuhmFp9Udq9/UlZPAXA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7+yyYS0H/RCGAjBzJ/j/Cwrd6JwfVwpcLdMnm+8zR/I=; b=knuaFEhg0YmqIP0qkjt31Z6PPXBvpRnbIA+Wme39rzCOAmP8ooKrWsrMP2+u8Ig9CU njp+cFldDuInmZM0bbSE4f2B0qdilFXqfvHA7u8YBAMgNMA2Lj4gOF2ZEhfmSh8AEarB tgZLofdIyx3PgUdHxXWs8kaztJEt6w3Hp/x012qGXEqbD5XqvM5rObKgLEaE23wV7VxF TFiWTMdkafEKNkIB5qThdnMDlDaTVZwFNVZC+vJTYjBM2JfbWscOgrL+YamqtzCxAEhz BeAExTMVmjgiubg/wXcF4+oBhfpWQ4p+Xz5VYsNhkxZRLsKq67xEax6R52NejhLO9qN8 DhgA== X-Gm-Message-State: ALyK8tLsxNLuk5zZwiZorljpHWsFnskZTonn3rPXWkgvtCHiIkyGOsl+iW9TPCgB+BMgag== X-Received: by 10.200.37.150 with SMTP id e22mr28331867qte.37.1466507490246; Tue, 21 Jun 2016 04:11:30 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id j62sm9981934qtb.35.2016.06.21.04.11.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 04:11:29 -0700 (PDT) Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] To: Keith White , Mark Millard References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> Cc: freebsd-arm , FreeBSD Current From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <22fe5f7f-6153-e092-c410-eddb1431a78a@bsd.com.br> Date: Tue, 21 Jun 2016 08:11:07 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 11:11:31 -0000 Em 21/06/2016 07:33, Keith White escreveu: > In an earlier message Ian said that he thought he knew what the > problem was... Here the problem occurs when using wifi. I do not have tested wired because I don't have a cable here. []'s -Otacilio From owner-freebsd-current@freebsd.org Tue Jun 21 11:14:20 2016 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 55868AC49E9 for ; Tue, 21 Jun 2016 11:14:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 1958B1DD7 for ; Tue, 21 Jun 2016 11:14:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13133 invoked from network); 21 Jun 2016 11:14:14 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 21 Jun 2016 11:14:14 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 21 Jun 2016 07:14:18 -0400 (EDT) Received: (qmail 22047 invoked from network); 21 Jun 2016 11:14:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jun 2016 11:14:18 -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.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id C906C1C407A; Tue, 21 Jun 2016 04:14:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] From: Mark Millard In-Reply-To: Date: Tue, 21 Jun 2016 04:14:11 -0700 Cc: otacilio.neto@bsd.com.br, freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> To: Keith White X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 11:14:20 -0000 On 2016-Jun-21, at 3:33 AM, Keith White = wrote: > On Tue, 21 Jun 2016, Mark Millard wrote: >=20 >> Otac=C3=ADlio otacilio.neto at bsd.com.br wrote on Tue Jun 21 = 00:06:39 UTC 2016 : >>=20 >>> > The kernel panic is totally reproducible. I need only do a ssh in = the >>> > beaglebone using ptty on windows or ssh on freebsd and the kernel = > panic is raised. >> . . . >>> FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need = to raise the fault is ssh in the beaglebone. >>=20 >> (After this quotes are command input/output from my test activity.) >>=20 >> Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . = . >>=20 >>> # uname -apKU >>> FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun 16 = 18:12:02 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = armv6 1100117 1100117 >>=20 >>=20 >> This is a no-debug kernel build (but with symbols). Details are given = later below. >>=20 >>> # ssh markmi@192.168.0.105 >>> Password: >>> Last login: Tue Jun 21 01:04:46 2016 >>> markmi$=20 >>=20 >> Similarly I can ssh into the rpi2 from outside, here using new remote = connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . . >>=20 >>> Password for markmi@rpi2: >>> Last login: Mon May 9 19:27:33 2016 from 192.168.2.1 >>> FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 = PDT 2016 >>> Welcome to FreeBSD! >>> Release Notes, Errata: https://www.FreeBSD.org/releases/ >>> Security Advisories: https://www.FreeBSD.org/security/ >>> FreeBSD Handbook: https://www.FreeBSD.org/handbook/ >>> FreeBSD FAQ: https://www.FreeBSD.org/faq/ >>> Questions List: = https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ >>> FreeBSD Forums: https://forums.FreeBSD.org/ >>> Documents installed with the system are in the = /usr/local/share/doc/freebsd/ >>> directory, or can be installed later with: pkg install = en-freebsd-doc >>> For other languages, replace "en" with a language code like de or = fr. >>> Show the version of FreeBSD installed: freebsd-version ; uname -a >>> Please include that output and any error messages when posting = questions. >>> Introduction to manual pages: man man >>> FreeBSD directory layout: man hier >>> Edit /etc/motd to change this login announcement. >>> To determine whether a file is a text file, executable, or some = other type >>> of file, use >>>=20 >>> file filename >>> -- Dru >>> $=20 >>=20 >> No panics or other odd notices. >>=20 >> The problem is apparently not general to all armv6 contexts. >>=20 >> Various context details follow. . . >>=20 >>> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host = TO_TYPE=3Darmv6 >>> # >>> KERNCONF=3DRPI2-NODBG >>> TARGET=3Darm >>> .if ${.MAKE.LEVEL} =3D=3D 0 >>> TARGET_ARCH=3D${TO_TYPE} >>> .export TARGET_ARCH >>> .endif >>> # >>> #WITH_CROSS_COMPILER=3D >>> WITH_SYSTEM_COMPILER=3D >>> # >>> #CPUTYPE=3Dsoft >>> WITH_LIBSOFT=3D >>> WITH_LIBCPLUSPLUS=3D >>> WITH_BINUTILS_BOOTSTRAP=3D >>> #WITHOUT_CLANG_BOOTSTRAP=3D >>> WITH_CLANG=3D >>> WITH_CLANG_IS_CC=3D >>> WITH_CLANG_FULL=3D >>> WITH_CLANG_EXTRAS=3D >>> WITH_LLDB=3D >>> # >>> WITH_BOOT=3D >>> WITHOUT_LIB32=3D >>> # >>> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >>> WITHOUT_GCC_BOOTSTRAP=3D >>> WITHOUT_GCC=3D >>> WITHOUT_GCC_IS_CC=3D >>> WITHOUT_GNUCXX=3D >>> # >>> NO_WERROR=3D >>> #WERROR=3D >>> MALLOC_PRODUCTION=3D >>> # >>> WITH_DEBUG_FILES=3D >>> # >>> XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>> XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>> # There is no XCPPFLAGS but XCPP ets XCFLAGS content. >>=20 >> ~/src.configs/make.conf was empty. >>=20 >>> # more /usr/src/sys/arm/conf/RPI2-NODBG >>> # >>> # RPI2 -- Custom configuration for the Raspberry Pi 2 >>> # >>> # For more information on this file, please read the config(5) = manual page, >>> # and/or the handbook section on Kernel Configuration Files: >>> # >>> # = http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-con= fig.html >>> # >>> # The handbook is also available locally in /usr/share/doc/handbook >>> # if you've installed the doc distribution, otherwise always see the >>> # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the >>> # latest information. >>> # >>> # An exhaustive list of options and more detailed explanations of = the >>> # device lines is also present in the ../../conf/NOTES and NOTES = files. >>> # If you are in doubt as to the purpose or necessity of a line, = check first >>> # in NOTES. >>> # >>> ident RPI2-NODBG >>> include "RPI2" >>> makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >>> options ALT_BREAK_TO_DEBUGGER >>> #options VERBOSE_SYSINIT # Enable verbose sysinit = messages >>> options KDB # Enable kernel debugger = support >>> # For minimum debugger support (stable branch) use: >>> #options KDB_TRACE # Print a stack trace for a = panic >>> options DDB # Enable the kernel debugger >>> nooptions INVARIANTS # Enable calls of extra = sanity checking >>> nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS >>> nooptions WITNESS # Enable checks to detect = deadlocks and cycles >>> nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed >>> nooptions DIAGNOSTIC >>=20 >>=20 >> My /usr/src tree has some changes/additions --but mostly for = powerpc64 and powerpc issues: >>=20 >>> # svnlite status /usr/src/ >>> M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>> M /usr/src/lib/csu/powerpc64/Makefile >>> ? /usr/src/sys/amd64/include/include >>> ? /usr/src/sys/arm/conf/RPI2-NODBG >>> ? /usr/src/sys/arm/include/include >>> M /usr/src/sys/boot/ofw/Makefile.inc >>> M /usr/src/sys/boot/powerpc/Makefile >>> M /usr/src/sys/boot/powerpc/Makefile.inc >>> M /usr/src/sys/boot/uboot/Makefile.inc >>> M /usr/src/sys/conf/Makefile.powerpc >>> M /usr/src/sys/conf/kern.mk >>> M /usr/src/sys/conf/kmod.mk >>> M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c >>> M /usr/src/sys/dev/cxgbe/tom/t4_listen.c >>> ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG >>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >>> ? /usr/src/sys/powerpc/conf/GENERICvtsc >>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >>> ? /usr/src/sys/powerpc/include/include >>> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >>> M /usr/src/sys/powerpc/powerpc/exec_machdep.c >>> ? /usr/src/sys/x86/include/include >>=20 >> (The include/include ones are from something making links pointing = back up to the parent include/ . I did not explicitly create these.) >>=20 >> (The cxbg and cxbge ones were from trying to have amd64 target amd64 = via xtoolchain (devel/amd64-gcc). But other places also stopped it and I = quit trying that for now.) >>=20 >>> # more /etc/rc.conf >>> hostname=3D"rpi2" >>> ifconfig_ue0=3D"DHCP" >>> sshd_enable=3D"YES" >>> powerd_enable=3D"YES" >>> # Nice if you have a network, else annoying. >>> ntpd_enable=3D"YES" >>> ntpd_sync_on_start=3D"YES" >>> # Uncomment to disable common services (more memory) >>> #cron_enable=3D"NO" >>> #syslogd_enable=3D"NO" >>> sendmail_enable=3D"NONE" >>> sendmail_submit_enable=3D"NO" >>> sendmail_outbound_enable=3D"NO" >>> sendmail_msp_queue_enable=3D"NO" >>> # >>> # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable >>> dumpdev=3D"AUTO" >>> # >>> dbus_enable=3D"YES" >>> hald_enable=3D"YES" >>> # >>> rpcbind_enable=3D"YES" >>> nfs_server_enable=3D"YES" >>> mountd_flags=3D"-r" >>> # >>> nfs_client_enable=3D"YES" >>=20 >>> # more /etc/sysctl.conf # $FreeBSD: head/etc/sysctl.conf 112200 = 2003-03-13 18:43:50Z mux $ >>> # >>> # This file is read when going to multi-user and its contents piped = thru >>> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for = details. >>> # >>> # Uncomment this to prevent users from seeing information about = processes that >>> # are being run under another UID. >>> #security.bsd.see_other_uids=3D0 >>> kern.nodump_coredump=3D1 >>> kern.capmode_coredump=3D1 >>> kern.sugid_coredump=3D1 >>> kern.corefile=3D/var/crash/%N.%P.core >>=20 >>=20 >> /etc/fstab , /etc/exports , /etc/resolv.conf are very simple but = non-default. Other than password files and the like the rest of /etc/. . = . is just defaults. >>=20 >>> # more /boot/loader.conf kern.cam.boot_delay=3D"10000" >>=20 >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 > I'm using an RPI-B rather than RPI2, but my symptoms are similar. >=20 > Did you use the wired or wireless interface on the RPI2? I only > get the panic on the RPI-B when using wireless. Wired works fine. My context is/was wired (ue0 --as in ifconfig_ue0=3D"DHCP"), not = wireless. > In an earlier message Ian said that he thought he knew what the > problem was... >=20 > ...keith =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Jun 21 11:59:14 2016 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 87B31A7B4CE for ; Tue, 21 Jun 2016 11:59:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 4B68B2F57 for ; Tue, 21 Jun 2016 11:59:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14058 invoked from network); 21 Jun 2016 11:59:48 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 21 Jun 2016 11:59:48 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 21 Jun 2016 07:59:09 -0400 (EDT) Received: (qmail 23621 invoked from network); 21 Jun 2016 11:59:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jun 2016 11:59:08 -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.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 0CC2F1C408D; Tue, 21 Jun 2016 04:59:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] From: Mark Millard In-Reply-To: Date: Tue, 21 Jun 2016 04:59:10 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> To: Keith White , otacilio.neto@bsd.com.br X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 11:59:14 -0000 [A top-post of a new result: WiFI works fine too. Quotes are from = input/output, with some redacting. This is the first time I've set up = WiFi on FreeBSD.] WiFI (urtwn0) also works fine for me with ssh on the rpi2 11.0 -r301975 = context. . . > urtwn0: on usbus0 > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > urtwn0: enabling 11n > # ifconfig . . . > wlan0: flags=3D8843 metric 0 = mtu 1500 > ether XXXX > inet 192.168.0.122 netmask 0xffffff00 broadcast 192.168.0.255=20= > groups: wlan=20 > ssid "Millard's AirPort2" channel 11 (2462 MHz 11g ht/20) = bssid XXXX > regdomain FCC country US authmode WPA2/802.11i privacy ON > deftxkey UNDEF TKIP 3:128-bit txpower 30 bmiss 7 scanvalid 60 > protmode CTS ht20 -ampdutx ampdurx ampdulimit 64k ampdudensity = 4 -stbc > wme roaming MANUAL > media: IEEE 802.11 Wireless Ethernet MCS mode 11ng > status: associated > nd6 options=3D29 An ssh markmi@192.168.0.122 into the rpi2 from Mac OS X's terminal = worked fine: > Warning: Permanently added '192.168.0.122' (ECDSA) to the list of = known hosts. > Password for markmi@rpi2: > Last login: Tue Jun 21 01:04:54 2016 from 192.168.0.105 > FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT = 2016 >=20 > Welcome to FreeBSD! >=20 > Release Notes, Errata: https://www.FreeBSD.org/releases/ > Security Advisories: https://www.FreeBSD.org/security/ > FreeBSD Handbook: https://www.FreeBSD.org/handbook/ > FreeBSD FAQ: https://www.FreeBSD.org/faq/ > Questions List: = https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ > FreeBSD Forums: https://forums.FreeBSD.org/ >=20 > Documents installed with the system are in the = /usr/local/share/doc/freebsd/ > directory, or can be installed later with: pkg install en-freebsd-doc > For other languages, replace "en" with a language code like de or fr. >=20 > Show the version of FreeBSD installed: freebsd-version ; uname -a > Please include that output and any error messages when posting = questions. > Introduction to manual pages: man man > FreeBSD directory layout: man hier >=20 > Edit /etc/motd to change this login announcement. > You can look through a file in a nice text-based interface by typing >=20 > less filename > $=20 The problem is apparently not general to all armv6 WiFi contexts. I'll note that I did not disable or unplug the wired Ethernet. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jun-21, at 4:14 AM, Mark Millard wrote: > On 2016-Jun-21, at 3:33 AM, Keith White = wrote: >=20 >> On Tue, 21 Jun 2016, Mark Millard wrote: >>=20 >>> Otac=C3=ADlio otacilio.neto at bsd.com.br wrote on Tue Jun 21 = 00:06:39 UTC 2016 : >>>=20 >>>>> The kernel panic is totally reproducible. I need only do a ssh in = the >>>>> beaglebone using ptty on windows or ssh on freebsd and the kernel = > panic is raised. >>> . . . >>>> FreeBSD11-ALPHA4 shows the same behavior. The only thing that I = need to raise the fault is ssh in the beaglebone. >>>=20 >>> (After this quotes are command input/output from my test activity.) >>>=20 >>> Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . = . >>>=20 >>>> # uname -apKU >>>> FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun = 16 18:12:02 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = armv6 1100117 1100117 >>>=20 >>>=20 >>> This is a no-debug kernel build (but with symbols). Details are = given later below. >>>=20 >>>> # ssh markmi@192.168.0.105 >>>> Password: >>>> Last login: Tue Jun 21 01:04:46 2016 >>>> markmi$=20 >>>=20 >>> Similarly I can ssh into the rpi2 from outside, here using new = remote connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . = . >>>=20 >>>> Password for markmi@rpi2: >>>> Last login: Mon May 9 19:27:33 2016 from 192.168.2.1 >>>> FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 = PDT 2016 >>>> Welcome to FreeBSD! >>>> Release Notes, Errata: https://www.FreeBSD.org/releases/ >>>> Security Advisories: https://www.FreeBSD.org/security/ >>>> FreeBSD Handbook: https://www.FreeBSD.org/handbook/ >>>> FreeBSD FAQ: https://www.FreeBSD.org/faq/ >>>> Questions List: = https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ >>>> FreeBSD Forums: https://forums.FreeBSD.org/ >>>> Documents installed with the system are in the = /usr/local/share/doc/freebsd/ >>>> directory, or can be installed later with: pkg install = en-freebsd-doc >>>> For other languages, replace "en" with a language code like de or = fr. >>>> Show the version of FreeBSD installed: freebsd-version ; uname -a >>>> Please include that output and any error messages when posting = questions. >>>> Introduction to manual pages: man man >>>> FreeBSD directory layout: man hier >>>> Edit /etc/motd to change this login announcement. >>>> To determine whether a file is a text file, executable, or some = other type >>>> of file, use >>>>=20 >>>> file filename >>>> -- Dru >>>> $=20 >>>=20 >>> No panics or other odd notices. >>>=20 >>> The problem is apparently not general to all armv6 contexts. >>>=20 >>> Various context details follow. . . >>>=20 >>>> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host = TO_TYPE=3Darmv6 >>>> # >>>> KERNCONF=3DRPI2-NODBG >>>> TARGET=3Darm >>>> .if ${.MAKE.LEVEL} =3D=3D 0 >>>> TARGET_ARCH=3D${TO_TYPE} >>>> .export TARGET_ARCH >>>> .endif >>>> # >>>> #WITH_CROSS_COMPILER=3D >>>> WITH_SYSTEM_COMPILER=3D >>>> # >>>> #CPUTYPE=3Dsoft >>>> WITH_LIBSOFT=3D >>>> WITH_LIBCPLUSPLUS=3D >>>> WITH_BINUTILS_BOOTSTRAP=3D >>>> #WITHOUT_CLANG_BOOTSTRAP=3D >>>> WITH_CLANG=3D >>>> WITH_CLANG_IS_CC=3D >>>> WITH_CLANG_FULL=3D >>>> WITH_CLANG_EXTRAS=3D >>>> WITH_LLDB=3D >>>> # >>>> WITH_BOOT=3D >>>> WITHOUT_LIB32=3D >>>> # >>>> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >>>> WITHOUT_GCC_BOOTSTRAP=3D >>>> WITHOUT_GCC=3D >>>> WITHOUT_GCC_IS_CC=3D >>>> WITHOUT_GNUCXX=3D >>>> # >>>> NO_WERROR=3D >>>> #WERROR=3D >>>> MALLOC_PRODUCTION=3D >>>> # >>>> WITH_DEBUG_FILES=3D >>>> # >>>> XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>>> XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >>>> # There is no XCPPFLAGS but XCPP ets XCFLAGS content. >>>=20 >>> ~/src.configs/make.conf was empty. >>>=20 >>>> # more /usr/src/sys/arm/conf/RPI2-NODBG >>>> # >>>> # RPI2 -- Custom configuration for the Raspberry Pi 2 >>>> # >>>> # For more information on this file, please read the config(5) = manual page, >>>> # and/or the handbook section on Kernel Configuration Files: >>>> # >>>> # = http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-con= fig.html >>>> # >>>> # The handbook is also available locally in /usr/share/doc/handbook >>>> # if you've installed the doc distribution, otherwise always see = the >>>> # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the >>>> # latest information. >>>> # >>>> # An exhaustive list of options and more detailed explanations of = the >>>> # device lines is also present in the ../../conf/NOTES and NOTES = files. >>>> # If you are in doubt as to the purpose or necessity of a line, = check first >>>> # in NOTES. >>>> # >>>> ident RPI2-NODBG >>>> include "RPI2" >>>> makeoptions DEBUG=3D-g # Build kernel with = gdb(1) debug symbols >>>> options ALT_BREAK_TO_DEBUGGER >>>> #options VERBOSE_SYSINIT # Enable verbose sysinit = messages >>>> options KDB # Enable kernel debugger = support >>>> # For minimum debugger support (stable branch) use: >>>> #options KDB_TRACE # Print a stack trace for a = panic >>>> options DDB # Enable the kernel = debugger >>>> nooptions INVARIANTS # Enable calls of extra = sanity checking >>>> nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS >>>> nooptions WITNESS # Enable checks to detect = deadlocks and cycles >>>> nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed >>>> nooptions DIAGNOSTIC >>>=20 >>>=20 >>> My /usr/src tree has some changes/additions --but mostly for = powerpc64 and powerpc issues: >>>=20 >>>> # svnlite status /usr/src/ >>>> M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>>> M /usr/src/lib/csu/powerpc64/Makefile >>>> ? /usr/src/sys/amd64/include/include >>>> ? /usr/src/sys/arm/conf/RPI2-NODBG >>>> ? /usr/src/sys/arm/include/include >>>> M /usr/src/sys/boot/ofw/Makefile.inc >>>> M /usr/src/sys/boot/powerpc/Makefile >>>> M /usr/src/sys/boot/powerpc/Makefile.inc >>>> M /usr/src/sys/boot/uboot/Makefile.inc >>>> M /usr/src/sys/conf/Makefile.powerpc >>>> M /usr/src/sys/conf/kern.mk >>>> M /usr/src/sys/conf/kmod.mk >>>> M /usr/src/sys/dev/cxgb/ulp/tom/cxgb_listen.c >>>> M /usr/src/sys/dev/cxgbe/tom/t4_listen.c >>>> ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG >>>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >>>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >>>> ? /usr/src/sys/powerpc/conf/GENERICvtsc >>>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >>>> ? /usr/src/sys/powerpc/include/include >>>> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >>>> M /usr/src/sys/powerpc/powerpc/exec_machdep.c >>>> ? /usr/src/sys/x86/include/include >>>=20 >>> (The include/include ones are from something making links pointing = back up to the parent include/ . I did not explicitly create these.) >>>=20 >>> (The cxbg and cxbge ones were from trying to have amd64 target amd64 = via xtoolchain (devel/amd64-gcc). But other places also stopped it and I = quit trying that for now.) >>>=20 >>>> # more /etc/rc.conf >>>> hostname=3D"rpi2" >>>> ifconfig_ue0=3D"DHCP" >>>> sshd_enable=3D"YES" >>>> powerd_enable=3D"YES" >>>> # Nice if you have a network, else annoying. >>>> ntpd_enable=3D"YES" >>>> ntpd_sync_on_start=3D"YES" >>>> # Uncomment to disable common services (more memory) >>>> #cron_enable=3D"NO" >>>> #syslogd_enable=3D"NO" >>>> sendmail_enable=3D"NONE" >>>> sendmail_submit_enable=3D"NO" >>>> sendmail_outbound_enable=3D"NO" >>>> sendmail_msp_queue_enable=3D"NO" >>>> # >>>> # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable >>>> dumpdev=3D"AUTO" >>>> # >>>> dbus_enable=3D"YES" >>>> hald_enable=3D"YES" >>>> # >>>> rpcbind_enable=3D"YES" >>>> nfs_server_enable=3D"YES" >>>> mountd_flags=3D"-r" >>>> # >>>> nfs_client_enable=3D"YES" >>>=20 >>>> # more /etc/sysctl.conf # $FreeBSD: head/etc/sysctl.conf 112200 = 2003-03-13 18:43:50Z mux $ >>>> # >>>> # This file is read when going to multi-user and its contents = piped thru >>>> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for = details. >>>> # >>>> # Uncomment this to prevent users from seeing information about = processes that >>>> # are being run under another UID. >>>> #security.bsd.see_other_uids=3D0 >>>> kern.nodump_coredump=3D1 >>>> kern.capmode_coredump=3D1 >>>> kern.sugid_coredump=3D1 >>>> kern.corefile=3D/var/crash/%N.%P.core >>>=20 >>>=20 >>> /etc/fstab , /etc/exports , /etc/resolv.conf are very simple but = non-default. Other than password files and the like the rest of /etc/. . = . is just defaults. >>>=20 >>>> # more /boot/loader.conf kern.cam.boot_delay=3D"10000" >>>=20 >>>=20 >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>>=20 >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>=20 >> I'm using an RPI-B rather than RPI2, but my symptoms are similar. >>=20 >> Did you use the wired or wireless interface on the RPI2? I only >> get the panic on the RPI-B when using wireless. Wired works fine. >=20 > My context is/was wired (ue0 --as in ifconfig_ue0=3D"DHCP"), not = wireless. >=20 >> In an earlier message Ian said that he thought he knew what the >> problem was... >>=20 >> ...keith >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Jun 21 13:29:54 2016 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 319DEAC51E4 for ; Tue, 21 Jun 2016 13:29:54 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 EF7CE1454 for ; Tue, 21 Jun 2016 13:29:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22a.google.com with SMTP id f6so13988462ith.0 for ; Tue, 21 Jun 2016 06:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=LkTBE/fo58pEnGEKTPXKCFGigX4oeZiKL36wuVrXaig=; b=mcjcjnRhXC2jSfzTfGOCLAvpaXAiSM/eAafrfyuM2PFrrfMx+awDTpEO+5JFoGtfA8 VmnUsfJ0OmNZ22BMTOqIk04NmPZ8QFIEvUT339eb9PyRncZDaikmqvVXNgJOSzX2y80f 5Y2aJs482QE/2ClUFtmF3XGyDxjw8lea5DtZ50jx5szAP7+OqHgqUunYzZzSewOdKq0f 0VgKxTVx8WJBCahh8LlXrDaLBdKe5k64Crop9BW+vJBPeAPIidfUqhll+NE1eThxPt+b hwZl7y3ncZvx/huyddi0hx5573WVu+Mav1FGV2YFJm8L6PbnvXjlBTIoZ1ghLKxjyNyX 75zw== 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:from :date:message-id:subject:to; bh=LkTBE/fo58pEnGEKTPXKCFGigX4oeZiKL36wuVrXaig=; b=NE1xEpTwO4zKeAbetcBr9JLGI6GltKAo+IzvNmSg+hvonm/gH9QYWiKCVV6O1Tx1hG Ks4WXKINntbdVg8dFgsZ1zyEVTk8tvKhJ3tra24xNxcLVyQpj7hOS5f3idtDL2SygJkT danBQYbJ+9q9KbGRaU0ya9vZ+ap+UWRzRcRzwQoRdTr80cvwd3+WtOYfwPJbNaNC4oq+ OmewdWHv02kBLz7AiOFsMDZGitedmK067Fg2Bh9u0UR+77zJTOapakpOH6IzDAAtsL9M iw+pwAFyOY1bdfO8be6Tj62fqOoKv6ulRFmlHUkmtZ8YcoFHmpcVZA1jr7OOuae6gaHs /XlA== X-Gm-Message-State: ALyK8tKAdgAX4kf9EWyXxnFtfAn1+r4fORM7vL91Xz/gzINNZ8E+lg/0tKwznU0H3ePK1rVslK5hbsTA8kPb/g== X-Received: by 10.36.239.70 with SMTP id i67mr5492727ith.59.1466515793147; Tue, 21 Jun 2016 06:29:53 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.6.213 with HTTP; Tue, 21 Jun 2016 06:29:33 -0700 (PDT) In-Reply-To: References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com> <31205295.d0H0JTrSWj@ralph.baldwin.cx> From: Ed Maste Date: Tue, 21 Jun 2016 09:29:33 -0400 X-Google-Sender-Auth: 7Tq4JkefxwRtwfAwKyD8MEpfnv0 Message-ID: Subject: Re: console in 11.0-ALPHA4 To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 13:29:54 -0000 On the topic of vgl(3) specifically, in October 2014 I wrote on this list: > vgl(3) is a graphics library for syscons(4) that provides some basic > graphics operations (e.g. some mode setting, bitmaps, boxes, > ellipses). Right now it does not support the newer vt(4) console. > > In order to help determine the priority of a porting effort to add > vt(4) support I'd like to better understand where vgl is being used > now. I'd be interested in hearing about both open source software > using vgl as well as proprietary or internal applications. So if > you're using vgl I'd appreciate a follow up (in private is fine) with > a brief description of your use case. That received exactly one private reply, where it was pointed out that dosbox is an example consumer. Nobody replied to say they actually use vgl(3). I will post a followup to -stable to ask the same question, but please, let me know if you use vgl(3) in open source or proprietary software. From owner-freebsd-current@freebsd.org Tue Jun 21 13:39:10 2016 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 BFD71AC570A for ; Tue, 21 Jun 2016 13:39:10 +0000 (UTC) (envelope-from imre@vdsz.com) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2151B1E3F for ; Tue, 21 Jun 2016 13:39:09 +0000 (UTC) (envelope-from imre@vdsz.com) Received: from vdsz.de ([188.68.58.236]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0LyeIB-1bU3130LuJ-016BSD; Tue, 21 Jun 2016 15:39:06 +0200 Received: from localhost (vdsz.de [local]) by vdsz.de (OpenSMTPD) with ESMTPA id e66169a1; Tue, 21 Jun 2016 15:39:04 +0200 (CEST) Date: Tue, 21 Jun 2016 15:39:04 +0200 From: Imre Vadasz To: freebsd-current@freebsd.org Cc: johannes@brilliantservice.co.jp Subject: Re: Intel Atom I2C Message-ID: <20160621133904.GA677128@albireo.intra.vdsz.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Provags-ID: V03:K0:HSYZAg2KCJlBRCoqsING2HjwxhLCGWYON9SEgZHmRIaghAeg/AC e+VTOAyr5O7VwYuFIQlSxfEnfy8NXhjTkdjEC4rRblRSOgmBy1ISKRjt05MVprMDAoSYUg1 smKxaKGv1PqHbI1rf91vKBSH/fOKobZQrmkPtCgPgxbqm+inlXP/0DBgV/88vFdkt/COkFd 7cOQcGnGRzFio240f6Q6Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:RMcxkkNdJFY=:HDcCUwexan3C00/hvtn/DI EXTdauEd9Z307CZzkYEpo4Od3upL3cXYOEinmJ/GaJ2SQ/oKjmoHqN0JN02DiDqoALw7X89hF Jw/7MF8BrnbYQMkCbAkxrYt9hIN9ioVDFvlNRf1eLIms6l7BHibrv+IXdzezSEBxxGhEs6R4/ 5t3Hahuflj0wC7fcmzCtO66JHsLJshdPy8xe2sedfXqvTql3YYag5B6/kDfzRvLmoYQABppxw TnKX/jGYUJu1ObiMtNJbysYcVvnhWWb/zp1ciSI0IsSM0Hn5uQRYI0xnu6HtvsVhvvFwh4mgo DMczsiCtfBTCSA/+ApzsuYcO6xhK/aP+X43W5bUFsXtSgM9juSF3Q8e1qgnz5x6YQVgJFQ8V+ p0JjH8zklZG4PBGAtLAG1Qg42BA6VoWPsOqg5ljuud6CJOg/OtV7PSK+ZzqCiqleiA77IMygQ aUSwtQeEp6uzHmrfhCE7aciauw3bUPxe1enNv6ESLq0EWCrro5qI776kHnfPcthLNcyvUvx6E dgM8UeG03FDPaIIhS9z3XLgQOOJf2tGtnloRWOHposgvGSzjwwvYte5u/mSXkukSx6KN47aWI hflCWOsI5CKS6fAXO31NyT8Ko9eiLuJoNzzZpquk/1+aJ2wZUxPlG09fnFjgJK0vFUQNNNbBU DLLrUYNdbF8/yBQzxepfD4hQMXJve4NxgGWmhq135DH/rX2pkHj98G0Pq5qpxQEv4pLg= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 13:39:10 -0000 Hi, No driver for the DMA controller is needed for using the I2C controllers. On many devices the I2C controllers are only mapped as ACPI devices, and not as PCI-devices, but the existing ichiic driver can trivially be adapted to attach via acpi, which is already done by DragonFly's ichiic: https://gitweb.dragonflybsd.org/dragonfly.git/blob/HEAD:/sys/bus/smbus/ichiic/ig4_acpi.c On many Cherryview devices, the I2C controller driver needs to install a handler for ACPI accesses to I2cSerialBus fields inside of GenericSerialBus operation regions. I have already committed the I2cSerialBus operation region Field handling to DraognFly master (implemented by the smbacpi(4) driver which attaches as a child to ichiic: https://gitweb.dragonflybsd.org/dragonfly.git/blob/HEAD:/sys/bus/smbus/smbacpi/smbacpi.c) The I2cSerialBus operation region Field handling is e.g. needed on the HP X2 210 tablet/detachable for the AC adapter and ACPI battery devices, as well as for activating power on the external micro-sd card slot via the sdhc controller's _PS0 ACPI-method. Peripheral devices hanging on the I2c busses usually are detected as ACPI devices, which have I2cSerialBus resource entries. On current Cherryview devices the I2c peripheral devices usually aren't explicitly child devices of the I2c-Controller devices, but the I2cSerialBus resources contain a string which can be dereferenced to get the corresponding I2c-bus device. The same mechanism is used for mapping GPIO pins and GPIO interrupts (with the GpioInt and GpioIo resource entries). Also, since the I2c peripheral devices usually are no longer children of the I2c-bus, the correct device attachement/initialization order needs to be derived via the _DEP acpi methods. From owner-freebsd-current@freebsd.org Tue Jun 21 14:00:23 2016 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 C3F19AC5AB7 for ; Tue, 21 Jun 2016 14:00:23 +0000 (UTC) (envelope-from imre@vdsz.com) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 256971C01 for ; Tue, 21 Jun 2016 14:00:22 +0000 (UTC) (envelope-from imre@vdsz.com) Received: from vdsz.de ([188.68.58.236]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0Lpis6-1bula12CQg-00fQm0; Tue, 21 Jun 2016 16:00:19 +0200 Received: from localhost (vdsz.de [local]) by vdsz.de (OpenSMTPD) with ESMTPA id 0c9575c6; Tue, 21 Jun 2016 16:00:18 +0200 (CEST) Date: Tue, 21 Jun 2016 16:00:18 +0200 From: Imre Vadasz To: freebsd-current@freebsd.org Cc: johannes@brilliantservice.co.jp Subject: Re: Intel Atom I2C Message-ID: <20160621140018.GA679553@albireo.intra.vdsz.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Provags-ID: V03:K0:Igz12JaXiEWP17xHsAEru0ybv+TxjM5ROprIwk2Nw+Oo/1fXHd+ GUFsRpEswEFuepfYFrx8TV3PkBo8HITC+/7K/IfzpPenG7nhfjIxkjQzMuK/sbFr6p/W1ru TlhuQWQWQ75OnzH3WNplDYkIinhSHKTikCaXk52X3N5/kHGq107drDUT4tV72QLYioC1ZR2 iJ53WxVKWOFlpySZHetsw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ik7qH2OnVB0=:dTs+gj7dzcGgektWpE5bwy JU0V2pSvnSFKS0FLgfN6r9GOw/uslocO+gsS5KA48mGcc397BzB/+VnE+zqOElN3GLb594mqO 08JQGxz5g0+VFoxUnTRGzeJHsoCbEemkom8oqcVyQwmf5xHCEprx+H3h9IqgKKnpZL3wXoNoR CctTxMRTLOKX5R19ypoRKaKnFqKUxSmvGMNPm2LN+Dg3C8KvqymjEQZWIY4ExLYoOKD/eNQzy 5tCtVYJxmxQhVSk2AQNRIzTTv1RKy/6Oz9gPKz9bTH86gOWNIlR+ZXJ371PuUqLNpaWuKexGK ShCFLDr4B9KnA+ju/cw+lTQLLAuKYWFU7ELww18ptYz6RXirktxAv38rz5ZqdF2AJp9ZSP3A+ RD8Ts9RHnGsgkUrS9pvXinNWfir+PQ+5atHoUIuJxOZxksjF5NBvnDfJpN3PKzed+Nbnt29VZ SJB77YWZTWjPtFNdHMh1gF2UxcW7uZuRvIhtGsmdfd+QUchqErt3X2q5uUHT5nfnhb76r20ZX Qo6JHTloJPiEEAMcaKyIJd0iF1tj+i8QbXcjpvxrqhug9v1qFLg4VchCQ2chkM8gfNqvDh8/Q NOG8Yodbal3Tuh1sCggO4air6MdIG1kLCkGcdUYZdopLNXSDYKsnIWVFG7wQZwcnUZEIajz+z W8b6KzjzavuQla+mqeocY7D0AVcz1rrMg/aesNfNYEZmykapccGlSbiZXSzZmTEOrQdk= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 14:00:23 -0000 So autodetection via smbus(4) probably shouldn't be used at all for this kind of I2c/smbus. On my HP x2 210 Cherryview tablet it even causes the system to hard freeze, when running the autodetection on the 7th I2C controller. Imre From owner-freebsd-current@freebsd.org Tue Jun 21 14:05:58 2016 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 DD9BDAC5C55 for ; Tue, 21 Jun 2016 14:05:58 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 9FBC82011 for ; Tue, 21 Jun 2016 14:05:58 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x230.google.com with SMTP id j2so21579584vkg.2 for ; Tue, 21 Jun 2016 07:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zi9CoQxhwd7mbHHxMX2I7rlppNaNkKEihY3dSRZvlMI=; b=cHK6cYn1Q3TpHpDDggQKbiZkVdCIdu8NY/GuD8V1RUejRL5T4vJwo9tIfUX2pseV6i GnDLpDAroMQJYyuILGssrurZ2KNUVbRE5FBoDXCQVe/PydGxJuWTzcz5Gfr1odc6fw0o rq18voAWIU0zj4OClBg0m80VygyWDwyLW/sCitqPKZvBUayuju84fu+vYuLoXCrOPo/9 Wl3coMaMow/t+x6jO0l2l3n1AVcZikQuvF3pyZcvfuALCvyPuSBgFriW280N5Xe9xGLN ZuYT+u531w0mNS3hV6i32fUHXfMQT0iPtWrsalxhfk+Z4URSn108s+yUPwBfTURNP0m7 spCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Zi9CoQxhwd7mbHHxMX2I7rlppNaNkKEihY3dSRZvlMI=; b=DmXQP8CjCDNfnvK4MfF3RuoqGuMYwZ6UdVxA+zxxdeF7lGIkriCYCJ5lWGnmMsow6q xg/rTbL7g4OkQvlLVJNXdVQrRDsozCQslt8xyZuFO04SQbFAFrIZLGtEuehWjTg/qaSb JKGqjnMl1OxfBO1IKzCYeFrEkRAzTFL7grSodz6D0ol1l2N8hno+shEaGajxWOraQijH +jvlGxd0vIaLVdU9sWlAAk2wrXejw0Z4ZeHZTmZIi7lL4OjxHQq3SHgHnoE1h6O4EQTj fmEbE5fbtaeZabx1o2KbRG+QmFT2X5z2uKZk0+82iRgXet2VCyshNA0ZOcR83kuXFDZt NLpg== X-Gm-Message-State: ALyK8tLY7YlytSGjiq7SAwP2qEqmmKgXxLcXL5bd4wcXdwbwC75wtDjMsdmvRXcTmggasl3HXi9qgvC7Mh+61T/e+ZnQVgYAXsuBiepC+i39/viSK8oA0tv6pmA8b63XwUGZ+HMyvAYNMBczlM7iif3u32M= X-Received: by 10.31.147.74 with SMTP id v71mr10063679vkd.101.1466517957373; Tue, 21 Jun 2016 07:05:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.33 with HTTP; Tue, 21 Jun 2016 07:05:43 -0700 (PDT) In-Reply-To: <20160621140018.GA679553@albireo.intra.vdsz.de> References: <20160621140018.GA679553@albireo.intra.vdsz.de> From: "Lundberg, Johannes" Date: Tue, 21 Jun 2016 07:05:43 -0700 Message-ID: Subject: Re: Intel Atom I2C To: Imre Vadasz Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 14:05:59 -0000 SGkgSW1yZQ0KDQpUaGFua3MgZm9yIHRoZSBpbmZvISBNYXkgSSBhc2ssIGlzbid0IHlvdXIgc3lz dGVtIFVFRkksIHNhbWUgYXMgbWluZT8gTGFzdA0KSSB0cmllZCBEcmFnb25GbHkgZGlkbid0IHN1 cHBvcnQgVUVGSS4uLg0KDQpJIGFsc28gaGFkIGhhbmdzIHdoZW4gcHJvYmluZyBjZXJ0YWluIEky QyBjb250cm9sbGVyIChtYXliZSBpdCB3YXMgdGhlDQo3dGguLi4pDQoNClBlcmhhcHMgdXNpbmcg bGludXhrcGkgYW5kIHRoZSBsaW51eCBkcml2ZXIgd291bGQgYmUgYSBnb29kIG9wdGlvbiBmb3IN CnRoaXMuIGk5MTUgdXNlcyBJMkMgYW5kIGl0IHdvcmtzIHdpdGggYmFzaWNhbGx5IHVubW9kaWZp ZWQgSW50ZWwgc291cmNlDQpjb2RlLiBPciBtYXliZSBJIHRyeSB0byBwb3J0IHlvdXIgZWZmb3J0 cyBsYXRlciA6KQ0KDQoNCk9uIFR1ZSwgSnVuIDIxLCAyMDE2IGF0IDc6MDAgQU0sIEltcmUgVmFk YXN6IDxpbXJlQHZkc3ouY29tPiB3cm90ZToNCg0KPiBTbyBhdXRvZGV0ZWN0aW9uIHZpYSBzbWJ1 cyg0KSBwcm9iYWJseSBzaG91bGRuJ3QgYmUgdXNlZCBhdCBhbGwgZm9yIHRoaXMNCj4ga2luZCBv ZiBJMmMvc21idXMuDQo+IE9uIG15IEhQIHgyIDIxMCBDaGVycnl2aWV3IHRhYmxldCBpdCBldmVu IGNhdXNlcyB0aGUgc3lzdGVtIHRvIGhhcmQgZnJlZXplLA0KPiB3aGVuIHJ1bm5pbmcgdGhlIGF1 dG9kZXRlY3Rpb24gb24gdGhlIDd0aCBJMkMgY29udHJvbGxlci4NCj4NCj4gSW1yZQ0KPg0KCi0t IAo9LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS0K 56eY5a+G5L+d5oyB44Gr44Gk44GE44Gm77ya44GT44Gu6Zu75a2Q44Oh44O844Or44Gv44CB5ZCN 5a6b5Lq644Gr6YCB5L+h44GX44Gf44KC44Gu44Gn44GC44KK44CB56eY5Yy/54m55qip44Gu5a++ 6LGh44Go44Gq44KL5oOF5aCx44KS5ZCr44KT44Gn44GE44G+44GZ44CCCuOCguOBl+OAgeWQjeWu m+S6uuS7peWkluOBruaWueOBjOWPl+S/oeOBleOCjOOBn+WgtOWQiOOAgeOBk+OBruODoeODvOOD q+OBruegtOajhOOAgeOBiuOCiOOBs+OBk+OBruODoeODvOODq+OBq+mWouOBmeOCi+S4gOWIh+OB rumWi+ekuuOAgQropIflhpnjgIHphY3luIPjgIHjgZ3jga7ku5bjga7liKnnlKjjgIHjgb7jgZ/j ga/oqJjovInlhoXlrrnjgavln7rjgaXjgY/jgYTjgYvjgarjgovooYzli5XjgoLjgZXjgozjgarj gYTjgojjgYbjgYrpoZjjgYTnlLPjgZfkuIrjgZLjgb7jgZnjgIIKLS0tCkNPTkZJREVOVElBTElU WSBOT1RFOiBUaGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbCBpcyBjb25maWRlbnRpYWwKYW5k IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZS4KRGlzY2xvc3VyZSwgY29weWluZywg ZGlzdHJpYnV0aW9uIG9yIGFueSBvdGhlciBhY3Rpb24gb2YgdXNlIG9mIHRoaXMKZW1haWwgYnkg cGVyc29uIG90aGVyIHRoYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBpcyBwcm9oaWJpdGVkLgpJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGFuZCBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4KZXJyb3IsIHBsZWFzZSBkZXN0cm95IHRoZSBvcmlnaW5hbCBtZXNzYWdlLgo= From owner-freebsd-current@freebsd.org Tue Jun 21 14:07:29 2016 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 09360AC5CD1 for ; Tue, 21 Jun 2016 14:07:29 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (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 C8FDD215F for ; Tue, 21 Jun 2016 14:07:28 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from vader9.bultmann.eu (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 41CEB752B for ; Tue, 21 Jun 2016 16:07:25 +0200 (CEST) Subject: Re: 11.0-ALPHA4 and VIMAGE To: freebsd-current@freebsd.org References: <57680DD1.8040808@gmail.com> <2003E00C-236B-4321-980E-474FD6243DD4@lists.zabbadoz.net> From: Jan Bramkamp Message-ID: Date: Tue, 21 Jun 2016 16:07:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <2003E00C-236B-4321-980E-474FD6243DD4@lists.zabbadoz.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 14:07:29 -0000 On 20/06/16 18:05, Bjoern A. Zeeb wrote: > Hi, > > On 20 Jun 2016, at 15:37, Ernie Luzar wrote: > >> Hello list; >> >> I have installed 11.0-ALPHA4-i386-20160617-r301975 to test VIMAGE. >> I have read previous list posts saying vimage was going to be part of >> the base system in 11.0. When I configure a jail with vnet I get a >> error typical of vimage not being compiled into the kernel. >> >> To me it looks like vimage is not part of the base system in 11.0. >> >> What is the status of vimage in 11.0? > > I am not sure anyone said that it would be in GENERIC for 11.0. > > The plan is to have it more stable and leak a lot less memory possibly > and some bits made it in to HEAD over the last months already, another > patch for a top-down teardown is in the review system, and I am > currently working on fixing a lot of pf. Is there any hope reliable VIMAGE support will make it into the 11.0 release? From owner-freebsd-current@freebsd.org Tue Jun 21 14:19:53 2016 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 094A6AC5FDA for ; Tue, 21 Jun 2016 14:19:53 +0000 (UTC) (envelope-from imre@vdsz.com) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CD0C2976 for ; Tue, 21 Jun 2016 14:19:51 +0000 (UTC) (envelope-from imre@vdsz.com) Received: from vdsz.de ([188.68.58.236]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0M78fW-1bd5z10OpS-00x5nI; Tue, 21 Jun 2016 16:19:49 +0200 Received: from localhost (vdsz.de [local]) by vdsz.de (OpenSMTPD) with ESMTPA id 0cef26b0; Tue, 21 Jun 2016 16:19:48 +0200 (CEST) Date: Tue, 21 Jun 2016 16:19:48 +0200 From: Imre Vadasz To: freebsd-current@freebsd.org Cc: "Lundberg, Johannes" Subject: Re: Intel Atom I2C Message-ID: <20160621141948.GA679813@albireo.intra.vdsz.de> References: <20160621140018.GA679553@albireo.intra.vdsz.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Provags-ID: V03:K0:C6A6Kc9K4iMPV6p0G9mk+h7mAGLwptxySds4thxNHvamEfbKixA TQUkbP9x35C1xUKS+qcH7GtXpAhuxbLgG7pkzq3p8cepx+hQv8UkvvWpyDzIwJ5MJG3Kifc gEEOlQy0rCRP6vIPr4XyxxNzcvTveZffHfGrWZ6r+BDFNuQHXKrIlp6KRV/84ILoyVgZtfR UHFZSxn1hiyedqn+ScMVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:95AucNbHlwg=:kPTGjFxmVJPl/REe6N56Wj d9c3gmQYSqdnWVYl7ckHjlwIda8XLj/DbK30DU2umTcUHfaabkFKCDXqnHZzDPDeW07aqNmSF ZMy8Kyjf4FSWi2h7KwmA79Ilxcm0rBEUloEvPrqS6yeG6CTsPPTO9B/45v/TdM6GEVfr9ZZKu S1WivGz7n9N0QOQfXAcl1jd/W6sFZ0BFo+UYMRgyHY3Wd4ydx0ewo+QeXlG4QJeU/GCLHbMYf 6nWJrgfUZq4ETBeuUCRTj4H7Ula7bZNV6FuonxMce0Fa+1rk11f78pP6a1r2iPkIQDJSr5pMX wb/oQ/DpMXqSBrpPrrvQZUlZzFB+IOPuVrd/FYa7XSHOT7XpVZxfohpHivD7s7euQ+WCRIraj R8U1NYP3FlGHW7Nr79zwyxWbQlNNr780NDXo6tXnVOhKDpEdmLXafZV8UuxR0EC/nzvx+Q18D u1D7smGDcp6BRR4YNluC/VGn7lsNdLv0ceb+geHaKkF0lBr54lStd20G1+aB/kSANisTM3jnH qdKlJDzh7m+OGKxCmh+Dx5P/LTxxmRePvFBO+gHFBMYiz652kH8G7kdqbou3gygFUTA2FnikB 6o0b6pLfmqdkus5bmQ5swYhbhymcZReH/tziAUI/Avgj+6YdSBYdUvRVGsMwUmoFDDZAY+iY/ YNoBxnZEN3p/FxQSXAihjzbQsR0/bBsBot/nDcOYXhr44xvKJwK+ljaf4PVVVZepeESg= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 14:19:53 -0000 Hi, On 07:05 Tue 21 Jun , Lundberg, Johannes wrote: > Hi Imre > > Thanks for the info! May I ask, isn't your system UEFI, same as mine? Last > I tried DragonFly didn't support UEFI... Yes, the HP x2 210 is UEFI only, but DragonFly *can* boot from UEFI :) I did a port of FreeBSD's UEFI bootloader to DragonFly, which I commited ca. 2 months ago, and I added basic support in the kernel for UEFI booting. Only UEFI support in DragonFly's installer is still missing :( > > I also had hangs when probing certain I2C controller (maybe it was the > 7th...) > > Perhaps using linuxkpi and the linux driver would be a good option for > this. i915 uses I2C and it works with basically unmodified Intel source > code. Or maybe I try to port your efforts later :) It's not really an option here, to use the linux driver, since this I2c bus has to integrate tightly with the operating-system for the ACPI operation region handling, and the I2cSerialBus resource handling. > On Tue, Jun 21, 2016 at 7:00 AM, Imre Vadasz wrote: > > > So autodetection via smbus(4) probably shouldn't be used at all for this > > kind of I2c/smbus. > > On my HP x2 210 Cherryview tablet it even causes the system to hard freeze, > > when running the autodetection on the 7th I2C controller. > > > > Imre > > > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 秘密ä¿æŒã«ã¤ã„ã¦ï¼šã“ã®é›»å­ãƒ¡ãƒ¼ãƒ«ã¯ã€å宛人ã«é€ä¿¡ã—ãŸã‚‚ã®ã§ã‚ã‚Šã€ç§˜åŒ¿ç‰¹æ¨©ã®å¯¾è±¡ã¨ãªã‚‹æƒ…報をå«ã‚“ã§ã„ã¾ã™ã€‚ > ã‚‚ã—ã€å宛人以外ã®æ–¹ãŒå—ä¿¡ã•ã‚ŒãŸå ´åˆã€ã“ã®ãƒ¡ãƒ¼ãƒ«ã®ç ´æ£„ã€ãŠã‚ˆã³ã“ã®ãƒ¡ãƒ¼ãƒ«ã«é–¢ã™ã‚‹ä¸€åˆ‡ã®é–‹ç¤ºã€ > 複写ã€é…布ã€ãã®ä»–ã®åˆ©ç”¨ã€ã¾ãŸã¯è¨˜è¼‰å†…容ã«åŸºã¥ãã„ã‹ãªã‚‹è¡Œå‹•ã‚‚ã•ã‚Œãªã„よã†ãŠé¡˜ã„申ã—上ã’ã¾ã™ã€‚ > --- > CONFIDENTIALITY NOTE: The information in this email is confidential > and intended solely for the addressee. > Disclosure, copying, distribution or any other action of use of this > email by person other than intended recipient, is prohibited. > If you are not the intended recipient and have received this email in > error, please destroy the original message. From owner-freebsd-current@freebsd.org Tue Jun 21 15:42:12 2016 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 581D3AC5287 for ; Tue, 21 Jun 2016 15:42:12 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 299D22AF1 for ; Tue, 21 Jun 2016 15:42:12 +0000 (UTC) (envelope-from will@firepipe.net) Received: by mail-io0-x244.google.com with SMTP id 100so2742650ioh.1 for ; Tue, 21 Jun 2016 08:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=firepipe-net.20150623.gappssmtp.com; s=20150623; h=sender:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=kbVqdEqKKkQj6yky5w9VoyvUkumzT5jrU9S5X2+mgmY=; b=XtMkorZhGPZXAJSAKya2lGkA5du2DIBTxj08krFFOvigUnmm45YUc9S0CKFDC78uOZ r7DxLXYzI4I7MiJf3nh9EP/ZZ6ruE3f8DpsUAH8MumhMlJMoXJ5sv2/l84j56/KjvQQJ GydItirThmZ8/S9l2UueXGBp0tp4p8+VRWTVvAMTc3VTqCN5bpxjzmUHscpv/+k4HgeB yq/1NrYybVcXGlDYlKK0Pc+Uct7ilTq20F0pW5PCYHmNGB6aqYBmXeVut/pUyQn14Ium rhmqYp+XT3MCvacmLKxcb+lMTjx1D7W7r5luZr4x/K09O0ctGBtoJ1Pt+WdD3fjZuS3O qeiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mime-version:content-disposition:user-agent; bh=kbVqdEqKKkQj6yky5w9VoyvUkumzT5jrU9S5X2+mgmY=; b=Pws9+DOAAD4LkZxAgq3mv36xuccpvtDLee3xZccqNP+tpoGT13f2FFP6Qj4I+Lzqiw W3QmTHStZdSRY7+GcDJDQhjS7jEYfz4tpOEX5/eCLyGUgFWFXw6WvPxru/YTU1MGarF3 Qy3sS16/7O9jxp+odLY0SUAI5fWfVCBGuHc9uTY1WTraXMh4IdKXkl4lByS7dHYfeaU2 ghSaiC89bgwDS3z7JklRYOLUYH+ZPmilCMZjKTIMylMTmWD8D/sT/cbBBrgW7px465KW Pwb0MlPDYiEddqmihzR6ZMXK8ZYfCSNiSWDL5X4xML6aqxyn4XhhMCX4lVPcSz6Jr0dX lsAA== X-Gm-Message-State: ALyK8tIyMH042y96vWl94AocKRxBjFgH4ejzkpHbxvI0OLHSR1RxYzWlo1IhVoDTnJ2Eaw== X-Received: by 10.107.152.82 with SMTP id a79mr31200469ioe.46.1466523731481; Tue, 21 Jun 2016 08:42:11 -0700 (PDT) Received: from sol.firepipe.net ([2601:445:4201:4373:beae:c5ff:fe74:d23b]) by smtp.gmail.com with ESMTPSA id o2sm1585887ith.7.2016.06.21.08.42.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jun 2016 08:42:10 -0700 (PDT) Sender: Will Andrews Date: Tue, 21 Jun 2016 10:42:08 -0500 From: Will Andrews To: freebsd-current@freebsd.org Cc: freebsd-geom@freebsd.org Subject: geom_part: support < 128 GPT partition entries Message-ID: <20160621154207.GA2322@sol.firepipe.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 15:42:12 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'd appreciate a review for: https://reviews.freebsd.org/D6900 Summary: This change is useful primarily for using GPT on embedded boards like the pine64 (and others using an Allwinner SoC) that want a firmware image loaded below sector 34 (8K in that instance). Note that because this changes g_part_scheme, it breaks the ABI. Thanks! --=20 wca --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAldpYEoACgkQF47idPgWcsUrJwCfe3XIixVPQZWKml3eQuxbtXxN Lo0An3P6ApUUrpjcpc7XgQGOFM3CMIoO =CAW3 -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-current@freebsd.org Tue Jun 21 15:55:22 2016 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 A1A3CAC5864 for ; Tue, 21 Jun 2016 15:55:22 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (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 512CA1845 for ; Tue, 21 Jun 2016 15:55:22 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from vader9.bultmann.eu (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 4A1797551 for ; Tue, 21 Jun 2016 17:55:12 +0200 (CEST) Subject: Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory To: freebsd-current@freebsd.org References: <7c39e5ac-3ed7-f19a-e175-d27af07eea47@delphij.net> <5fc80d8ee559336a657514b3f2ec2a33@ultimatedns.net> From: Jan Bramkamp Message-ID: <975a9e3d-c7c5-6ed1-9985-5f5d99050d8f@rlwinm.de> Date: Tue, 21 Jun 2016 17:55:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 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.22 Precedence: 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, 21 Jun 2016 15:55:22 -0000 On 18/06/16 17:15, Alan Somers wrote: > On Thu, Jun 16, 2016 at 7:20 AM, Chris H wrote: >> On Wed, 15 Jun 2016 08:03:55 -0400 Nikolai Lifanov >> wrote >> >>> On 06/14/2016 21:05, Marcelo Araujo wrote: >>>> 2016-06-15 8:17 GMT+08:00 Chris H : >>>> >>>>> On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo >>>>> wrote >>>>> >>>>>> Hey, >>>>>> >>>>>> Thanks for the CFT Craig. >>>>>> >>>>>> 2016-06-09 14:41 GMT+08:00 Xin Li : >>>>>> >>>>>>> >>>>>>> >>>>>>> On 6/8/16 23:10, Craig Rodrigues wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD >>>>>>>> current. >>>>>>>> >>>>>>>> In latest current, it should be possible to put in /etc/rc.conf: >>>>>>>> >>>>>>>> nis_ypldap_enable="YES" >>>>>>>> to activate the ypldap daemon. >>>>>>>> >>>>>>>> When set up properly, it should be possible to log into FreeBSD, and >>>>> have >>>>>>>> the backend password database come from an LDAP database such >>>>>>>> as OpenLDAP >>>>>>>> >>>>>>>> There is some documentation for setting this up, but it is OpenBSD >>>>>>> specific: >>>>>>>> >>>>>>>> http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client >>>>>>>> http://puffysecurity.com/wiki/ypldap.html#2 >>>>>>>> >>>>>>>> I did not bother porting the OpenBSD LDAP server to FreeBSD, so that >>>>>>>> information >>>>>>>> does not apply. I figure that openldap from ports should work fine. >>>>>>>> >>>>>>>> I was wondering if there is someone out there familiar enough with >>>>> LDAP >>>>>>>> and has a setup they can test this stuff out with, provide feedback, >>>>> and >>>>>>>> help >>>>>>>> improve the documentation for FreeBSD? >>>>>>> >>>>>>> Looks like it would be a fun weekend project. I've cc'ed a potential >>>>>>> person who may be interested in this as well. >>>>>>> >>>>>>> But will this worth the effort? (I think the current implementation >>>>>>> would do everything with plaintext protocol over wire, so while it >>>>>>> extends life for legacy applications that are still using NIS/YP, it >>>>>>> doesn't seem to be something that we should recommend end user to use?) >>>>>>> >>>>>> >>>>>> I can see two good point to use ypldap that would be basically for users >>>>>> that needs to migrate from NIS to LDAP or need to make some integration >>>>>> between legacy(NIS) and LDAP during a transition period to LDAP. >>>>>> >>>>>> As mentioned, NIS is 'plain text' not safe by its nature, however there >>>>> are >>>>>> still lots of people out there using NIS, and ypldap(8) is a good tool to >>>>>> help these people migrate to a more safe tool like LDAP. >>>>>> >>>>>> >>>>>>> >>>>>>>> I would also be interested in hearing from someone who can see if >>>>>>>> ypldap can work against a Microsoft Active Directory setup? >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> >>>>>> All my tests were using OpenLDAP, I used the OpenBSD documentation to >>>>> setup >>>>>> everything, and the file share/examples/ypldap/ypldap.conf can be a good >>>>>> start to anybody that wants to start to work with ypldap(8). >>>>>> >>>>>> Would be nice hear from other users how was their experience using ypldap >>>>>> with MS Active Directory and perhaps some HOWTO how they made all the >>>>> setup >>>>>> would be amazing to have. >>>>>> >>>>>> Also, would be useful to know who are still using NIS and what kind of >>>>>> setup(user case), maybe even the reason why they are still using it. >>>>> >>>>> Honestly, I think the best way to motivate people to do the right >>>>> thing(tm) Would be to remove Yellow Pages from the tree, entirely. :-) >>>>> It's been dead for *years*, and as you say, isn't safe, anyway.. >>>>> >>>> >>>> Yes, I have a plan for that, but I don't believe it will happens before >>>> FreeBSD 12-RELEASE. >>>> >>> >>> Please don't, at least for now. NIS is fast, simple, reliable, and works >>> on first boot without additional software. I have passwords in >>> Kerberos, so the usual cons doesn't apply. This is very valuable to me. >>> >>> It's not hurting anyone. What's the motivation behind removing it? >> >> In all honesty, my comment was somewhat tongue-in-cheek. But from >> a purely maintenance POV, at this point in time. I think the Yellow >> Pages are better suited for the ports tree, than in $BASE. >> > > It will be hard to wean people off of NIS as long as KGSSAPI is > disabled in GENERIC. Does anybody know why it isn't enabled by > default? Because it's just a `kldload kgssapi` away. Put it in loader.conf or rc.conf depending on your needs/preferences. From owner-freebsd-current@freebsd.org Tue Jun 21 16:36:54 2016 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 974D9AC402C for ; Tue, 21 Jun 2016 16:36:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 579EE2B8C for ; Tue, 21 Jun 2016 16:36:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ob0-x234.google.com with SMTP id c3so30435792obc.2 for ; Tue, 21 Jun 2016 09:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+a24zFHvTNgRgYSOXb3QzfYZwyuAQ7h9SuRBKRBc4sw=; b=IYFyT7zfVUT+5yiEjzf3jlM6v4KCSIUsasQGsdwx9WV4C/U77faig7u8Q+yT6TgY/v w4CgI+GEbLMl2fNxeJT0bvD694XS2NQe4dlqZmJkdtPAjFl2vARu1qDKAwDQF18wK092 p1vce3rPeLWphDchtaGtKfuR7w20pgADJjtWm055IYg55v4gdxEGgHix7v2bnU4G6vs/ 63V3smISODtldAHhcytzry8KhkAM1rIeiIxWri3nUj1mXSTDb1fCT8hv28WTu+GGiHFX IixD/1gqiGLDlT8A6k3d6PFBWLfSGV+jh479DfOtkXyA3o5I32n3bF0IqCvmY8kNm2G7 4cRQ== 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:from :date:message-id:subject:to:cc; bh=+a24zFHvTNgRgYSOXb3QzfYZwyuAQ7h9SuRBKRBc4sw=; b=mB0ZFr9z2Ot2uTLWJ1t53rB/8Qof6N1wnF8ywNeKWQZdQM6LFOvdFpZs/pOGXcuZTl E3YACg+MlAh6+pfhqFqHaHB5WN1e2GCTeKS2YS2o9Ccfn2NCXjtnJDux0DcjJITywoIb ndcDdnF9uqFlQs/jzoBLuw/R5bdW8ZTEVO3YYe1l1YU9cwU3wU2ceSE2SZZQ0BZtH5kM sGm7pf1XeIgCYrAR8qmqQRXpDXj7M0d0kanlBaCI9hiFXM/JjjhnhRMlAHq4vXIWW5LT JYyjV3zfhb7RnkNXt5sxltuQGFQlIiFixNUMf0ogmnlY4XWLwbA98hbF+7qeKaLx/Q0d yHxQ== X-Gm-Message-State: ALyK8tLahyCVoUiWpOEYnn/RBexKU4pXWIYmBbEr4J0vNo+w/I4Avus4vojZZA0EZu0TgrlFHPFMAb4usJRWxA== X-Received: by 10.157.14.115 with SMTP id n48mr16620664otd.106.1466527013490; Tue, 21 Jun 2016 09:36:53 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.102.206 with HTTP; Tue, 21 Jun 2016 09:36:52 -0700 (PDT) In-Reply-To: <975a9e3d-c7c5-6ed1-9985-5f5d99050d8f@rlwinm.de> References: <7c39e5ac-3ed7-f19a-e175-d27af07eea47@delphij.net> <5fc80d8ee559336a657514b3f2ec2a33@ultimatedns.net> <975a9e3d-c7c5-6ed1-9985-5f5d99050d8f@rlwinm.de> From: Alan Somers Date: Tue, 21 Jun 2016 10:36:52 -0600 X-Google-Sender-Auth: iHtoCo-RhmTUjDt4R4ROV2_kh7k Message-ID: Subject: Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory To: Jan Bramkamp Cc: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 16:36:54 -0000 On Tue, Jun 21, 2016 at 9:55 AM, Jan Bramkamp wrote: > On 18/06/16 17:15, Alan Somers wrote: >> >> On Thu, Jun 16, 2016 at 7:20 AM, Chris H wrote: >>> >>> On Wed, 15 Jun 2016 08:03:55 -0400 Nikolai Lifanov >>> >>> wrote >>> >>>> On 06/14/2016 21:05, Marcelo Araujo wrote: >>>>> >>>>> 2016-06-15 8:17 GMT+08:00 Chris H : >>>>> >>>>>> On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo >>>>>> >>>>>> wrote >>>>>> >>>>>>> Hey, >>>>>>> >>>>>>> Thanks for the CFT Craig. >>>>>>> >>>>>>> 2016-06-09 14:41 GMT+08:00 Xin Li : >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 6/8/16 23:10, Craig Rodrigues wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have worked with Marcelo Araujo to port OpenBSD's ypldap to >>>>>>>>> FreeBSD >>>>>>>>> current. >>>>>>>>> >>>>>>>>> In latest current, it should be possible to put in /etc/rc.conf: >>>>>>>>> >>>>>>>>> nis_ypldap_enable="YES" >>>>>>>>> to activate the ypldap daemon. >>>>>>>>> >>>>>>>>> When set up properly, it should be possible to log into FreeBSD, >>>>>>>>> and >>>>>> >>>>>> have >>>>>>>>> >>>>>>>>> the backend password database come from an LDAP database such >>>>>>>>> as OpenLDAP >>>>>>>>> >>>>>>>>> There is some documentation for setting this up, but it is OpenBSD >>>>>>>> >>>>>>>> specific: >>>>>>>>> >>>>>>>>> >>>>>>>>> http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client >>>>>>>>> http://puffysecurity.com/wiki/ypldap.html#2 >>>>>>>>> >>>>>>>>> I did not bother porting the OpenBSD LDAP server to FreeBSD, so >>>>>>>>> that >>>>>>>>> information >>>>>>>>> does not apply. I figure that openldap from ports should work >>>>>>>>> fine. >>>>>>>>> >>>>>>>>> I was wondering if there is someone out there familiar enough with >>>>>> >>>>>> LDAP >>>>>>>>> >>>>>>>>> and has a setup they can test this stuff out with, provide >>>>>>>>> feedback, >>>>>> >>>>>> and >>>>>>>>> >>>>>>>>> help >>>>>>>>> improve the documentation for FreeBSD? >>>>>>>> >>>>>>>> >>>>>>>> Looks like it would be a fun weekend project. I've cc'ed a >>>>>>>> potential >>>>>>>> person who may be interested in this as well. >>>>>>>> >>>>>>>> But will this worth the effort? (I think the current implementation >>>>>>>> would do everything with plaintext protocol over wire, so while it >>>>>>>> extends life for legacy applications that are still using NIS/YP, it >>>>>>>> doesn't seem to be something that we should recommend end user to >>>>>>>> use?) >>>>>>>> >>>>>>> >>>>>>> I can see two good point to use ypldap that would be basically for >>>>>>> users >>>>>>> that needs to migrate from NIS to LDAP or need to make some >>>>>>> integration >>>>>>> between legacy(NIS) and LDAP during a transition period to LDAP. >>>>>>> >>>>>>> As mentioned, NIS is 'plain text' not safe by its nature, however >>>>>>> there >>>>>> >>>>>> are >>>>>>> >>>>>>> still lots of people out there using NIS, and ypldap(8) is a good >>>>>>> tool to >>>>>>> help these people migrate to a more safe tool like LDAP. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> I would also be interested in hearing from someone who can see if >>>>>>>>> ypldap can work against a Microsoft Active Directory setup? >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> >>>>>>> All my tests were using OpenLDAP, I used the OpenBSD documentation to >>>>>> >>>>>> setup >>>>>>> >>>>>>> everything, and the file share/examples/ypldap/ypldap.conf can be a >>>>>>> good >>>>>>> start to anybody that wants to start to work with ypldap(8). >>>>>>> >>>>>>> Would be nice hear from other users how was their experience using >>>>>>> ypldap >>>>>>> with MS Active Directory and perhaps some HOWTO how they made all the >>>>>> >>>>>> setup >>>>>>> >>>>>>> would be amazing to have. >>>>>>> >>>>>>> Also, would be useful to know who are still using NIS and what kind >>>>>>> of >>>>>>> setup(user case), maybe even the reason why they are still using it. >>>>>> >>>>>> >>>>>> Honestly, I think the best way to motivate people to do the right >>>>>> thing(tm) Would be to remove Yellow Pages from the tree, entirely. :-) >>>>>> It's been dead for *years*, and as you say, isn't safe, anyway.. >>>>>> >>>>> >>>>> Yes, I have a plan for that, but I don't believe it will happens before >>>>> FreeBSD 12-RELEASE. >>>>> >>>> >>>> Please don't, at least for now. NIS is fast, simple, reliable, and works >>>> on first boot without additional software. I have passwords in >>>> Kerberos, so the usual cons doesn't apply. This is very valuable to me. >>>> >>>> It's not hurting anyone. What's the motivation behind removing it? >>> >>> >>> In all honesty, my comment was somewhat tongue-in-cheek. But from >>> a purely maintenance POV, at this point in time. I think the Yellow >>> Pages are better suited for the ports tree, than in $BASE. >>> >> >> It will be hard to wean people off of NIS as long as KGSSAPI is >> disabled in GENERIC. Does anybody know why it isn't enabled by >> default? > > > Because it's just a `kldload kgssapi` away. Put it in loader.conf or rc.conf > depending on your needs/preferences. Thanks Jan. I didn't realize that kgssapi was built as a module by default now. All of the very few NFSv4 guides I've found have described including it in the kernel as a requirement. https://code.google.com/archive/p/macnfsv4/wikis/FreeBSD8KerberizedNFSSetup.wiki http://daemon-notes.com/articles/network/unix-lan/nfs -Alan From owner-freebsd-current@freebsd.org Tue Jun 21 17:33:23 2016 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 D3B45AC5236; Tue, 21 Jun 2016 17:33:23 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB2F62EF9; Tue, 21 Jun 2016 17:33:23 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 7DA625C0; Tue, 21 Jun 2016 13:33:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: BBB (cpsw(4)) seems to be broken in the latest 11-current From: Paul Mather In-Reply-To: Date: Tue, 21 Jun 2016 13:33:20 -0400 Cc: Luiz Otavio O Souza , "freebsd-arm@freebsd.org" , FreeBSD Current , Maxim Sobolev Content-Transfer-Encoding: quoted-printable Message-Id: References: <83A18C0E-FA89-4009-A8D5-3185FB27A688@netgate.com> To: Keith White X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 17:33:23 -0000 On Jun 20, 2016, at 6:33 PM, Keith White wrote: > On Mon, 20 Jun 2016, Luiz Otavio O Souza wrote: >=20 >> On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote: >>> Jim, some update from here. Running r283287 of the driver, I still = see the >>> same "watchdog timeout" messages, but they do not lead to the = interface >>> lockout. The traffic resumes momentarily. Which is probably why I = never paid >>> much attention to those warnings before. Therefore, I suspect that = the new >>> MAC code does not deal with watchdog-triggered interface reset as = good as >>> the old code. Does it give you any ideas about what could be wrong = there by >>> any chance? >>=20 >>=20 >> Hi Maxim, >>=20 >> My recent changes contributed somehow to expose the bug more = frequently. >>=20 >> There was a condition in tx packet reclamation where we aren't >> restarting the tx queue in one of the possible stall conditions. >>=20 >> Please try the attached patch and let me know if it works for you. >>=20 >> Luiz >=20 > Your patch fixes the problem for me. Thanks! >=20 > FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302028M: Mon = Jun 20 18:19:55 EDT 2016 = kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE-LOCAL arm = armv6 >=20 > ...keith The patch also fixes the problem for me. FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #2 r302030M: Tue Jun = 21 10:20:59 EDT 2016 = pmather@beaglebone:/usr/obj/usr/src/sys/BEAGLEBONE-NO_WITNESS arm Cheers, Paul. From owner-freebsd-current@freebsd.org Tue Jun 21 17:55:28 2016 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 D48EFAC5871 for ; Tue, 21 Jun 2016 17:55:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 28E431D81 for ; Tue, 21 Jun 2016 17:55:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 57a4a319-37d9-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 21 Jun 2016 17:55:29 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u5LHtJCB006416; Tue, 21 Jun 2016 11:55:19 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1466531719.34556.72.camel@freebsd.org> Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] From: Ian Lepore To: =?ISO-8859-1?Q?Otac=EDlio?= , Keith White , Mark Millard Cc: freebsd-arm , FreeBSD Current Date: Tue, 21 Jun 2016 11:55:19 -0600 In-Reply-To: <22fe5f7f-6153-e092-c410-eddb1431a78a@bsd.com.br> References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> <22fe5f7f-6153-e092-c410-eddb1431a78a@bsd.com.br> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 17:55:28 -0000 On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: > Em 21/06/2016 07:33, Keith White escreveu: > > In an earlier message Ian said that he thought he knew what the > > problem was... > > Here the problem occurs when using wifi. I do not have tested wired > because I don't have a cable here. > > > []'s > > -Otacilio The wifi alignment fault should be fixed as of r302064. Sorry it took so long. -- Ian From owner-freebsd-current@freebsd.org Tue Jun 21 19:03:46 2016 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 09FD5AC574C for ; Tue, 21 Jun 2016 19:03:46 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id E55DE2763 for ; Tue, 21 Jun 2016 19:03:45 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id E4BAFAC574A; Tue, 21 Jun 2016 19:03:45 +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 E43F4AC5749; Tue, 21 Jun 2016 19:03:45 +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 D0AD32762; Tue, 21 Jun 2016 19:03:45 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id CA2F61278; Tue, 21 Jun 2016 19:03:45 +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 9739B1D949; Tue, 21 Jun 2016 19:03:45 +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 rnOn_ixV5EnW; Tue, 21 Jun 2016 19:03:43 +0000 (UTC) To: current@FreeBSD.org, toolchain@FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 157101D93F From: Bryan Drewery Subject: WITH_SYSTEM_COMPILER default on Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <136e515e-b1c0-b5dd-6397-b935f243a9fc@FreeBSD.org> Date: Tue, 21 Jun 2016 12:03:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nBwQGgnalIXeskOhfixod2AekXwBRg51s" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 19:03:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nBwQGgnalIXeskOhfixod2AekXwBRg51s Content-Type: multipart/mixed; boundary="k1l2Ds1fbMp5oSVIcNgTOfswT22wI895w" From: Bryan Drewery To: current@FreeBSD.org, toolchain@FreeBSD.org Message-ID: <136e515e-b1c0-b5dd-6397-b935f243a9fc@FreeBSD.org> Subject: WITH_SYSTEM_COMPILER default on --k1l2Ds1fbMp5oSVIcNgTOfswT22wI895w Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This feature is where the bootstrap compiler in buildworld is not built if the one in /usr/bin/cc matches what would be built. It is very conservative and requires a complete match of major/minor version and the compiler revision (__FreeBSD_cc_version). The only complaint so far about this feature was that when we bumped the compiler revision, too much of clang would rebuild. That was addressed in r301277. I would like to enable this feature by default in head for 11.0. Unless there are any objections I will do so in a few days. --=20 Regards, Bryan Drewery --k1l2Ds1fbMp5oSVIcNgTOfswT22wI895w-- --nBwQGgnalIXeskOhfixod2AekXwBRg51s 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 iQEcBAEBAgAGBQJXaY+OAAoJEDXXcbtuRpfPz1sIAJw2ubZAYnuVxLtO+MEDPYXE R0fii3OAOyP3o/AmJfRC0kwkOf+du0EcOrLH4XbPtQonfR4kTM1v+dEUsybY6SRq AQjdJRnr6GsjX9hl/DwFd3ZCV8afkzoLaxUS56nDus/gY9+DIB0H+hYNNfhehRjM USvgfDqFag5DDz0eaV8OQaz7jjqzQyIcDTnFiSPgxsbZsZTJnoSECCiyzs8q/t8t 7QunWjGfxOB7PE80wTkj1vdFEmkvaUULQDd8rA9DQe5SYXBQ/u899f4Q+CShBfji O8vLAqMBYMUIK3QaIALXMOcFv4gQFEgU779c+j2IiBhDNQpMU08FmsB50re8Kk8= =iBNi -----END PGP SIGNATURE----- --nBwQGgnalIXeskOhfixod2AekXwBRg51s-- From owner-freebsd-current@freebsd.org Tue Jun 21 19:12:08 2016 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 614B7AC59B4 for ; Tue, 21 Jun 2016 19:12:08 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 219D22D02 for ; Tue, 21 Jun 2016 19:12:08 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ob0-x22a.google.com with SMTP id mu6so36606621obc.3 for ; Tue, 21 Jun 2016 12:12:08 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=dGTlzNkDYcv4zTeq93HktarkOz40fm0wqLNX7aChlPU=; b=lw2u9MjGe3Pe0Vv8wscDSKlLcJdcS1/cliBMzgKlXDHaVrMLnZZvPPG0XjxITfad+S 9AiVwGqQxoKiZbOh5KjcWRuQk1slMRq97w3Qmf5QCuEplkhag8V8aExGPJHrxxvqyCvi 78K/PMrIp/ZeaX5lYsxQ5O0oWTHj0mDmqvbXISZvqU2rPAHs3DBd692Dj59Xngz8fQZm 7Cruz0030kAVussOCjc1QaXE/z5mh2PmP8v41yXkrMP0mPxmzWe0RT2lhCOc3MMkEvxO xOumP+WjC1VdbruHk+k49rnMv1VMrIYUATJg4/gx9+JO7Fy1I84wkFrEb7VwnAPl4ukB mZHQ== 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:from :date:message-id:subject:to:cc; bh=dGTlzNkDYcv4zTeq93HktarkOz40fm0wqLNX7aChlPU=; b=GkhSjHoV82iTgUWTKB2/WX/ptJoiYncj7LJHrRhrobsbSQVfeMOuuisZwU2BnHqton SgODSlLjcLgw9QB6LdRuzYfhlZk2vtg3lLwXzW4L+cCzvaBVRSRo2ebggY2FrQsmNiNO sNYquVe7ojRLun6k4svF+ndhxPM8rW9shtEw+WpO1tEyH6ScZ2KXdrY0JzfuPBpFxO4Y BFmSvxKgGV6WvyGM2e2Oa3cMR+gkkIfs72ZXtySAogY0rJ/cGq07YBVpkRlGw8g8tV3O 4KpEFJlVgek5jvIEGv3gg1+Uel5vISCVeT1Z773479i7oTBT36yj41gZmVYaNPzqXPF9 +jXQ== X-Gm-Message-State: ALyK8tKEDXPx8a1x8PUAO5jUXhIc5MGFgznn5H0dsQ3bkx4vuC953DzQtWMZKH18Z9b1K9u5EZubYjoaUSKC9EdA X-Received: by 10.157.1.241 with SMTP id e104mr17336379ote.180.1466536326968; Tue, 21 Jun 2016 12:12:06 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.157.41.209 with HTTP; Tue, 21 Jun 2016 12:12:06 -0700 (PDT) In-Reply-To: References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com> <31205295.d0H0JTrSWj@ralph.baldwin.cx> From: Maxim Sobolev Date: Tue, 21 Jun 2016 12:12:06 -0700 X-Google-Sender-Auth: _JNEjhcJq39PGnBRuIIEtoRMZiQ Message-ID: Subject: Re: console in 11.0-ALPHA4 To: Ed Maste Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 19:12:08 -0000 P.S. On more of IMHO side, I think having simple built in console graphics library is quite important in order for kids to actually explore FreeBSD early. I remember learning my first computer in elementary, with only few KB of RAM it had BASIC interpreter built in and could already do basic graphics primitives with just few lines of code. And that's what we had explored quite early in the learning process. Computers we are running on today are literally million times more powerful that that, both hardware and software-wise, still you should not need to install whole X11 monstrosity to write graphics version of "hello world". In any case if somebody is to add vt(4) support into libvgl, I could probably help with testing that as well as possibly porting it to SDL 2.0. My reduction of interest to maintaining that support has been generally caused by the vesa going out of scope gradually, but with vt it might actually revive it by opening it up for getting it running on most today's x86 hardware and smaller arm systems as well. -Max On Tue, Jun 21, 2016 at 11:33 AM, Maxim Sobolev wrote: > Ed, > > For once, we have pretty good VGL support in the libSDL, at least version > 1.x has been tested and seems to be building/working fine with > sc(4)+vesa(4) on supported hardware/VMs. > > http://libsdl.org/download-1.2.php > > So pretty much any application built against SDL 1.2 library should work. > Unless it uses some specific X11 stuff directly that is. > > For what it's worth, I also have direct vgl support in my pet project > here: https://github.com/sobomax/digger ) > > -Max > > On Tue, Jun 21, 2016 at 6:29 AM, Ed Maste wrote: > >> On the topic of vgl(3) specifically, in October 2014 I wrote on this list: >> >> > vgl(3) is a graphics library for syscons(4) that provides some basic >> > graphics operations (e.g. some mode setting, bitmaps, boxes, >> > ellipses). Right now it does not support the newer vt(4) console. >> > >> > In order to help determine the priority of a porting effort to add >> > vt(4) support I'd like to better understand where vgl is being used >> > now. I'd be interested in hearing about both open source software >> > using vgl as well as proprietary or internal applications. So if >> > you're using vgl I'd appreciate a follow up (in private is fine) with >> > a brief description of your use case. >> >> That received exactly one private reply, where it was pointed out that >> dosbox is an example consumer. Nobody replied to say they actually use >> vgl(3). >> >> I will post a followup to -stable to ask the same question, but >> please, let me know if you use vgl(3) in open source or proprietary >> software. >> _______________________________________________ >> 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 >> " >> >> > > > -- > Maksym Sobolyev > Sippy Software, Inc. > Internet Telephony (VoIP) Experts > Tel (Canada): +1-778-783-0474 > Tel (Toll-Free): +1-855-747-7779 > Fax: +1-866-857-6942 > Web: http://www.sippysoft.com > MSN: sales@sippysoft.com > Skype: SippySoft > From owner-freebsd-current@freebsd.org Tue Jun 21 19:48:01 2016 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 97BE7AC5325 for ; Tue, 21 Jun 2016 19:48:01 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003: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 57C261FD6 for ; Tue, 21 Jun 2016 19:48:01 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x233.google.com with SMTP id s66so946625oif.1 for ; Tue, 21 Jun 2016 12:48:01 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=BWu424J08XNTOZZDYk8pJct/4YcWXKZL5/IlcVjBLww=; b=iJPKziUxHO0tsRC/zzIVAVu38nJ8yRoDGgld62ptXQbu6JV7h5Are7VbL5UctnPF5v oKdHL616cNCASpZU10m7vElATRjPg601xJ2qxxDuYk5aB1qvpDw/NY/Dg/J7Xxez/CO8 Vh9cO/9Q6wEJH1jCiJh3yQHVx5mlBvHCrg/R9ThvqwFVRZSdHCO0ehTAjFNeAFphPQRy FsFGQpjP8FZVU6IPT3Hdg71Kmke9nQom4A0NrovudgYvTbA0NzT3Y++/xcGvq3eMpOAU DXY1mtV+JO8PLBigpRccrC8I9Xt4s9BKN0x+/ZdBjgc1FEOaYfEBuM3DJDxvt+SAxHtm DnTg== 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:from :date:message-id:subject:to:cc; bh=BWu424J08XNTOZZDYk8pJct/4YcWXKZL5/IlcVjBLww=; b=dQom8qQZkc4A3uCjIj1sirQbk0nthwuro4cw05KAzH/a5hp1tDhiY6Gai2ImsSVXBF NMuRycWru1TJwlcsUu+f0+s66mreL/K0m9E36QgKxngbTItP43mJqp8y3VC2uTcj+zr1 uSCp2LEPMiMCEra8OmozrKk7H9/n0zVnXDu1IcTke21adXDen9O20U9YVI/q2OVJqTts B61GbCunTftwJGyyEL0Vj+lpj2lZlFcH33S0JQVaq7nFdtxwmAvrFcl7Bvsa7h6Ldwyl eVBbVIhi1SVhnG4ibIybLyJQPo6ZOHCPmAdVJr8ssoJ53TH6tL0BGe1yyzpOo/D661+K mUWQ== X-Gm-Message-State: ALyK8tLYkXa11Xef0ZstGpmW/SX35ldPKaa3uhYOC+lFk0I1R3+0uwzY9xKyOzDI0Po3RkgKY4t69kgukBRUfY7j X-Received: by 10.202.240.11 with SMTP id o11mr67831oih.45.1466538480657; Tue, 21 Jun 2016 12:48:00 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.157.41.209 with HTTP; Tue, 21 Jun 2016 12:48:00 -0700 (PDT) In-Reply-To: <1603235.2ShtoCfSqO@ralph.baldwin.cx> References: <20140627125613.GT93733@kib.kiev.ua> <1603235.2ShtoCfSqO@ralph.baldwin.cx> From: Maxim Sobolev Date: Tue, 21 Jun 2016 12:48:00 -0700 X-Google-Sender-Auth: TGqbUJWsBeRDE3jS2pTvxu0J558 Message-ID: Subject: Re: PostgreSQL performance on FreeBSD To: John Baldwin Cc: Adrian Chadd , Konstantin Belousov , Alan Somers , Alan Cox , Alan Cox , freebsd-current , performance@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 19:48:01 -0000 Thanks, Konstantin for the great work, we are definitely looking forward to get all those improvements to be part of the default FreeBSD kernel/port. Would be nice if you can post an update some day later as to what's integrated and what's not. Just in case, I've opened #14206 with PG to switch us to using POSIX semaphores by default. Apart from the mentioned performance benefits, SYSV semaphores are PITA to deal with as they come in very limited quantities by default. Also they might stay around if PG dies/gets nuked and prevent it from starting again due to overflow. We've got some quite ugly code to clean up those using ipcrm(1) in our build scripts to deal with just that. I am happy that code could be retired now. -Maxim On Fri, Jun 3, 2016 at 11:53 AM, John Baldwin wrote: > On Friday, June 03, 2016 11:29:03 AM Adrian Chadd wrote: > > On 3 June 2016 at 11:27, Adrian Chadd wrote: > > > > > That and the other NUMA stuff is something to address in -12. > > > > And, I completely welcome continued development in NUMA scaling in > > combination with discussion. The iterator changes I committed are a > > more generic version of a patch people were applying on top of -10 and > > -head for at least what, three years now? Maybe more if -9 also just > > did round-robin and not first-touch? > > 8 and 9 did first-touch. Only 10 did round-robin. > > -- > 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 Jun 21 20:36:21 2016 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 A290AAC51EA for ; Tue, 21 Jun 2016 20:36:21 +0000 (UTC) (envelope-from merljin@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 6C4A426BA for ; Tue, 21 Jun 2016 20:36:21 +0000 (UTC) (envelope-from merljin@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id f6so13429264ith.0 for ; Tue, 21 Jun 2016 13:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=hQusBqy+CcF4HgNadVcH2SpMGwz+dK3D17xnu/9IQZY=; b=KkQ/QFDKLEF9wvayxm0TRhGjWCQeTh1voBlno9DoyQb+kAP08q49ZrEFqXLMs6VBvp wFl/7usTZu2r6Ak8geCCtHnOQ7mErIjdTNq6ZSG40I1jXyKzHbU4btOmvvo29e4e7ABb MVmhB+BpImBaw7sUD8Fx86VraCgkNnzRdGbntf6UWK4l/S9BQr72INMr7KVBZC9EL6LX qEI/uIFYSnoV392A/n+VxPRPAZsa0+31IL6zz9v4JzCU0yxqMftQStIh++cTI4WhSO/J 6uySQGk8c246npwtJejguuaUOCU9KtaZW5yNvfQ1/bBXn3rNE2kmvAseqAdJcqLCqwpN W9cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hQusBqy+CcF4HgNadVcH2SpMGwz+dK3D17xnu/9IQZY=; b=P5B69i0UZ/JmkQBnEw8MQSRk5CikOJaJqnTG6+K5YclGY+rf7QPXmFEjjcyhoSvfvE W1rp/i2hPL3k57QIsW8V32KxhomVal5rYeLM2BKy2rbOS0oXH1jWltLCfZDi4A5s/Aog yTqrGSrBwJqA0HyPi738qBMsOrQo1/JQAf2NcoSjTyHXgrl/bbkXJyfeZ7Ryl3DxGpey 4Gc8E+0SJ7vmljzyM4lQC3nUua2mhcjyu4yY+bFdc3gyAgCqVLK1bx0qL6eGgx9Sr1Vv 2PRWnem5ywnFKJiJNmkyBdQe4oky+Y9i+1/fWLxeKPfn3gNoliQJL3B4VSQDLYEbaxSV jsdw== X-Gm-Message-State: ALyK8tIjgZOLe+YFpgwBpDGMM8aqp0rttvlJCg8pvEKOUx2G9MF+c6j6WUvC84OM/DIq+/C4SngIqAQEBK3qIQ== X-Received: by 10.36.76.71 with SMTP id a68mr9054943itb.77.1466541380804; Tue, 21 Jun 2016 13:36:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.81.3 with HTTP; Tue, 21 Jun 2016 13:36:20 -0700 (PDT) From: Merljin Date: Tue, 21 Jun 2016 22:36:20 +0200 Message-ID: Subject: ALPHA4-amd64-r301975 UFS crashes on VMware Wks To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 20:36:21 -0000 Hello community, ( sorry for my bad english lang skills ) I would like to report problem with FreeBSD-11.0-ALPHA4-amd64-20160617-r301975. After clean install, while trying to install any binary packages with pkg (ex: pkg install xorg ) Kernel crashes happen usually during any disk intensive operation. ( pkg upgrade wanted to upgrade two packages - get text and python27 ) Crash occured immediatelly after confirming pkg to continue ( y/N ) Jun 21 18:53:58 Auriga pkg: gettext-runtime upgraded: 0.19.7 -> 0.19.8.1 Jun 21 18:53:59 Auriga kernel: lock order reversal: Jun 21 18:53:59 Auriga kernel: 1st 0xfffff80033631068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 Jun 21 18:53:59 Auriga kernel: 2nd 0xfffffe00f625e170 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 Jun 21 18:53:59 Auriga kernel: 3rd 0xfffff80033499068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 Jun 21 18:53:59 Auriga kernel: stack backtrace: Jun 21 18:53:59 Auriga kernel: #0 0xffffffff80aa7320 at witness_debugger+0x70 Jun 21 18:53:59 Auriga kernel: #1 0xffffffff80aa7214 at witness_checkorder+0xe54 Jun 21 18:53:59 Auriga kernel: #2 0xffffffff80a206d2 at __lockmgr_args+0x4c2 Jun 21 18:53:59 Auriga kernel: #3 0xffffffff80d09426 at ffs_lock+0xa6 Jun 21 18:53:59 Auriga kernel: #4 0xffffffff81014f2a at VOP_LOCK1_APV+0xea Jun 21 18:53:59 Auriga kernel: #5 0xffffffff80b17b8a at _vn_lock+0x9a Jun 21 18:53:59 Auriga kernel: #6 0xffffffff80b07fb3 at vget+0x63 Jun 21 18:53:59 Auriga kernel: #7 0xffffffff80afa84c at vfs_hash_get+0xcc Jun 21 18:53:59 Auriga kernel: #8 0xffffffff80d05130 at ffs_vgetf+0x40 Jun 21 18:53:59 Auriga kernel: #9 0xffffffff80cfca21 at softdep_sync_buf+0xb51 Jun 21 18:53:59 Auriga kernel: #10 0xffffffff80d0a016 at ffs_syncvnode+0x256 Jun 21 18:53:59 Auriga kernel: #11 0xffffffff80ce0d83 at ffs_truncate+0x8d3 Jun 21 18:53:59 Auriga kernel: #12 0xffffffff80d11741 at ufs_direnter+0x681 Jun 21 18:53:59 Auriga kernel: #13 0xffffffff80d1aa59 at ufs_makeinode+0x5e9 Jun 21 18:53:59 Auriga kernel: #14 0xffffffff80d165e3 at ufs_create+0x33 Jun 21 18:53:59 Auriga kernel: #15 0xffffffff8101281b at VOP_CREATE_APV+0xdb Jun 21 18:53:59 Auriga kernel: #16 0xffffffff80b173d8 at vn_open_cred+0x2f8 Jun 21 18:53:59 Auriga kernel: #17 0xffffffff80b1075c at kern_openat+0x25c Jun 21 18:54:01 Auriga pkg: python27 upgraded: 2.7.11_2 -> 2.7.11_3 After executing "pkg install xorg" - three crashes happened during installation. Running on VMware 12 Workstation. FreeBSD 10.3 RELEASE, Debian Linux, Windows running there without any problems. Is possible that filesystem is damaged/inconsistent after these crashes ? data lost etc ? Karel ( FBSD newbie ) From owner-freebsd-current@freebsd.org Tue Jun 21 20:36:56 2016 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 4B451AC527C for ; Tue, 21 Jun 2016 20:36:56 +0000 (UTC) (envelope-from ken@kdm.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 369A828C2 for ; Tue, 21 Jun 2016 20:36:56 +0000 (UTC) (envelope-from ken@kdm.org) Received: by mailman.ysv.freebsd.org (Postfix) id 328FAAC5279; Tue, 21 Jun 2016 20:36:56 +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 321C0AC5278; Tue, 21 Jun 2016 20:36:56 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D874528BF; Tue, 21 Jun 2016 20:36:55 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id u5LKaqpR090893 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jun 2016 16:36:53 -0400 (EDT) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id u5LKaqpp090892; Tue, 21 Jun 2016 16:36:52 -0400 (EDT) (envelope-from ken) Date: Tue, 21 Jun 2016 16:36:52 -0400 From: "Kenneth D. Merry" To: current@freebsd.org Cc: fs@freebsd.org Subject: Heads Up: struct disk KBI change Message-ID: <20160621203652.GA90745@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 21 Jun 2016 16:36:54 -0400 (EDT) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 20:36:56 -0000 This will break binary compatibility for loadable modules that depend on struct disk. DISK_VERSION has been bumped, and I bumped __FreeBSD_version in a subsequent change. So, if you have module that uses struct disk, you'll need to recompile against the latest version of head. Ken ----- Forwarded message from "Kenneth D. Merry" ----- Date: Tue, 21 Jun 2016 20:18:19 +0000 (UTC) From: "Kenneth D. Merry" To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r302069 - head/sys/geom Author: ken Date: Tue Jun 21 20:18:19 2016 New Revision: 302069 URL: https://svnweb.freebsd.org/changeset/base/302069 Log: Fix a bug that caused da(4) instances to hang around after the underlying device is gone. The problem was that when disk_gone() is called, if the GEOM disk creation process has not yet happened, the withering process couldn't start. We didn't record any state in the GEOM disk code, and so the d_gone() callback to the da(4) driver never happened. The solution is to track the state of the creation process, and initiate the withering process from g_disk_create() if the disk is being created. This change does add fields to struct disk, and so I have bumped DISK_VERSION. geom_disk.c: Track where we are in the disk creation process, and check to see whether our underlying disk has gone away or not. In disk_gone(), set a new d_goneflag variable that g_disk_create() can check to see if it needs to clean up the disk instance. geom_disk.h: Add a mutex to struct disk (for internal use) disk init level, and a gone flag. Bump DISK_VERSION because the size of struct disk has changed and fields have been added at the beginning. Sponsored by: Spectra Logic Approved by: re (marius) Modified: head/sys/geom/geom_disk.c head/sys/geom/geom_disk.h ----- End forwarded message ----- -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@freebsd.org Tue Jun 21 21:31:14 2016 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 528C1AC5F4B; Tue, 21 Jun 2016 21:31:14 +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 3FF6A181B; Tue, 21 Jun 2016 21:31:14 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 345BD1CE4; Tue, 21 Jun 2016 21:31:14 +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 CCD501DD14; Tue, 21 Jun 2016 21:31:13 +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 2qG2MMa5fIap; Tue, 21 Jun 2016 21:31:09 +0000 (UTC) Subject: Re: libpam.so lost in update to 11.0-ALPHA3 DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 1EF7F1DD0E To: FreeBSD Current References: <7D63E77B-0D82-44D3-9A1C-233ACA8C62D0@alumni.tu-berlin.de> <2716b37a-0ccb-e5b4-bc6b-9751fb6e1174@FreeBSD.org> Cc: "pkgbase@freebsd.org" From: Bryan Drewery Organization: FreeBSD Message-ID: <338f3146-b0bf-fd7e-accb-b268a3b32af9@FreeBSD.org> Date: Tue, 21 Jun 2016 14:31:06 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <2716b37a-0ccb-e5b4-bc6b-9751fb6e1174@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 21:31:14 -0000 On 6/16/16 3:35 PM, Bryan Drewery wrote: > On 6/16/16 11:39 AM, Florian Ermisch wrote: >> >> >> Am 14. Juni 2016 13:36:32 MESZ, schrieb Ben Woods = : >>> On Tuesday, 14 June 2016, Pavel Timofeev wrote: >>> >>>> >>>> 14 =D0=B8=D1=8E=D0=BD=D1=8F 2016 =D0=B3. 10:37 =D0=BF=D0=BE=D0=BB=D1= =8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Ben Woods" >>> > =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BB: >>>>> >>>>> On 14 June 2016 at 09:11, Ren=C3=A9 Ladan >>> > wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I updated my pkgbase installation (11.0-amd64 from a few weeks >>> ago) to >>>>>> 11.0-ALPHA3. Building and installing went fine but it turns out >>> that >>>>>> libpam.so* is lost in the update (both the symlink and the >>> actual so, >>>>>> currently so.6) : >>>>>> >>>>>> # pkg upgrade >>>>>> # pkg autoremove >>>>>> <>> one >>>>>> version lower) >>>>>> << yes, I forgot to run mergemaster>> >>>>>> # reboot >>>>>> <>> still fine) >>>>>> >>>>>> Is this a known bug? >>>>>> >>>>>> Regards, >>>>>> Ren=C3=A9 >>>>>> >>>>> >>>>> Michael Lucas mentioned on twitter a few days ago that pam was >>> broken >>>>> recently in FreeBSD current. >>>>> >>>>> Michael: was this a problem with libpam.so going missing? Were you >>> using >>>>> pkgbase, or is this an issue with the normal build/install system >>> also? >>>>> >>>>> Regards, >>>>> Ben >>>>> >>>>> -- >>>> >>>> Hi! >>>> I have the same problem with normal build/install system. >>>> >>> >>> Ok, thanks for the feedback. >>> >>> Bringing in the FreeBSD-current@ mailing list as it is not a problem >>> with >>> PkgBase, but with 11-current. >>> >>> Regards, >>> Ben >>> >> On my laptop running a few weeks old CURRENT sudo >> just broke after a `pkg upgrade`. The missing lib it's=20 >> complaining about is libpam.so.6 but when built from >> ports it's linked against libpam.so.5. >> >=20 >=20 > Packages built after base r301892 will be fixed. >=20 >=20 Actually the case of libpam.so.6 needed by sudo and your system has libpam.so.5 is just part of running head and using head packages. The head packages are built every 2 days from the latest head at that time. So packages were built using the bumped libpam.so.6 but your system didn't yet have that so sudo failed to work. The only good way to fix this is to not be splitting our dependencies up so that some are not in the package set. Meaning, not having base libraries and moving everything into the same ports/pkg system. Which by the way is *not* what pkgbase does in its current form since we're using 2 repositories that have different dependencies between them. We would need a single repository, or not be removing old versions from both and pkg supporting multiple versions from remotes. I don't see the first happening due to secteam/re needs of controlling the base system builds, and I don't see the latter happening soon. The __FreeBSD_version bump in r301892 only fixed the sudo package still wanting libpam.so.5 rather than the bumped libpam.so.6. Packages on head have several issues. Technically after upgrading your world/kernel the only safe thing to do with packages is to reinstall all of them to ensure they are all ABI-compatible with pkg upgrade -f. Even then because of the 2 day delay there is risk of not having it all be compatible. Pkg could use more logic to handle all of this better, perhaps by comparing __FreeBSD_version numbers of local and remote and not upgrading past it. I don't know. --=20 Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Tue Jun 21 22:11:23 2016 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 4FF0FAC571B for ; Tue, 21 Jun 2016 22:11:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 EB5A92B28 for ; Tue, 21 Jun 2016 22:11:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14596 invoked from network); 21 Jun 2016 22:11:56 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 21 Jun 2016 22:11:56 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 21 Jun 2016 18:11:25 -0400 (EDT) Received: (qmail 3426 invoked from network); 21 Jun 2016 22:11:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jun 2016 22:11:25 -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.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 904D51C4079; Tue, 21 Jun 2016 15:11:15 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: WITH_SYSTEM_COMPILER default on Date: Tue, 21 Jun 2016 15:11:18 -0700 Message-Id: <39C98FFD-B0BB-4F25-A1D1-2447A2FDDFBD@dsl-only.net> Cc: freebsd-arm , FreeBSD PowerPC ML To: Bryan Drewery , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 22:11:23 -0000 Bryan Drewery bdrewery at FreeBSD.org wrote on Tue Jun 21 19:03:46 UTC = 2016 : > This feature is where the bootstrap compiler in buildworld is not = built > if the one in /usr/bin/cc matches what would be built. It is very > conservative and requires a complete match of major/minor version and > the compiler revision (__FreeBSD_cc_version). >=20 > The only complaint so far about this feature was that when we bumped = the > compiler revision, too much of clang would rebuild. That was = addressed > in r301277. >=20 > I would like to enable this feature by default in head for 11.0. >=20 > Unless there are any objections I will do so in a few days. >=20 > --=20 > Regards, > Bryan Drewery I've only been using WITH_SYSTEM_COMPILER=3D for system-clang based = builds with the host matching TARGET_ARCH ("self hosted"). For xtoolchain use (self-hosted or not) I've been using in my src.conf = files for such contexts:=20 WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D For cross builds (all being amd64 -> something else, such as armv6, = powerpc64, or powerpc) based on using some build of the system clang = 3.8.0 I've been using: WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D As I understand the history the paths for finding tools, headers, etc. = built into the clang cross compiler were not necessarily the same as for = the live the system compiler that has paths appropriate specifically to = self-hosting. This helped avoid getting the wrong versions of files = involved. This was true despite the normal clang code generation being able to = target other architectures. As for self-hosted system-clang based builds I've been using: #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D WITH_BINUTILS_BOOTSTRAP=3D #WITH_CLANG_BOOTSTRAP=3D (So in this case I've left some things implicit in operation.) As stands I'll not notice the SYSTEM_COMPILER default's consequences = because I'm always explicit about WITH vs. WITHOUT for SYSTM_COMPILER. = If you want some sort of experiment(s), let me know. But I only currently have an amd64 context and a rpi2 armv6 context. The = dual-proessor, each dual-core powerpc64 was much faster at self-hosted = xtoolchain builds compared to any self-hosted rpi2 build but I do not = have access to the powerpc family for now. Self-hosted amd64 xtoolchain = builds do not work yet for normal settings: duplicate declarations tend = to stop the builds if one leaves on the warnings-as-errors status for = buildkernel. (At least last that I tried such.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Jun 21 22:30:52 2016 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 5A610AC5C0E for ; Tue, 21 Jun 2016 22:30:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 0DD391732 for ; Tue, 21 Jun 2016 22:30:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2324 invoked from network); 21 Jun 2016 22:31:26 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 21 Jun 2016 22:31:26 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 21 Jun 2016 18:31:34 -0400 (EDT) Received: (qmail 14603 invoked from network); 21 Jun 2016 22:31:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jun 2016 22:31:34 -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.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 0FE761C408D; Tue, 21 Jun 2016 15:30:45 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] Date: Tue, 21 Jun 2016 15:30:47 -0700 Message-Id: Cc: FreeBSD Toolchain To: Ian Lepore , freebsd-arm , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 22:30:52 -0000 Ian Lepore ian at freebsd.org wrote on Tue Jun 21 17:55:28 UTC 2016 : > On Tue, 2016-06-21 at 08:11 -0300, Otac=C3=ADlio wrote: > > Em 21/06/2016 07:33, Keith White escreveu: > > > In an earlier message Ian said that he thought he knew what the > > > problem was...=20 > >=20 > > Here the problem occurs when using wifi. I do not have tested wired=20= > > because I don't have a cable here. > >=20 > >=20 > > []'s > >=20 > > -Otacilio >=20 > The wifi alignment fault should be fixed as of r302064. Sorry it took > so long. >=20 > -- Ian >=20 FYI: I've not had any -r301975 problems with WiFi on my rpi2. But I cross build for TARGET_ARCH=3Darmv6 with: > XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 > XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 (And similarly for self-hosted.) It may be that the -march and/or -mcpu = matter to the code generation and explain my lack of problems. The builds also have INVARIANTS and WITNESS off. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Jun 21 22:45:20 2016 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 1A5E9AC4033; Tue, 21 Jun 2016 22:45:20 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "courriel.site.uottawa.ca", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD0051EA6; Tue, 21 Jun 2016 22:45:18 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from [10.0.2.15] (ppp-66-186-88-176.vianet.ca [66.186.88.176]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id u5LMj8fj081847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jun 2016 18:45:09 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Tue, 21 Jun 2016 18:45:07 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Ian Lepore cc: =?ISO-8859-15?Q?Otac=EDlio?= , Mark Millard , freebsd-arm , FreeBSD Current Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] In-Reply-To: <1466531719.34556.72.camel@freebsd.org> Message-ID: References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> <22fe5f7f-6153-e092-c410-eddb1431a78a@bsd.com.br> <1466531719.34556.72.camel@freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 22:45:20 -0000 On Tue, 21 Jun 2016, Ian Lepore wrote: > On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: >> Em 21/06/2016 07:33, Keith White escreveu: >>> In an earlier message Ian said that he thought he knew what the >>> problem was... >> >> Here the problem occurs when using wifi. I do not have tested wired >> because I don't have a cable here. >> >> >> []'s >> >> -Otacilio > > The wifi alignment fault should be fixed as of r302064. Sorry it took > so long. > > -- Ian Many thanks Ian! Yes, this has fixed the problem. No more panics on ssh to rpi-b. ...keith From owner-freebsd-current@freebsd.org Tue Jun 21 23:13:59 2016 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 3CB5AAC4750 for ; Tue, 21 Jun 2016 23:13:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 0FB562C2C for ; Tue, 21 Jun 2016 23:13:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: e0ae30ae-3805-11e6-a0ff-e511cd071b9b X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 21 Jun 2016 23:14:17 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u5LNDoxg006862; Tue, 21 Jun 2016 17:13:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1466550830.34556.73.camel@freebsd.org> Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] From: Ian Lepore To: Mark Millard , freebsd-arm , FreeBSD Current Cc: FreeBSD Toolchain Date: Tue, 21 Jun 2016 17:13:50 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 23:13:59 -0000 On Tue, 2016-06-21 at 15:30 -0700, Mark Millard wrote: > Ian Lepore ian at freebsd.org wrote on Tue Jun 21 17:55:28 UTC 2016 > : > > > On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: > > > Em 21/06/2016 07:33, Keith White escreveu: > > > > In an earlier message Ian said that he thought he knew what the > > > > problem was... > > > > > > Here the problem occurs when using wifi. I do not have tested > > > wired > > > because I don't have a cable here. > > > > > > > > > []'s > > > > > > -Otacilio > > > > The wifi alignment fault should be fixed as of r302064. Sorry it > > took > > so long. > > > > -- Ian > > > > FYI: I've not had any -r301975 problems with WiFi on my rpi2. > > But I cross build for TARGET_ARCH=armv6 with: > > > XCFLAGS+= -march=armv7-a -mcpu=cortex-a7 > > XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7 > > (And similarly for self-hosted.) It may be that the -march and/or > -mcpu matter to the code generation and explain my lack of problems. > > The builds also have INVARIANTS and WITNESS off. > > === > Mark Millard > markmi at dsl-only.net INVARIANTS being on was one of the things required to trigger the alignment fault. -- Ian From owner-freebsd-current@freebsd.org Tue Jun 21 18:33:11 2016 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 97325AC5093 for ; Tue, 21 Jun 2016 18:33:11 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 60262126D for ; Tue, 21 Jun 2016 18:33:11 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ob0-x234.google.com with SMTP id xn17so35639603obc.0 for ; Tue, 21 Jun 2016 11:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iH0+foetnWc2ZvEipbm3eGmC8XM1vXHYL9SkHkZ/m5U=; b=ZhhISSqoqOv3sS1Vwed9UuMTGinktimLD3w70WMnTqhcdJmsUHg9vo3JUb3NMi4hJZ /f5weyhn1Z50HFQqfNZjgy/MlPSoT4DBqJoi8XtW/GMBXe2yzsDsCt8IpHTvAt4Cm8lH oCCJa5/qKyrKPvkl4OQsKQcDECOT4wUx3KA9NgkWOl4lzsOPmPuwq2kI2kzN7jYhlPzz 5/j11gESD5iSSImjPLEHL5W73m4jerr5FNojIF1ryETqQvYFETnJMzObRmwx1qavDLig AZrrwMg6h0YL3L2uz122SNQxwLIdbRwMdK1DzUln81Do07kWRWPmNjrEbYxQOCV4NWTY qQpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iH0+foetnWc2ZvEipbm3eGmC8XM1vXHYL9SkHkZ/m5U=; b=RDOv+i429KZiOfBn87TZLFDBNnagnb0lkOGpC2UkGlecNQEr/fk8R8iUCvfMy7JqIx S3zsbIo3g+7m0dgQSe2bHBigczgxCawMBuPnPg7ZSZwwHAcKSrscgfPy0gR/UBWjQJ8r RO1mUnkmOwY2o2+23PMJbx/TNwbj7hNqLVOD5KlrmHr1K5EYjX4YnqjuWU3zx2m/tbWh byrIMAMZlsWyM+EK5umGotj/+Dn0JooYDO/nKwHNLMv0lXFu6C1ibW3RdYBM4gh9blQQ i8XwQFgrJ05RqcQX9vk11YbHqoz4dBnahekbydG8qpxKek1OtWI6wS1sncXLM0K/Xd9A ww6w== X-Gm-Message-State: ALyK8tIF5fqffDhbgIaV+5RwrgKUfBevKmCjS951lTD2YEmmXo7VVF+Uu8buLDe68hOXls1p6c/w+nA5Z861Q0ML X-Received: by 10.157.1.241 with SMTP id e104mr17164192ote.180.1466533990495; Tue, 21 Jun 2016 11:33:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.209 with HTTP; Tue, 21 Jun 2016 11:33:09 -0700 (PDT) In-Reply-To: References: <57680D69.7030309@gmail.com> <576857F3.5040102@gmail.com> <31205295.d0H0JTrSWj@ralph.baldwin.cx> From: Maxim Sobolev Date: Tue, 21 Jun 2016 11:33:09 -0700 Message-ID: Subject: Re: console in 11.0-ALPHA4 To: Ed Maste Cc: FreeBSD Current X-Mailman-Approved-At: Wed, 22 Jun 2016 00:33:26 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 18:33:11 -0000 Ed, For once, we have pretty good VGL support in the libSDL, at least version 1.x has been tested and seems to be building/working fine with sc(4)+vesa(4) on supported hardware/VMs. http://libsdl.org/download-1.2.php So pretty much any application built against SDL 1.2 library should work. Unless it uses some specific X11 stuff directly that is. For what it's worth, I also have direct vgl support in my pet project here: https://github.com/sobomax/digger ) -Max On Tue, Jun 21, 2016 at 6:29 AM, Ed Maste wrote: > On the topic of vgl(3) specifically, in October 2014 I wrote on this list: > > > vgl(3) is a graphics library for syscons(4) that provides some basic > > graphics operations (e.g. some mode setting, bitmaps, boxes, > > ellipses). Right now it does not support the newer vt(4) console. > > > > In order to help determine the priority of a porting effort to add > > vt(4) support I'd like to better understand where vgl is being used > > now. I'd be interested in hearing about both open source software > > using vgl as well as proprietary or internal applications. So if > > you're using vgl I'd appreciate a follow up (in private is fine) with > > a brief description of your use case. > > That received exactly one private reply, where it was pointed out that > dosbox is an example consumer. Nobody replied to say they actually use > vgl(3). > > I will post a followup to -stable to ask the same question, but > please, let me know if you use vgl(3) in open source or proprietary > software. > _______________________________________________ > 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" > > -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-current@freebsd.org Tue Jun 21 22:32:39 2016 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 B68B9AC5DC8 for ; Tue, 21 Jun 2016 22:32:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A318B1B1F for ; Tue, 21 Jun 2016 22:32:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u5LM4H6d033762 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 21 Jun 2016 15:04:17 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u5LM4Hiw033761 for freebsd-current@freebsd.org; Tue, 21 Jun 2016 15:04:17 -0700 (PDT) (envelope-from sgk) Date: Tue, 21 Jun 2016 15:04:17 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Subject: panic in g_vfs_strategy() Message-ID: <20160621220417.GA33717@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Mailman-Approved-At: Wed, 22 Jun 2016 00:34:14 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Jun 2016 22:32:39 -0000 After a forced umount of a msdos filesystem, I received a panic. I have the kernel and vmcore. The first hundred or so lines of core.txt.4 follow my .sig. -- Steve troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.4 Tue Jun 21 14:32:29 PDT 2016 FreeBSD troutmask.apl.washington.edu 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r299122: Thu May 5 10:03:31 PDT 2016 kargl@troutmask.apl.washington.edu:/data/obj/usr/src/sys/SPEW amd64 panic: general protection fault Unread portion of the kernel message buffer: Device da1s1 went missing before all of the data could be written to it; expect data loss. Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 10 instruction pointer = 0x20:0xffffffff8050c4a1 stack pointer = 0x28:0xfffffe0239276fc0 frame pointer = 0x28:0xfffffe0239277000 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 30604 (sendmail) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0239276c60 vpanic() at vpanic+0x182/frame 0xfffffe0239276ce0 panic() at panic+0x43/frame 0xfffffe0239276d40 trap_fatal() at trap_fatal+0x351/frame 0xfffffe0239276da0 trap() at trap+0x6d1/frame 0xfffffe0239276f00 calltrap() at calltrap+0x8/frame 0xfffffe0239276f00 --- trap 0x9, rip = 0xffffffff8050c4a1, rsp = 0xfffffe0239276fd0, rbp = 0xfffffe0239277000 --- g_vfs_strategy() at g_vfs_strategy+0x31/frame 0xfffffe0239277000 bufwrite() at bufwrite+0x1da/frame 0xfffffe0239277040 vop_stdfsync() at vop_stdfsync+0x220/frame 0xfffffe02392770b0 devfs_fsync() at devfs_fsync+0x67/frame 0xfffffe02392770e0 VOP_FSYNC_APV() at VOP_FSYNC_APV+0x80/frame 0xfffffe0239277110 bufsync() at bufsync+0x35/frame 0xfffffe0239277140 bufobj_invalbuf() at bufobj_invalbuf+0x126/frame 0xfffffe02392771b0 vgonel() at vgonel+0x17e/frame 0xfffffe0239277220 vgone() at vgone+0x4c/frame 0xfffffe0239277250 devfs_delete() at devfs_delete+0x1f3/frame 0xfffffe02392772c0 devfs_populate_loop() at devfs_populate_loop+0x20f/frame 0xfffffe0239277320 devfs_populate() at devfs_populate+0x2a/frame 0xfffffe0239277340 devfs_populate_vp() at devfs_populate_vp+0x9b/frame 0xfffffe0239277390 devfs_lookup() at devfs_lookup+0x2c/frame 0xfffffe02392774a0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x7a/frame 0xfffffe02392774d0 lookup() at lookup+0x561/frame 0xfffffe0239277560 namei() at namei+0x3ef/frame 0xfffffe0239277620 vn_open_cred() at vn_open_cred+0x26c/frame 0xfffffe0239277790 kern_openat() at kern_openat+0x220/frame 0xfffffe0239277910 amd64_syscall() at amd64_syscall+0x33f/frame 0xfffffe0239277a30 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0239277a30 --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x2015336da, rsp = 0x7fffffffb328, rbp = 0x7fffffffb410 --- Uptime: 7d21h3m52s Dumping 1033 out of 8143 MB:..2%..11%..21%..31%..41%..52%..61%..72%..81%..92% #0 doadump (textdump=1) at pcpu.h:221 221 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:221 #1 0xffffffff8057e7f2 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:366 #2 0xffffffff8057ec6b in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff8057eaa3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:690 #4 0xffffffff807e5ab1 in trap_fatal (frame=0xfffffe0239276f10, eva=0) at /usr/src/sys/amd64/amd64/trap.c:841 #5 0xffffffff807e5741 in trap (frame=0xfffffe0239276f10) at /usr/src/sys/amd64/amd64/trap.c:203 #6 0xffffffff807cc133 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #7 0xffffffff8050c4a1 in g_vfs_strategy (bo=0xfffff801303510d0, bp=0xfffffe01f05637c0) at atomic.h:184 #8 0xffffffff8060d41a in bufwrite (bp=0xfffffe01f05637c0) at buf.h:405 #9 0xffffffff8061a750 in vop_stdfsync (ap=0xfffffe0239277120) at /usr/src/sys/kern/vfs_default.c:695 #10 0xffffffff8047d637 in devfs_fsync (ap=0xfffffe0239277120) at /usr/src/sys/fs/devfs/devfs_vnops.c:694 #11 0xffffffff8084d920 in VOP_FSYNC_APV (vop=, a=) at vnode_if.c:1331 #12 0xffffffff8060d535 in bufsync (bo=, waitfor=) at vnode_if.h:549 #13 0xffffffff80627686 in bufobj_invalbuf (bo=, flags=, slpflag=, slptimeo=) at /usr/src/sys/kern/vfs_subr.c:1539 #14 0xffffffff8062a20e in vgonel (vp=) at /usr/src/sys/kern/vfs_subr.c:1617 #15 0xffffffff8062a6bc in vgone (vp=0xfffff80130351000) at /usr/src/sys/kern/vfs_subr.c:3079 #16 0xffffffff80477e33 in devfs_delete (dm=0xfffff800088d6080, de=0xfffff8022d551500, flags=0) at /usr/src/sys/fs/devfs/devfs_devs.c:397 #17 0xffffffff804782df in devfs_populate_loop (dm=, cleanup=) at /usr/src/sys/fs/devfs/devfs_devs.c:535 #18 0xffffffff804780ba in devfs_populate (dm=) at /usr/src/sys/fs/devfs/devfs_devs.c:662 #19 0xffffffff8047cd1b in devfs_populate_vp (vp=0xfffff8000a0071d8) at /usr/src/sys/fs/devfs/devfs_vnops.c:241 #20 0xffffffff8047aeec in devfs_lookup (ap=0xfffffe0239277518) at /usr/src/sys/fs/devfs/devfs_vnops.c:1050 #21 0xffffffff8084c48a in VOP_LOOKUP_APV (vop=, a=) at vnode_if.c:127 #22 0xffffffff8061e3e1 in lookup (ndp=) at vnode_if.h:54 #23 0xffffffff8061db6f in namei (ndp=) at /usr/src/sys/kern/vfs_lookup.c:306 #24 0xffffffff8063839c in vn_open_cred (ndp=, flagp=0xfffffe02392778cc, cmode=0, vn_open_flags=, cred=, fp=0xffffffff80040b30) at /usr/src/sys/kern/vfs_vnops.c:277 #25 0xffffffff80631790 in kern_openat (td=0xfffff8013adf1000, fd=-100, path=0x48a13c
, pathseg=UIO_USERSPACE, flags=808784080, mode=) at /usr/src/sys/kern/vfs_syscalls.c:998 #26 0xffffffff807e623f in amd64_syscall (td=0xfffff8013adf1000, traced=0) at subr_syscall.c:135 #27 0xffffffff807cc41b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #28 0x00000002015336da in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal From owner-freebsd-current@freebsd.org Wed Jun 22 08:16:25 2016 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 4CB02B03C2E for ; Wed, 22 Jun 2016 08:16:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9999E2924 for ; Wed, 22 Jun 2016 08:16:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA14400; Wed, 22 Jun 2016 11:16:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bFdKe-000J89-T0; Wed, 22 Jun 2016 11:16:20 +0300 Subject: Re: panic in g_vfs_strategy() To: kargl@uw.edu, freebsd-current@FreeBSD.org References: <20160621220417.GA33717@troutmask.apl.washington.edu> From: Andriy Gapon Message-ID: <30eb3425-b6e8-6b08-ad6d-d8188b7f9ad7@FreeBSD.org> Date: Wed, 22 Jun 2016 11:15:27 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160621220417.GA33717@troutmask.apl.washington.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 22 Jun 2016 08:16:25 -0000 On 22/06/2016 01:04, Steve Kargl wrote: > After a forced umount of a msdos filesystem, I received > a panic. I have the kernel and vmcore. The first hundred > or so lines of core.txt.4 follow my .sig. > It seems that this problem might have the same root cause as this bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210316 so it could be worth while following up there. BTW, some mail user agents render signatures (and, by extension, anything that follows them) in a much less readable way than a regular message text. -- Andriy Gapon From owner-freebsd-current@freebsd.org Wed Jun 22 09:01:51 2016 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 EB7A7AC4E32 for ; Wed, 22 Jun 2016 09:01:51 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF8041ED4 for ; Wed, 22 Jun 2016 09:01:51 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bFe2f-000DIQ-Rp; Wed, 22 Jun 2016 11:01:49 +0200 Date: Wed, 22 Jun 2016 11:01:49 +0200 From: Kurt Jaeger To: Trond =?iso-8859-1?Q?Endrest=F8l?= Cc: FreeBSD current Subject: Re: console in 11.0-ALPHA4 Message-ID: <20160622090149.GD19494@home.opsec.eu> References: <57680D69.7030309@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 22 Jun 2016 09:01:52 -0000 Hi! > If you want textmode like in the old days, add this line to > /boot/loader.conf: > > hw.vga.textmode="1" If I do this on a laptop 10.3p5, sending the laptop to sleep with zzz causes a crash (!), which is reproducable. -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-current@freebsd.org Wed Jun 22 10:02:54 2016 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 65D2EB3B0F0 for ; Wed, 22 Jun 2016 10:02:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 4AC7A24F3 for ; Wed, 22 Jun 2016 10:02:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 465DAB3B0EC; Wed, 22 Jun 2016 10:02:54 +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 435E9B3B0EB; Wed, 22 Jun 2016 10:02:54 +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 AA01324EE; Wed, 22 Jun 2016 10:02:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5MA2ggC018605 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 22 Jun 2016 13:02:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5MA2ggC018605 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5MA2fPD018604; Wed, 22 Jun 2016 13:02:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 22 Jun 2016 13:02:41 +0300 From: Konstantin Belousov To: Maxim Sobolev Cc: John Baldwin , Adrian Chadd , Alan Somers , Alan Cox , Alan Cox , freebsd-current , performance@freebsd.org, "current@freebsd.org" Subject: Re: PostgreSQL performance on FreeBSD Message-ID: <20160622100241.GM38613@kib.kiev.ua> References: <20140627125613.GT93733@kib.kiev.ua> <1603235.2ShtoCfSqO@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 22 Jun 2016 10:02:54 -0000 On Tue, Jun 21, 2016 at 12:48:00PM -0700, Maxim Sobolev wrote: > Thanks, Konstantin for the great work, we are definitely looking forward to > get all those improvements to be part of the default FreeBSD kernel/port. > Would be nice if you can post an update some day later as to what's > integrated and what's not. I did posted the update several days earlier. Since you replying to this thread, it would be not unreasonable to read recent messages that were sent. > > Just in case, I've opened #14206 with PG to switch us to using POSIX > semaphores by default. Apart from the mentioned performance benefits, SYSV > semaphores are PITA to deal with as they come in very limited quantities by > default. Also they might stay around if PG dies/gets nuked and prevent it > from starting again due to overflow. We've got some quite ugly code to > clean up those using ipcrm(1) in our build scripts to deal with just that. > I am happy that code could be retired now. Named semaphores also stuck around if processes are killed without cleanup. From owner-freebsd-current@freebsd.org Wed Jun 22 11:21:50 2016 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 9EB09AC56EC for ; Wed, 22 Jun 2016 11:21:50 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 66A542B14 for ; Wed, 22 Jun 2016 11:21:50 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-it0-x232.google.com with SMTP id f6so36176110ith.0 for ; Wed, 22 Jun 2016 04:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=QyzLqyQKhMD59Kgv5XYnD3OMFV4EkEY7n/zvdt90NxQ=; b=WXp9DalAWUYCS1DgoWI1HBYfm/YSGKltMeY7OzhnpVW1qjRZxVzAwIbb7GjAClaZH8 CmtA3mb/mbpQkx14XxZl7RAR5FVYnwPZnhxde2tzS6FUVSgT1GzjNUsnAhlhtzUDYcr7 EQ15jMxSSPwicPXkHCaN0jgEoybV6P03oiG8w8CICoFU0mOP1Q0/2GI7N2nYFiXddyYE GL838KOpJ+LQiQf6yvlChTc4wWQm+F3RULhZC7CBuBBpoERBPgsiFE25q6i5SCEN7gyu rLcyuf9NvVKvAsjE12QhHS5liVNnUisixPOUXeGZvweDgG35mjXgzoX+c2jEK0WamcnM V5mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-transfer-encoding; bh=QyzLqyQKhMD59Kgv5XYnD3OMFV4EkEY7n/zvdt90NxQ=; b=gSrl6G8vZBgRA2YvNJPENJHPIGHWn+9BJXxHcZUeNhzMd9BJdQOGcMOM0dTDO10tn2 ZrH7J60UwOjxfpOHPGjCdTKQWgoIgJOSxY+6DxWeznyWzyEAo9yR2QsAJ8ELc6O/A5ca ///HAKuZc0sb+DwSM+lN7Xo/gDngIkS4Aaw5797HWOuhs+10tlH0FBKkVNaELf6DERAr J5QxZzNSqKoYQdniaEnISaPX84w5GkimZNMTY04xG4rGbn2Usncu8KwaZjoBpRYouEIM edGzQPReb9PCt4xoUJuRvDhKHXoJ1xugsuLYHn3mcZ1pWK7ShRYFJX3X3qpHlmf7aq6m oadw== X-Gm-Message-State: ALyK8tJdn1Jbp8LJPwFvaGy1p45j0oYcuFwVAZl3Er85SiFRMRn5usb95zacMKcA3Lf6uA== X-Received: by 10.36.211.205 with SMTP id n196mr13092574itg.65.1466594509718; Wed, 22 Jun 2016 04:21:49 -0700 (PDT) Received: from [10.0.10.3] (cpe-184-56-210-236.neo.res.rr.com. [184.56.210.236]) by smtp.googlemail.com with ESMTPSA id j206sm3592160ite.14.2016.06.22.04.21.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 04:21:49 -0700 (PDT) Message-ID: <576A74D0.2020704@gmail.com> Date: Wed, 22 Jun 2016 07:21:52 -0400 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kurt Jaeger CC: =?ISO-8859-1?Q?Trond_Endrest=F8l?= , FreeBSD current Subject: Re: console in 11.0-ALPHA4 References: <57680D69.7030309@gmail.com> <20160622090149.GD19494@home.opsec.eu> In-Reply-To: <20160622090149.GD19494@home.opsec.eu> 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.22 Precedence: 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, 22 Jun 2016 11:21:50 -0000 Kurt Jaeger wrote: > Hi! > >> If you want textmode like in the old days, add this line to >> /boot/loader.conf: >> >> hw.vga.textmode="1" > > If I do this on a laptop 10.3p5, sending the laptop to sleep with > zzz causes a crash (!), which is reproducable. > submit a PR From owner-freebsd-current@freebsd.org Wed Jun 22 14:26:54 2016 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 7B7FDB6963F for ; Wed, 22 Jun 2016 14:26:54 +0000 (UTC) (envelope-from sobomax@sippysoft.com) 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 5591119D8 for ; Wed, 22 Jun 2016 14:26:54 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mailman.ysv.freebsd.org (Postfix) id 54E91B6963A; Wed, 22 Jun 2016 14:26:54 +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 54806B69637 for ; Wed, 22 Jun 2016 14:26:54 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 184EA19D1 for ; Wed, 22 Jun 2016 14:26:54 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x236.google.com with SMTP id s66so24358956oif.1 for ; Wed, 22 Jun 2016 07:26:54 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=r/NmRzpGThk1aVRAcTUeMQLapWNn/JvOvb9Ir6Ec4Lg=; b=uCdt91Dec+M7FIguu2hYXxZJ9WFe11ak9weMMYHgr09dYXXTHLRjgBW6VAMpDk6d93 YixkRSoTpNoQuc9TR/kMS/eZlWrmdKhv3XHkUT3315CN730RuILXkuV7x8UHyrRLrS+9 Xbsa5rXmqfXI8DCJhfLaDARPnFUFeMHEhb7jp0sCusgPRxyviGpHD1Y0cZ9DSs7zz2kL uJkTc8GzXT49UHJARxPE9Gi6lSjVtIfKQJ8QvwxKoDQAaNIzbmQ33J2/NJZjdhTLnwIS LTGV3uqngQl7MJPaMlF5HFHewitJAlkyVUOHHJ8Uosy7zMgF6LUvZA3aZ6qzh651U/e5 gHtg== 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:from :date:message-id:subject:to:cc; bh=r/NmRzpGThk1aVRAcTUeMQLapWNn/JvOvb9Ir6Ec4Lg=; b=bSsqPNW2Dt+NWPz/bkD02NUKbY478H9z9ZNUo7i1Gq9TX0DWLA1UNLR6E7IMcI9cVK MoOEZjYXZRPsFzLPkXJJajrmJ+hMhYBKydTyrv+Twv8M3fu6U7YoU//fEr6Ape/wWzuy MBMJ37z8UKNxqOk2yuNDC+Nv/OnnNPZOOklwfSeqGlchgsxs4d4NfquJ4NwSz4k92qYP 7pEgZUhgPJVVFlfqRYrKTKi8MLa/rdMPpRNtQyEQkbnFCEB1TAeZu12qjWxxSpnjOQUH uv+4WKwmNUToAwb6m6mLn3319F+TBJbM+mYSSaaVOeXiMV2c+vsPzX42Lly8pSWfDpqe 0scQ== X-Gm-Message-State: ALyK8tKTSwOnm8I+r2qiWmijZi7Zr6egWcFKDulU0GGmJR1Iqs2y7TcsI9w/ueoVmvm+shMZsaun6t4OJ2xX7onB X-Received: by 10.202.231.198 with SMTP id e189mr1715841oih.3.1466605613413; Wed, 22 Jun 2016 07:26:53 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.157.41.209 with HTTP; Wed, 22 Jun 2016 07:26:52 -0700 (PDT) In-Reply-To: <20160622100241.GM38613@kib.kiev.ua> References: <20140627125613.GT93733@kib.kiev.ua> <1603235.2ShtoCfSqO@ralph.baldwin.cx> <20160622100241.GM38613@kib.kiev.ua> From: Maxim Sobolev Date: Wed, 22 Jun 2016 07:26:52 -0700 X-Google-Sender-Auth: GEhz5HWzcNo5tUqTMHS36sfjGuc Message-ID: Subject: Re: PostgreSQL performance on FreeBSD To: Konstantin Belousov Cc: John Baldwin , Adrian Chadd , Alan Somers , Alan Cox , Alan Cox , freebsd-current , performance@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 22 Jun 2016 14:26:54 -0000 Konstantin, Not if you do sem_unlink() immediately, AFAIK. And that's what PG does. So the window of opportunity for the leakage is quite small, much smaller than for SYSV primitives. Sorry for missing your status update message, I've missed it somehow. ---- mySem = sem_open(semname, O_CREAT | O_EXCL, (mode_t) IPCProtection, (unsigned) 1); #ifdef SEM_FAILED if (mySem != (sem_t *) SEM_FAILED) break; #else if (mySem != (sem_t *) (-1)) break; #endif /* Loop if error indicates a collision */ if (errno == EEXIST || errno == EACCES || errno == EINTR) continue; /* * Else complain and abort */ elog(FATAL, "sem_open(\"%s\") failed: %m", semname); } /* * Unlink the semaphore immediately, so it can't be accessed externally. * This also ensures that it will go away if we crash. */ sem_unlink(semname); return mySem; ---- -Max On Wed, Jun 22, 2016 at 3:02 AM, Konstantin Belousov wrote: > On Tue, Jun 21, 2016 at 12:48:00PM -0700, Maxim Sobolev wrote: > > Thanks, Konstantin for the great work, we are definitely looking forward > to > > get all those improvements to be part of the default FreeBSD kernel/port. > > Would be nice if you can post an update some day later as to what's > > integrated and what's not. > I did posted the update several days earlier. Since you replying to this > thread, it would be not unreasonable to read recent messages that were > sent. > > > > > Just in case, I've opened #14206 with PG to switch us to using POSIX > > semaphores by default. Apart from the mentioned performance benefits, > SYSV > > semaphores are PITA to deal with as they come in very limited quantities > by > > default. Also they might stay around if PG dies/gets nuked and prevent it > > from starting again due to overflow. We've got some quite ugly code to > > clean up those using ipcrm(1) in our build scripts to deal with just > that. > > I am happy that code could be retired now. > > Named semaphores also stuck around if processes are killed without cleanup. > > From owner-freebsd-current@freebsd.org Wed Jun 22 15:46:43 2016 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 9FDF0AC511D for ; Wed, 22 Jun 2016 15:46:43 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FFCE11B1; Wed, 22 Jun 2016 15:46:43 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u5MFkgvI084453 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Jun 2016 08:46:42 -0700 (PDT) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u5MFkgmt084452; Wed, 22 Jun 2016 08:46:42 -0700 (PDT) (envelope-from kargl) Date: Wed, 22 Jun 2016 08:46:42 -0700 From: "Steven G. Kargl" To: Andriy Gapon Cc: kargl@uw.edu, freebsd-current@FreeBSD.org Subject: Re: panic in g_vfs_strategy() Message-ID: <20160622154642.GB84271@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20160621220417.GA33717@troutmask.apl.washington.edu> <30eb3425-b6e8-6b08-ad6d-d8188b7f9ad7@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30eb3425-b6e8-6b08-ad6d-d8188b7f9ad7@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Mailman-Approved-At: Wed, 22 Jun 2016 15:58:42 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 22 Jun 2016 15:46:43 -0000 On Wed, Jun 22, 2016 at 11:15:27AM +0300, Andriy Gapon wrote: > On 22/06/2016 01:04, Steve Kargl wrote: > > After a forced umount of a msdos filesystem, I received > > a panic. I have the kernel and vmcore. The first hundred > > or so lines of core.txt.4 follow my .sig. > > > > It seems that this problem might have the same root cause as this bug > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210316 > so it could be worth while following up there. > > BTW, some mail user agents render signatures (and, by extension, > anything that follows them) in a much less readable way than a regular > message text. > Thanks for the pointer to the bug. Yes, I think my panic is the same as yours. Checking /var/log/messages I find errors of the form Jun 21 14:14:39 troutmask kernel: g_vfs_done():da1s1[WRITE(\ offset=-1099375943680, length=32768)]error = 5 Inspection of the FAT32 msdosfs showed about 1 TB of disk space used. I suspect, but can't prove, I hit a filesystem limit. -- Steve http://troutmask.apl.washington.edu/~kargl/ From owner-freebsd-current@freebsd.org Wed Jun 22 17:36:45 2016 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 B1C79B72D67 for ; Wed, 22 Jun 2016 17:36:45 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv157.fwdcdn.com (frv157.fwdcdn.com [212.42.77.157]) (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 754A2166E for ; Wed, 22 Jun 2016 17:36:45 +0000 (UTC) (envelope-from fidaj@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=CYG6h1h49HReZr0aipKXl3UplR7774jxJoYyJeKzemk=; b=ob0uUhg1yLUMAfNt6ghNz2KpFP+tykP42AYdP3lTtNFNdBn63fZQAWmFfVE6XRMdOsBXL0CH57+VYfqALQ2Fe0hcYe7eAkzRudIa+nGcsMwVd0eJumMrTIZO7J3cYQrXrL0usLmo5tYnD15Ti4/5AkSg2cIPZPqSmWFFem7pNQc=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1bFm4r-000FDu-6A for freebsd-current@freebsd.org; Wed, 22 Jun 2016 20:36:37 +0300 Date: Wed, 22 Jun 2016 20:36:36 +0300 From: Ivan Klymenko To: freebsd-current@freebsd.org Subject: Fatal trap 12 Message-ID: <20160622203636.050ac83a@nonamehost.local> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 22 Jun 2016 17:36:45 -0000 Hello. After update from r302000 to r302083 i have panic http://i.imgur.com/YfvvhdS.png Thanks. From owner-freebsd-current@freebsd.org Wed Jun 22 17:44:32 2016 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 DA213B72019 for ; Wed, 22 Jun 2016 17:44:32 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 91B391C1A for ; Wed, 22 Jun 2016 17:44:32 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x232.google.com with SMTP id p10so75208642qke.3 for ; Wed, 22 Jun 2016 10:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5sfajsxviTIQFwmtBO4vSEwmdk0Ak6q9r2iAnq2WLv8=; b=Xgb07g6aTChdKNn4tGhE4aeQ6mY4hn/Zc1C+KXIR04Y952qIvVC6MLiTSJcTKseWH0 MAGCGdROWkpiJxQ1wjtRIlWXDMXnmQNnigibtR4aChUngU8NNsZIPkZnvcLqTYus5KY3 kiCTgwwMffCWwzUcMNo53tcjKbMHDis4h68jo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5sfajsxviTIQFwmtBO4vSEwmdk0Ak6q9r2iAnq2WLv8=; b=CPDbzbM1rugf2yyROn9aGt5tQ2PYXHWMoOI0u2zKa1sM8exnKuaLbc+zo1BhbHhtK2 2e1UhqhlkB2Bzo8WyRWhySYDOk787QostHt2qsVy8OyZznaQqZBOxkH4mHNnn4egGpNM gESpsv8nr8aMGF8aavbhtHyd2Mo6lS9vnHgDOEHrGcFiZQ0ENDro6wPqn3NFYpH+w/yP wLRjsoCxgkXXbHsJHWzOv9keeN5GY+pgyMp6fYpt4MPT4LIou1I0tZfsZQt/01NsxEE/ C+ny5y4jkCjI7iBxZWED5yHH4abs1CY04+5+apiYU7MM+/wVnvWXZ4oGVGWpdFEOj3kb eSYw== X-Gm-Message-State: ALyK8tLHqJcSKqEV0yi1DvrUMVas8fwqLO0Bz2uWjGRqCq97bfbQWgbNryKKVxPHA/UY0Q== X-Received: by 10.55.165.67 with SMTP id o64mr40246172qke.51.1466617471608; Wed, 22 Jun 2016 10:44:31 -0700 (PDT) Received: from [192.168.0.18] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id j62sm396074qtb.35.2016.06.22.10.44.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 10:44:30 -0700 (PDT) Subject: Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison] To: Keith White , Ian Lepore References: <99277FB6-77EB-4D8B-8A55-FBD622D29AC3@dsl-only.net> <22fe5f7f-6153-e092-c410-eddb1431a78a@bsd.com.br> <1466531719.34556.72.camel@freebsd.org> Cc: Mark Millard , freebsd-arm , FreeBSD Current From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <3c4cc02c-f6be-b6de-3d9b-da1302aac85d@bsd.com.br> Date: Wed, 22 Jun 2016 14:44:06 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 22 Jun 2016 17:44:32 -0000 Em 21/06/2016 19:45, Keith White escreveu: > On Tue, 21 Jun 2016, Ian Lepore wrote: > >> On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: >>> Em 21/06/2016 07:33, Keith White escreveu: >>>> In an earlier message Ian said that he thought he knew what the >>>> problem was... >>> >>> Here the problem occurs when using wifi. I do not have tested wired >>> because I don't have a cable here. >>> >>> >>> []'s >>> >>> -Otacilio >> >> The wifi alignment fault should be fixed as of r302064. Sorry it took >> so long. >> >> -- Ian > > Many thanks Ian! Yes, this has fixed the problem. No more panics > on ssh to rpi-b. > > ...keith This fix on beaglebone black also. Thanks a lot! []'s -Otacílio From owner-freebsd-current@freebsd.org Wed Jun 22 17:45:29 2016 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 31A42B720C0 for ; Wed, 22 Jun 2016 17:45:29 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv157.fwdcdn.com (frv157.fwdcdn.com [212.42.77.157]) (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 EC30F1DBE for ; Wed, 22 Jun 2016 17:45:28 +0000 (UTC) (envelope-from fidaj@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:To:From:Date; bh=ea2JlskPnI8f2Utn9nrh9PZY82ylVwpr+y2HAXmXIEQ=; b=g5eThj/xBjzwRlarDlGGbGezjYjN55doHlcbLr6gUOSxNq4ASG4uBGJ7IKF28XbDX3ukc3Af5EaGlJAt6T5gz8El0itUrrELmCzU6PcyGHSfFIfbTJOmUzojNn9FycNAl2hRcP9K8Ky+wUpX/Er691p6KjRbVCnuMilwpRD3ZNQ=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1bFmDO-000J4X-W9 for freebsd-current@freebsd.org; Wed, 22 Jun 2016 20:45:27 +0300 Date: Wed, 22 Jun 2016 20:45:26 +0300 From: Ivan Klymenko To: freebsd-current@freebsd.org Subject: Re: Fatal trap 12 Message-ID: <20160622204526.427fa6ea@nonamehost.local> In-Reply-To: <20160622203636.050ac83a@nonamehost.local> References: <20160622203636.050ac83a@nonamehost.local> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 22 Jun 2016 17:45:29 -0000 On Wed, 22 Jun 2016 20:36:36 +0300 Ivan Klymenko wrote: > Hello. > After update from r302000 to r302083 i have panic > http://i.imgur.com/YfvvhdS.png > > Thanks. Sorry, the first time discovered a revision r302060. From owner-freebsd-current@freebsd.org Wed Jun 22 17:56:10 2016 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 7B369B723CA for ; Wed, 22 Jun 2016 17:56:10 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv157.fwdcdn.com (frv157.fwdcdn.com [212.42.77.157]) (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 4041B2487 for ; Wed, 22 Jun 2016 17:56:09 +0000 (UTC) (envelope-from fidaj@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:To:From:Date; bh=IbToOjpVTd4MsMSa8OhX1OC/k/lDaAh1oSO+BNv0HM0=; b=ur/1DY1l4aBia0T/r1MVW1UclBDJBIVRT5zJGmy/TboluZ7nVS0AozcxoL1GllVlSFkSwVrwiZ6a9VyOYvgAc7ks9blBTaVEZAO54kjDjrsPhNpgymUp3Ycx29l/Nn3pbg5tgy5iKcro3MDJWCwI16gmVnUClgS43vaKJ6EMP7c=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1bFmNj-000Nxc-Q1 for freebsd-current@freebsd.org; Wed, 22 Jun 2016 20:56:07 +0300 Date: Wed, 22 Jun 2016 20:56:07 +0300 From: Ivan Klymenko To: freebsd-current@freebsd.org Subject: Re: Fatal trap 12 Message-ID: <20160622205607.472ea221@nonamehost.local> In-Reply-To: <20160622204526.427fa6ea@nonamehost.local> References: <20160622203636.050ac83a@nonamehost.local> <20160622204526.427fa6ea@nonamehost.local> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 22 Jun 2016 17:56:10 -0000 On Wed, 22 Jun 2016 20:45:26 +0300 Ivan Klymenko wrote: > On Wed, 22 Jun 2016 20:36:36 +0300 > Ivan Klymenko wrote: > > > Hello. > > After update from r302000 to r302083 i have panic > > http://i.imgur.com/YfvvhdS.png > > > > Thanks. > Sorry, the first time discovered a revision r302060. There is a suspicion that the reason for this commit: https://svnweb.freebsd.org/base?view=revision&revision=302054 From owner-freebsd-current@freebsd.org Wed Jun 22 21:12:42 2016 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 E6A26B7245B for ; Wed, 22 Jun 2016 21:12:42 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 7B5712C15 for ; Wed, 22 Jun 2016 21:12:42 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id r190so124497wmr.0 for ; Wed, 22 Jun 2016 14:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ErMBqHswlG9JZE4dcRUhGWOTwD2oLow9vGxIHMkQwTQ=; b=Phh/b5wIyK1dSF3AmZjGB5W8VJz7ZvqLc2XMav6FMxX8nwgqle7ECF8H9F4TCFakdD uNzZCIt0mKZweXAp+RFYjM8ym0AVnB36FVeZ0g70b6Kq3BTIYmghFKp9HqYAcNMOAO/1 9QREKXjNTvw6NC553Hms8dMonDy7Rq/h7obl/rbuaQlXZ2zwk58B6V0ow6BVNjtN3Qer +QOMm7g5LosY2HdP4Ue9qacj6E+1CObD2q2WQmC0ZwgfHgkZJBbH5E3lm72j6hK/Rfkl 917pGPVTasfDZbwWebXU3gUFivZFKR0dRUhJDbgptkumJdbSNSktO57fTk8FeFBzYCoE CmFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ErMBqHswlG9JZE4dcRUhGWOTwD2oLow9vGxIHMkQwTQ=; b=QV+ovJEqR51gngXTQ6S8k63ESD/5ccqqQGYrhQymSwP5Sc8TgrrC862grvTcCOVJf6 6la73kemy7mzNgu9DpdNiLFBHuavHAIfznEJwATxnqM/k2B1RgVVeDeuU38mbeCoCF38 PwHi8lULEfs6jQ+M8rS9YciAlTPgWOMq2xWGqg4WZTg7odJnDyphGR0rsMsWPkRUUD5C 6W+dBfdzeYvOftnvqN9SvMe08z4SWJwRqcWPQS4RaCb3cGvBQCeYIdxKaR50jct2vWdU oier45ZpduqkPjmIDUs5dDkLNboAen3eyAVU3pJn/rqF1f3Ecokt8UplrJl5A7O5MMIY zCHw== X-Gm-Message-State: ALyK8tL3Ib5ASuVJLY3lK8mPnWiEu7F0LvjW35fSNCTz/QXJpQL5K9iCqZxW/UFgMUoxiQ== X-Received: by 10.28.216.14 with SMTP id p14mr10255582wmg.84.1466629960984; Wed, 22 Jun 2016 14:12:40 -0700 (PDT) Received: from Johans-MacBook-Air-2.local (92-111-79-242.static.chello.nl. [92.111.79.242]) by smtp.googlemail.com with ESMTPSA id b77sm2342515wme.0.2016.06.22.14.12.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jun 2016 14:12:40 -0700 (PDT) Subject: Re: Fatal trap 12 To: Ivan Klymenko References: <20160622203636.050ac83a@nonamehost.local> From: Johan Hendriks Cc: freebsd-current@freebsd.org Message-ID: <4ef2b986-60f0-94f1-b180-46f543774419@gmail.com> Date: Wed, 22 Jun 2016 23:12:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160622203636.050ac83a@nonamehost.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 22 Jun 2016 21:12:43 -0000 Just a me too. Build yesterday (revision unclear) and starts fine, today a rebuild and a panic. But I do not see the panic message as it reboots right away. The latest line I see is atkbd0: irq 1 on atkbdc0 Then a real quick panic and then it reboots. I captured it by filming and then pause it before the reboot. ( the first part is unreadable, but from processor eflags it is the same! except the 0xfffffffff80b values.) But also 10 lines of KDB stack backtrace: , and 1s uptime. The old kernel boots fine! My system uses root on ZFS! regards Johan Op 22/06/16 om 19:36 schreef Ivan Klymenko: > Hello. > After update from r302000 to r302083 i have panic > http://i.imgur.com/YfvvhdS.png > > Thanks. > _______________________________________________ > 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 Jun 23 00:01:51 2016 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 722A2AC5943 for ; Thu, 23 Jun 2016 00:01:51 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 34D34180B for ; Thu, 23 Jun 2016 00:01:50 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CBE6A25D37C2; Thu, 23 Jun 2016 00:01:46 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 27C4CD1F813; Thu, 23 Jun 2016 00:01:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id IZs96OSimmXJ; Thu, 23 Jun 2016 00:01:44 +0000 (UTC) Received: from [192.168.124.1] (unknown [IPv6:fde9:577b:c1a9:4410:21bf:e4ab:2432:b9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id CB684D1F7F8; Thu, 23 Jun 2016 00:01:43 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Ivan Klymenko" Cc: freebsd-current@freebsd.org Subject: Re: Fatal trap 12 Date: Thu, 23 Jun 2016 00:01:42 +0000 Message-ID: <589E375F-8518-4849-AA0C-E4FE8F1D85E1@lists.zabbadoz.net> In-Reply-To: <20160622205607.472ea221@nonamehost.local> References: <20160622203636.050ac83a@nonamehost.local> <20160622204526.427fa6ea@nonamehost.local> <20160622205607.472ea221@nonamehost.local> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate Trial (2.0BETAr6032) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 00:01:51 -0000 On 22 Jun 2016, at 17:56, Ivan Klymenko wrote: > On Wed, 22 Jun 2016 20:45:26 +0300 > Ivan Klymenko wrote: > >> On Wed, 22 Jun 2016 20:36:36 +0300 >> Ivan Klymenko wrote: >> >>> Hello. >>> After update from r302000 to r302083 i have panic >>> http://i.imgur.com/YfvvhdS.png >>> >>> Thanks. >> Sorry, the first time discovered a revision r302060. > > There is a suspicion that the reason for this commit: > https://svnweb.freebsd.org/base?view=revision&revision=302054 Do you compile pflog into the kernel or load it from loader by any chance? I can see what might happen here. Can you try to see if this goes away if you load pflog after pf is loaded? If that helps change the SI_SUB_PSEUDO at the end of sys/netpfil/pf/if_pflog.c to SI_SUB_PROTO_FIREWALL ; that should fix it. /bz From owner-freebsd-current@freebsd.org Thu Jun 23 00:18:43 2016 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 E85D2AC5D6A; Thu, 23 Jun 2016 00:18:43 +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 CEB632241; Thu, 23 Jun 2016 00:18:43 +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 A280B155; Thu, 23 Jun 2016 00:18:43 +0000 (UTC) Date: Thu, 23 Jun 2016 00:18:41 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: brooks@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <1393254322.1.1466641123746.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #3431 - 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.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 00:18:44 -0000 FreeBSD_HEAD_i386 - Build #3431 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3431/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3431/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3431/console Change summaries: 302095 by brooks: Generate syscall tables and update pipe() implementation after r302094. Mark the pipe() system call as COMPAT10. As of r302092 libc uses pipe2() with a zero flags value instead of pipe(). Approved by: re (gjb) Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D6816 302094 by brooks: Mark the pipe() system call as COMPAT10. As of r302092 libc uses pipe2() with a zero flags value instead of pipe(). Commit with regenerated files and implementation to follow. Approved by: re (gjb) Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D6816 The end of the build log: [...truncated 179099 lines...] --- emu10kx-pcm.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 -MD -MF.depend.emu10kx-pcm.o -MTemu10kx-pcm.o -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/sound/driver/emu10kx/../../../../dev/sound/pci/emu10kx-pcm.c -o emu10kx-pcm.o --- all_subdir_stge --- ctfconvert -L VERSION -g if_stge.o --- if_stge.kld --- ld -d -warn-common -r -d -o if_stge.kld if_stge.o ctfmerge -L VERSION -g -o if_stge.kld if_stge.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_stge.kld export_syms | xargs -J% objcopy % if_stge.kld --- if_stge.ko.full --- ld -Bshareable -d -warn-common -o if_stge.ko.full if_stge.kld --- if_stge.ko.debug --- objcopy --only-keep-debug if_stge.ko.full if_stge.ko.debug --- if_stge.ko --- objcopy --strip-debug --add-gnu-debuglink=if_stge.ko.debug if_stge.ko.full if_stge.ko --- rslist.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 -MD -MF.depend.rslist.o -MTrslist.o -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/contrib/dev/acpica/components/resources/rslist.c ctfconvert -L VERSION -g rslist.o --- modules-all --- --- all_subdir_sound --- --- emu10kx-midi.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 -MD -MF.depend.emu10kx-midi.o -MTemu10kx-midi.o -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/sound/driver/emu10kx/../../../../dev/sound/pci/emu10kx-midi.c -o emu10kx-midi.o ctfconvert -L VERSION -g emu10kx-midi.o --- rsmemory.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 -MD -MF.depend.rsmemory.o -MTrsmemory.o -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/contrib/dev/acpica/components/resources/rsmemory.c --- modules-all --- --- emu10kx-pcm.o --- ctfconvert -L VERSION -g emu10kx-pcm.o --- emu10kx.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 -MD -MF.depend.emu10kx.o -MTemu10kx.o -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/sound/driver/emu10kx/../../../../dev/sound/pci/emu10kx.c -o emu10kx.o --- rsmemory.o --- ctfconvert -L VERSION -g rsmemory.o --- modules-all --- --- all_subdir_sound/driver/envy24 --- ===> sound/driver/envy24 (all) --- all_subdir_sound/sound --- ctfconvert -L VERSION -g mixer.o --- all_subdir_sound/driver --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- rsmisc.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 -MD -MF.depend.rsmisc.o -MTrsmisc.o -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/contrib/dev/acpica/components/resources/rsmisc.c --- modules-all --- --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- ac97_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/sound/pcm/ac97_if.m -h --- channel_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/sound/pcm/channel_if.m -h --- feeder_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/sound/pcm/feeder_if.m -h --- mixer_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/sound/pcm/mixer_if.m -h --- envy24.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 -MD -MF.depend.envy24.o -MTenvy24.o -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/sound/driver/envy24/../../../../dev/sound/pci/envy24.c -o envy24.o --- rsmisc.o --- ctfconvert -L VERSION -g rsmisc.o --- modules-all --- --- all_subdir_sound/driver/envy24ht --- ===> sound/driver/envy24ht (all) --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- device_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h --- bus_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h --- pci_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h --- ac97_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/sound/pcm/ac97_if.m -h --- channel_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/sound/pcm/channel_if.m -h --- feeder_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/sound/pcm/feeder_if.m -h --- mixer_if.h --- awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/sound/pcm/mixer_if.m -h --- envy24ht.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 -MD -MF.depend.envy24ht.o -MTenvy24ht.o -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/sound/driver/envy24ht/../../../../dev/sound/pci/envy24ht.c -o envy24ht.o --- all_subdir_sound/sound --- --- dsp.o --- ctfconvert -L VERSION -g dsp.o --- sndstat.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 -MD -MF.depend.sndstat.o -MTsndstat.o -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/dev/sound/pcm/sndstat.c -o sndstat.o ctfconvert -L VERSION -g sndstat.o --- sound.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 -MD -MF.depend.sound.o -MTsound.o -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/dev/sound/pcm/sound.c -o sound.o --- all_subdir_sound/driver --- --- all_subdir_sound/driver/envy24 --- ctfconvert -L VERSION -g envy24.o --- all_subdir_sound/driver/envy24ht --- ctfconvert -L VERSION -g envy24ht.o --- all_subdir_sound/driver/envy24 --- --- snd_envy24.kld --- ld -d -warn-common -r -d -o snd_envy24.kld envy24.o ctfmerge -L VERSION -g -o snd_envy24.kld envy24.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk snd_envy24.kld export_syms | xargs -J% objcopy % snd_envy24.kld --- all_subdir_sound/driver/envy24ht --- --- snd_envy24ht.kld --- ld -d -warn-common -r -d -o snd_envy24ht.kld envy24ht.o --- all_subdir_sound/driver/envy24 --- --- snd_envy24.ko.full --- ld -Bshareable -d -warn-common -o snd_envy24.ko.full snd_envy24.kld --- all_subdir_sound/driver/envy24ht --- ctfmerge -L VERSION -g -o snd_envy24ht.kld envy24ht.o --- all_subdir_sound/driver/envy24 --- --- snd_envy24.ko.debug --- objcopy --only-keep-debug snd_envy24.ko.full snd_envy24.ko.debug --- snd_envy24.ko --- objcopy --strip-debug --add-gnu-debuglink=snd_envy24.ko.debug snd_envy24.ko.full snd_envy24.ko --- all_subdir_sound/driver/envy24ht --- :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk snd_envy24ht.kld export_syms | xargs -J% objcopy % snd_envy24ht.kld --- all_subdir_streams --- ===> streams (all) --- all_subdir_sound --- --- snd_envy24ht.ko.full --- ld -Bshareable -d -warn-common -o snd_envy24ht.ko.full snd_envy24ht.kld --- snd_envy24ht.ko.debug --- objcopy --only-keep-debug snd_envy24ht.ko.full snd_envy24ht.ko.debug --- snd_envy24ht.ko --- objcopy --strip-debug --add-gnu-debuglink=snd_envy24ht.ko.debug snd_envy24ht.ko.full snd_envy24ht.ko --- all_subdir_svr4 --- ===> svr4 (all) --- all_subdir_streams --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- streams.o --- cc -O2 -pipe -O -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 -MD -MF.depend.streams.o -MTstreams.o -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/streams/../../dev/streams/streams.c -o streams.o --- all_subdir_svr4 --- --- machine --- machine -> /usr/src/sys/i386/include --- x86 --- x86 -> /usr/src/sys/x86/include --- opt_compat.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_compat.h opt_compat.h --- opt_svr4.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_svr4.h opt_svr4.h --- vnode_if_newproto.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p --- vnode_if_typedef.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q --- opt_ktrace.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_ktrace.h opt_ktrace.h --- opt_sysvipc.h --- ln -sf /usr/obj/usr/src/sys/GENERIC/opt_sysvipc.h opt_sysvipc.h --- vnode_if.h --- awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h --- svr4_sysent.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 -MD -MF.depend.svr4_sysent.o -MTsvr4_sysent.o -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/svr4/../../compat/svr4/svr4_sysent.c -o svr4_sysent.o /usr/src/sys/modules/svr4/../../compat/svr4/svr4_sysent.c:64:20: error: use of undeclared identifier 'sys_pipe' { 0, (sy_call_t *)sys_pipe, AUE_NULL, NULL, 0, 0, 0, SY_THR_STATIC }, /* 42 = pipe */ ^ 1 error generated. *** [svr4_sysent.o] Error code 1 bmake[4]: stopped in /usr/src/sys/modules/svr4 1 error bmake[4]: stopped in /usr/src/sys/modules/svr4 *** [all_subdir_svr4] Error code 2 bmake[3]: stopped in /usr/src/sys/modules --- all_subdir_streams --- ctfconvert -L VERSION -g streams.o A failure has been detected in another branch of the parallel make bmake[4]: stopped in /usr/src/sys/modules/streams *** [all_subdir_streams] Error code 2 bmake[3]: stopped in /usr/src/sys/modules --- all_subdir_sound --- --- all_subdir_sound/sound --- ctfconvert -L VERSION -g sound.o A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/src/sys/modules/sound/sound *** [all_subdir_sound/sound] Error code 2 bmake[4]: stopped in /usr/src/sys/modules/sound --- all_subdir_sound/driver --- --- all_subdir_sound/driver/emu10kx --- ctfconvert -L VERSION -g emu10kx.o A failure has been detected in another branch of the parallel make bmake[6]: stopped in /usr/src/sys/modules/sound/driver/emu10kx *** [all_subdir_sound/driver/emu10kx] Error code 2 bmake[5]: stopped in /usr/src/sys/modules/sound/driver 1 error bmake[5]: stopped in /usr/src/sys/modules/sound/driver *** [all_subdir_sound/driver] Error code 2 bmake[4]: stopped in /usr/src/sys/modules/sound 2 errors bmake[4]: stopped in /usr/src/sys/modules/sound *** [all_subdir_sound] Error code 2 bmake[3]: stopped in /usr/src/sys/modules 3 errors bmake[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC 1 error bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 bmake[1]: stopped in /usr/src 1 error bmake[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/hudson1386109795712248858.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::104: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 Thu Jun 23 02:23:59 2016 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 C96B1B73269; Thu, 23 Jun 2016 02:23:59 +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 ADBAE1186; Thu, 23 Jun 2016 02:23:59 +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 CF29017D; Thu, 23 Jun 2016 02:23:59 +0000 (UTC) Date: Thu, 23 Jun 2016 02:23:56 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: brooks@FreeBSD.org, bz@FreeBSD.org, adrian@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <584263914.3.1466648639863.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1393254322.1.1466641123746.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1393254322.1.1466641123746.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_i386 - Build #3432 - 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.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 02:23:59 -0000 FreeBSD_HEAD_i386 - Build #3432 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3432/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3432/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3432/console Change summaries: 302104 by adrian: [iwm] Use mbuf for large firmware commands, like OpenBSD does. We also need to consider the size of large firmware commands in iwm_alloc_tx_ring(), in the dma tag creation, when qid == IWM_MVM_CMD_QUEUE. The old code apparently only allocated a 2KB (MCLBYTES) sized buffer when it actually expected 4KB. Submitted by: Imre Vadasz Approved by: re (gjb) Differential Revision: https://reviews.freebsd.org/D6824 302103 by adrian: [iwm] Add and use iwm_phy_db_free(), to plug phy_db memory leak. (Together with other iwm(4) memory leak fixes) Memory leakage in M_DEVBUF is now at ca. 2KB for each iwm(4) module load/unload cycle. Submitted by: Imre Vadasz Approved by: re (gjb) Obtained from: DragonflyBSD git eaf551a1d464c643e98ce5781971dd32124e9af1 Differential Revision: https://reviews.freebsd.org/D6819 302102 by adrian: [iwm] Fix iwm_dma_contig_free(). dma->map is always NULL here. * When bus_dmamem_alloc is used, the bus_dmamap_t is usually set to NULL, so we were never actually freeing any dma memory allocations done via iwm_dma_contig_alloc(). So we should check dma->vaddr instead of dma->map here. * Also, the dmamap is actually supposed to be invalidated as part of bus_dmamem_free(), so bus_dmamap_destroy() is never needed here. Submitted by: Imre Vadasz Approved by: re (gjb) Obtained from: DragonflyBSD git ef2b29a7ba6ca8a9d2c82ab591c0622227ff84cb 302101 by adrian: [iwm] Use vap->iv_myaddr instead of ic->ic_macaddr when vap != NULL. ic_macaddr is only used for the initial mac address provided by NVM. We should rather use vap->iv_myaddr when vap != NULL, to allow the MAC address to be changed later with ifconfig(8). Submitted by: Imre Vadasz Reviewed by: avos Approved by: re (gjb) Obtained from: DragonflyBSD git 4aee7a78275676d22d14c04177bd0c9377d91478 Differential Revision: https://reviews.freebsd.org/D6743 302100 by adrian: [ath] fix comments! I keep asking myself "what do these fields mean" and so now I've clarified it for myself. Tested: * Reading the comments, going "a-ha!" a couple times. Approved by: re (gjb) 302099 by bz: Check the V_tcbinfo.ipi_count to hit 0 before doing the full TCP cleanup. That way timers can finish cleanly and we do not gamble with a DELAY(). Reviewed by: gnn, jtl Approved by: re (gjb) Obtained from: projects/vnet MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D6923 302098 by bz: No longer mark TCP TW zone NO_FREE. Timewait code does a proper cleanup after itself. Reviewed by: gnn Approved by: re (gjb) Obtained from: projects/vnet MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D6922 302097 by brooks: Regen post r302096 and implement svr4_pipe(). Approved by: re (implict, fixing build) Sponsored by: DARPA, AFRL 302096 by brooks: Declare a svr4 version of pipe() now that sys_pipe() is no more. Approved by: re (implicit, fixing build) Sponsored by: DARPA, AFRL From owner-freebsd-current@freebsd.org Thu Jun 23 04:42:21 2016 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 97705AC4F6C for ; Thu, 23 Jun 2016 04:42:21 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6963A168C for ; Thu, 23 Jun 2016 04:42:21 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net (torb.pix.net [192.168.16.32]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id u5N4gKW6099440; Thu, 23 Jun 2016 00:42:20 -0400 (EDT) (envelope-from lidl@pix.net) To: FreeBSD-Current From: Kurt Lidl Subject: head is broken after recent sys_pipe changes Message-ID: <4e11a1e3-2815-2979-822c-ddac44113392@pix.net> Date: Thu, 23 Jun 2016 00:42:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 04:42:21 -0000 As of this commit: r302106 | adrian | 2016-06-22 21:15:35 -0400 (Wed, 22 Jun 2016) | 4 lines revert error commit from previous commit. my bad! Approved by: re (implicit) Head still doesn't compile doing: make -k -s -j24 tinderbox TARGETS="amd64 sparc64" Tinderbox failed: amd64.amd64 buildworld failed, check _.amd64.amd64.buildworld for details ===> lib/csu/amd64 (obj) ===> lib/csu/amd64 (all) ===> lib/csu/amd64 (install) bmake[6]: /usr/obj/p/fbsd/GIT/lib/libc/.depend.pipe.o, 5: ignoring stale .depend for /p/fbsd/GIT/lib/libc/amd64/sys/pipe.S cc: error: no such file or directory: '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' cc: error: no input files --- pipe.So --- *** [pipe.So] Error code 1 bmake[6]: stopped in /p/fbsd/GIT/lib/libc cc: error: no such file or directory: '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' cc: error: no input files --- pipe.o --- *** [pipe.o] Error code 1 -Kurt From owner-freebsd-current@freebsd.org Thu Jun 23 04:44:10 2016 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 22175AC4FED for ; Thu, 23 Jun 2016 04:44:10 +0000 (UTC) (envelope-from gjb@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 13B97181D; Thu, 23 Jun 2016 04:44:10 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id C7B571918; Thu, 23 Jun 2016 04:44:09 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 23 Jun 2016 04:44:06 +0000 From: Glen Barber To: Kurt Lidl Cc: FreeBSD-Current Subject: Re: head is broken after recent sys_pipe changes Message-ID: <20160623044406.GZ10155@FreeBSD.org> References: <4e11a1e3-2815-2979-822c-ddac44113392@pix.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2+IDmuKgu0wSQZlt" Content-Disposition: inline In-Reply-To: <4e11a1e3-2815-2979-822c-ddac44113392@pix.net> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 04:44:10 -0000 --2+IDmuKgu0wSQZlt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 23, 2016 at 12:42:20AM -0400, Kurt Lidl wrote: > As of this commit: >=20 > r302106 | adrian | 2016-06-22 21:15:35 -0400 (Wed, 22 Jun 2016) | 4 lines >=20 > revert error commit from previous commit. my bad! >=20 > Approved by: re (implicit) >=20 > Head still doesn't compile doing: >=20 > make -k -s -j24 tinderbox TARGETS=3D"amd64 sparc64" >=20 > Tinderbox failed: > amd64.amd64 buildworld failed, check _.amd64.amd64.buildworld for details >=20 > =3D=3D=3D> lib/csu/amd64 (obj) > =3D=3D=3D> lib/csu/amd64 (all) > =3D=3D=3D> lib/csu/amd64 (install) > bmake[6]: /usr/obj/p/fbsd/GIT/lib/libc/.depend.pipe.o, 5: ignoring stale > .depend > for /p/fbsd/GIT/lib/libc/amd64/sys/pipe.S > cc: error: no such file or directory: > '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' > cc: error: no input files > --- pipe.So --- > *** [pipe.So] Error code 1 >=20 > bmake[6]: stopped in /p/fbsd/GIT/lib/libc > cc: error: no such file or directory: > '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' > cc: error: no input files > --- pipe.o --- > *** [pipe.o] Error code 1 >=20 What revision? It builds for me on r302113. Glen --2+IDmuKgu0wSQZlt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXa2kWAAoJEAMUWKVHj+KTwDcP/i3MUag2FNCMxwpPO0XS72p6 AovBMGlQtajuRWQCZPUXEF/D9kjZNhogzO2+8XiY3Ws8qv8ZKiAMZvJtFzDCOLTO Dcitfgc9f1tF7i0XTm7OkYpYfaEErHZsiu6Z3JTji8al6Xed9SwtlHswKvucZZey nFI3gc8P4Gpa3LPQ8DKJFSUlX1f41H6YkilfGFvEzvrZwqNBcPDT+t80qiX36ITj P2VX0CgdoLSqFPLoXxBZDf6EPoMt/JnL6utygYl0/yEjyFYj8tXlPZqGtOzY7x5E Zk9OBijDYFvGD/sxD9cMh83M+beqJPZxcVIhTDNI31X5PRjVq3ij1c6PGBFHjL4F j5aXZhWtzilcmm4ncIGvOEGDSAYEou7sIsEEAjTrLlpTdqqz82ii6jIkpzr09Yrl u1sBsACex6z5a6Y4GZsGM5bfTUKhi4ujIiDs4cCl/I//Ca3/uPW79X/SkV7/aIjs vjvgPq6hUu4qXGjkRtDmEeb+nytOx/5hsIbuCERWheLHfyz7E1TmTfDMzEkRUEcl shEbOetMnJ2aBf/WUaijp2agVCAW70YLTkeESPMOQ0mRkJfoTQO2tUE26ByYSMio JEqHDQ39DWKCUol5yHna3jTwKaBKb9DTqxF+7U2L+42s+0Y4Lt1kzvp6xl0f6q/v CsIVocHOahK1YetQUWbY =2W1H -----END PGP SIGNATURE----- --2+IDmuKgu0wSQZlt-- From owner-freebsd-current@freebsd.org Thu Jun 23 04:45:45 2016 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 1C8CEB720C0 for ; Thu, 23 Jun 2016 04:45:45 +0000 (UTC) (envelope-from gjb@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 0E18419B7; Thu, 23 Jun 2016 04:45:45 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id C268819F5; Thu, 23 Jun 2016 04:45:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 23 Jun 2016 04:45:28 +0000 From: Glen Barber To: Kurt Lidl Cc: FreeBSD-Current Subject: Re: head is broken after recent sys_pipe changes Message-ID: <20160623044528.GA10155@FreeBSD.org> References: <4e11a1e3-2815-2979-822c-ddac44113392@pix.net> <20160623044406.GZ10155@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XsxFkDPDWfsXVt/M" Content-Disposition: inline In-Reply-To: <20160623044406.GZ10155@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 04:45:45 -0000 --XsxFkDPDWfsXVt/M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 23, 2016 at 04:44:06AM +0000, Glen Barber wrote: > On Thu, Jun 23, 2016 at 12:42:20AM -0400, Kurt Lidl wrote: > > As of this commit: > >=20 > > r302106 | adrian | 2016-06-22 21:15:35 -0400 (Wed, 22 Jun 2016) | 4 lin= es > >=20 > > revert error commit from previous commit. my bad! > >=20 > > Approved by: re (implicit) > >=20 > > Head still doesn't compile doing: > >=20 > > make -k -s -j24 tinderbox TARGETS=3D"amd64 sparc64" > >=20 > > Tinderbox failed: > > amd64.amd64 buildworld failed, check _.amd64.amd64.buildworld for detai= ls > >=20 > > =3D=3D=3D> lib/csu/amd64 (obj) > > =3D=3D=3D> lib/csu/amd64 (all) > > =3D=3D=3D> lib/csu/amd64 (install) > > bmake[6]: /usr/obj/p/fbsd/GIT/lib/libc/.depend.pipe.o, 5: ignoring stale > > .depend > > for /p/fbsd/GIT/lib/libc/amd64/sys/pipe.S > > cc: error: no such file or directory: > > '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' > > cc: error: no input files > > --- pipe.So --- > > *** [pipe.So] Error code 1 > >=20 > > bmake[6]: stopped in /p/fbsd/GIT/lib/libc > > cc: error: no such file or directory: > > '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' > > cc: error: no input files > > --- pipe.o --- > > *** [pipe.o] Error code 1 > >=20 >=20 > What revision? It builds for me on r302113. >=20 I see you mentioned the revision, sorry for not noticing. I think you hit a bug that brooks fixed later, which should build fine now. Glen --XsxFkDPDWfsXVt/M Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXa2loAAoJEAMUWKVHj+KT7xYQAJ9Yks8VGtxS/nJB0XrLtrUP iarT2Pb03Z0+x5UcLhH9di3kMHht5maRtJ6His0xIeNbiI5bDY5wae+EzFCOXdpJ p5kq5FRUUifbKWW2BuGl50EQ3OIS1jYRL/f46HhPRpkE/tkXSSX+Em3bMJHIsRzT a/4uoLF6WCFq+aZHZD+HE2QKPcKqc/ndBMWNnxqduE9GQZgI9wICI1R1m6L8gvUe Tt0iL65q7DN1GbxJlraNG6uKLdfJXKFsGjhh4sPzUAG5gMGBz7DFT1+3cwqbSCCo 3SrwYnaAd+UDNMHBJ/t4jjDj5JErpyDNDGwu4k7PU6RisrKx58lYMXhP4Kdq7ZcR AqsqG/Tv1JpVAMbmXsUB1vNAvLIZtt+Er3s9n/i3vtGJHIjhdYY2aqzMeafIZYHd 8XZ7iOV3y4Yt3LMkrltxyDgo587M2HaGFy950jn1B0Z+g92NHE7C94+kt80UIyvd GvSl6pq6fDH0P9HEl62v9EzI9PJmlLHbk+Fsfgmt/fX8TJzUN2HGhi6Qtm2lIz47 SF5CJ5GfZ86qGl7oSde+lw9UsFooPa5NsodtY0Mk/CsSy4yJoczVufZ3L8MKDzrW bXkdQsoJCS5cdYNNoGmGg7MDi3vkCtOSneLW0tSRc1fPVGJ31aL1c/Bkx/5Lil6Q ZNdXfFxvLcsgBTyBbNKg =afJv -----END PGP SIGNATURE----- --XsxFkDPDWfsXVt/M-- From owner-freebsd-current@freebsd.org Thu Jun 23 04:46:49 2016 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 9EDF0B72155 for ; Thu, 23 Jun 2016 04:46:49 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5513D1AE7; Thu, 23 Jun 2016 04:46:49 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net (torb.pix.net [192.168.16.32]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id u5N4km1g099511; Thu, 23 Jun 2016 00:46:48 -0400 (EDT) (envelope-from lidl@pix.net) Subject: Re: head is broken after recent sys_pipe changes To: Glen Barber References: <4e11a1e3-2815-2979-822c-ddac44113392@pix.net> <20160623044406.GZ10155@FreeBSD.org> <20160623044528.GA10155@FreeBSD.org> Cc: FreeBSD-Current From: Kurt Lidl Message-ID: <34e6a7d5-d96e-8277-3848-07aedf832c20@pix.net> Date: Thu, 23 Jun 2016 00:46:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160623044528.GA10155@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.22 Precedence: 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, 23 Jun 2016 04:46:49 -0000 On 6/23/16 12:45 AM, Glen Barber wrote: > On Thu, Jun 23, 2016 at 04:44:06AM +0000, Glen Barber wrote: >> On Thu, Jun 23, 2016 at 12:42:20AM -0400, Kurt Lidl wrote: >>> As of this commit: >>> >>> r302106 | adrian | 2016-06-22 21:15:35 -0400 (Wed, 22 Jun 2016) | 4 lines >>> >>> revert error commit from previous commit. my bad! >>> >>> Approved by: re (implicit) >>> >>> Head still doesn't compile doing: >>> >>> make -k -s -j24 tinderbox TARGETS="amd64 sparc64" >>> >>> Tinderbox failed: >>> amd64.amd64 buildworld failed, check _.amd64.amd64.buildworld for details >>> >>> ===> lib/csu/amd64 (obj) >>> ===> lib/csu/amd64 (all) >>> ===> lib/csu/amd64 (install) >>> bmake[6]: /usr/obj/p/fbsd/GIT/lib/libc/.depend.pipe.o, 5: ignoring stale >>> .depend >>> for /p/fbsd/GIT/lib/libc/amd64/sys/pipe.S >>> cc: error: no such file or directory: >>> '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' >>> cc: error: no input files >>> --- pipe.So --- >>> *** [pipe.So] Error code 1 >>> >>> bmake[6]: stopped in /p/fbsd/GIT/lib/libc >>> cc: error: no such file or directory: >>> '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' >>> cc: error: no input files >>> --- pipe.o --- >>> *** [pipe.o] Error code 1 >>> >> >> What revision? It builds for me on r302113. >> > > I see you mentioned the revision, sorry for not noticing. > > I think you hit a bug that brooks fixed later, which should build fine > now. > > Glen > OK, I'll update and try again. This spoiled all my builds on my sparc64 machines too. -Kurt From owner-freebsd-current@freebsd.org Thu Jun 23 05:54:59 2016 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 92AB6B72F9A for ; Thu, 23 Jun 2016 05:54:59 +0000 (UTC) (envelope-from lidl@FreeBSD.org) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 465E01F71; Thu, 23 Jun 2016 05:54:59 +0000 (UTC) (envelope-from lidl@FreeBSD.org) Received: from torb.pix.net (torb.pix.net [192.168.16.32]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id u5N5sw52094534; Thu, 23 Jun 2016 01:54:58 -0400 (EDT) (envelope-from lidl@FreeBSD.org) Subject: Re: head is broken after recent sys_pipe changes To: Glen Barber References: <4e11a1e3-2815-2979-822c-ddac44113392@pix.net> <20160623044406.GZ10155@FreeBSD.org> <20160623044528.GA10155@FreeBSD.org> <34e6a7d5-d96e-8277-3848-07aedf832c20@pix.net> Cc: FreeBSD-Current Reply-To: lidl@FreeBSD.org From: Kurt Lidl Message-ID: <1532f7dd-67e7-ee41-0456-8f2e50a74ca4@FreeBSD.org> Date: Thu, 23 Jun 2016 01:54:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <34e6a7d5-d96e-8277-3848-07aedf832c20@pix.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 05:54:59 -0000 On 6/23/16 12:46 AM, Kurt Lidl wrote: > On 6/23/16 12:45 AM, Glen Barber wrote: >> On Thu, Jun 23, 2016 at 04:44:06AM +0000, Glen Barber wrote: >>> On Thu, Jun 23, 2016 at 12:42:20AM -0400, Kurt Lidl wrote: >>>> As of this commit: >>>> >>>> r302106 | adrian | 2016-06-22 21:15:35 -0400 (Wed, 22 Jun 2016) | 4 >>>> lines >>>> >>>> revert error commit from previous commit. my bad! >>>> >>>> Approved by: re (implicit) >>>> >>>> Head still doesn't compile doing: >>>> >>>> make -k -s -j24 tinderbox TARGETS="amd64 sparc64" >>>> >>>> Tinderbox failed: >>>> amd64.amd64 buildworld failed, check _.amd64.amd64.buildworld for >>>> details >>>> >>>> ===> lib/csu/amd64 (obj) >>>> ===> lib/csu/amd64 (all) >>>> ===> lib/csu/amd64 (install) >>>> bmake[6]: /usr/obj/p/fbsd/GIT/lib/libc/.depend.pipe.o, 5: ignoring >>>> stale >>>> .depend >>>> for /p/fbsd/GIT/lib/libc/amd64/sys/pipe.S >>>> cc: error: no such file or directory: >>>> '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' >>>> cc: error: no input files >>>> --- pipe.So --- >>>> *** [pipe.So] Error code 1 >>>> >>>> bmake[6]: stopped in /p/fbsd/GIT/lib/libcr302114 >>>> cc: error: no such file or directory: >>>> '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' >>>> cc: error: no input files >>>> --- pipe.o --- >>>> *** [pipe.o] Error code 1 >>>> >>> >>> What revision? It builds for me on r302113. >>> >> >> I see you mentioned the revision, sorry for not noticing. >> >> I think you hit a bug that brooks fixed later, which should build fine >> now. >> >> Glen >> > > OK, I'll update and try again. This spoiled all my builds on my sparc64 > machines too. > > -Kurt I updated to r302114, deleted my /usr/obj tree for the amd64 build, and this time it successfully built. Sorry for the false alarm. I'll kick off my native sparc64 builds again. -Kurt From owner-freebsd-current@freebsd.org Thu Jun 23 05:58:00 2016 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 E4B97B730CA for ; Thu, 23 Jun 2016 05:58:00 +0000 (UTC) (envelope-from gjb@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 C9BFC2286; Thu, 23 Jun 2016 05:58:00 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 89FA91D52; Thu, 23 Jun 2016 05:58:00 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 23 Jun 2016 05:57:59 +0000 From: Glen Barber To: Kurt Lidl Cc: FreeBSD-Current Subject: Re: head is broken after recent sys_pipe changes Message-ID: <20160623055759.GD10155@FreeBSD.org> References: <4e11a1e3-2815-2979-822c-ddac44113392@pix.net> <20160623044406.GZ10155@FreeBSD.org> <20160623044528.GA10155@FreeBSD.org> <34e6a7d5-d96e-8277-3848-07aedf832c20@pix.net> <1532f7dd-67e7-ee41-0456-8f2e50a74ca4@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MEatx1zidE5asLAI" Content-Disposition: inline In-Reply-To: <1532f7dd-67e7-ee41-0456-8f2e50a74ca4@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 05:58:01 -0000 --MEatx1zidE5asLAI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 23, 2016 at 01:54:58AM -0400, Kurt Lidl wrote: > On 6/23/16 12:46 AM, Kurt Lidl wrote: > >On 6/23/16 12:45 AM, Glen Barber wrote: > >>On Thu, Jun 23, 2016 at 04:44:06AM +0000, Glen Barber wrote: > >>>On Thu, Jun 23, 2016 at 12:42:20AM -0400, Kurt Lidl wrote: > >>>>As of this commit: > >>>> > >>>>r302106 | adrian | 2016-06-22 21:15:35 -0400 (Wed, 22 Jun 2016) | 4 > >>>>lines > >>>> > >>>>revert error commit from previous commit. my bad! > >>>> > >>>>Approved by: re (implicit) > >>>> > >>>>Head still doesn't compile doing: > >>>> > >>>>make -k -s -j24 tinderbox TARGETS=3D"amd64 sparc64" > >>>> > >>>>Tinderbox failed: > >>>>amd64.amd64 buildworld failed, check _.amd64.amd64.buildworld for > >>>>details > >>>> > >>>>=3D=3D=3D> lib/csu/amd64 (obj) > >>>>=3D=3D=3D> lib/csu/amd64 (all) > >>>>=3D=3D=3D> lib/csu/amd64 (install) > >>>>bmake[6]: /usr/obj/p/fbsd/GIT/lib/libc/.depend.pipe.o, 5: ignoring > >>>>stale > >>>>.depend > >>>> for /p/fbsd/GIT/lib/libc/amd64/sys/pipe.S > >>>>cc: error: no such file or directory: > >>>>'/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' > >>>>cc: error: no input files > >>>>--- pipe.So --- > >>>>*** [pipe.So] Error code 1 > >>>> > >>>>bmake[6]: stopped in /p/fbsd/GIT/lib/libcr302114 > >>>>cc: error: no such file or directory: > >>>>'/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' > >>>>cc: error: no input files > >>>>--- pipe.o --- > >>>>*** [pipe.o] Error code 1 > >>>> > >>> > >>>What revision? It builds for me on r302113. > >>> > >> > >>I see you mentioned the revision, sorry for not noticing. > >> > >>I think you hit a bug that brooks fixed later, which should build fine > >>now. > >> > >>Glen > >> > > > >OK, I'll update and try again. This spoiled all my builds on my sparc64 > >machines too. > > > >-Kurt >=20 > I updated to r302114, deleted my /usr/obj tree for the amd64 build, and > this time it successfully built. >=20 > Sorry for the false alarm. >=20 > I'll kick off my native sparc64 builds again. >=20 No worries, but FWIW, non-X86 builds are part of my patch testing before replying to commit approval requests. (Unfortunately, I missed i386 in this case, but CI and all that crap). :) Glen --MEatx1zidE5asLAI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXa3pnAAoJEAMUWKVHj+KTkKYP/RHttjml3KIzfEP7XDCnoVfR KqbBL0XL+eYUL7b0b8q9al1iKcRTsyRE4r9dfzrX4khpOncOQQ+vX+XQZvx00/4x iC5GA73rrytX2HpXkDWfTDpM0OPSHXRmD1Jm3xs6YTM46DBmpJSI5sIyl2eKJ9VV ul2xgW8YBYDYRfeTstGSq45Xcdrc/FzWud+cqBCq6MowHnxUB1nyqwv/SK2Fpfvw apT6Wu+U7jRBsUv9rLK3CPmCpnoVeFakbqC4+rh/W1WEU2kQsgvCyFBPvwE2pLKz MK0PcPmwWqIDxgAfC432lGydZ36v7N3LBwCpgaSjKAEYMe3mzj9WuUrE9ChpEETd R9hhEO5uc5h06+FTW4UMJRBsAYa/a8T7yvFCFpGWiv4uHUCQXlasp1apnYqR3VZV MHJWKVrM2d+tl/wdnko/DthxWG4wIPwtvnNy0aHY6WUDPyNUJrLyjVVWe/Pza0Qc eOkm6VZfjisCKjK8RWNUDHod2LZbFE9DFM6osUpI9HY8EVYPkZuYjoaHzA853oGS GUO7wId3Lrc5npmWOf1uiqHWfM4fs0c62as4wD01yv6BCcRNI8dryPE+18UrxM+H NLeb4/Yt6d/2SuPwDd2RGGfYJaHD/WMHLo14O4oKeJ8jC/b6GvxB0zZz+a9Sscv2 5Ivt9CDTxvR0XACzpSdy =ALXP -----END PGP SIGNATURE----- --MEatx1zidE5asLAI-- From owner-freebsd-current@freebsd.org Thu Jun 23 06:03:52 2016 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 ADAD5B7327D for ; Thu, 23 Jun 2016 06:03:52 +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 6A50027D6 for ; Thu, 23 Jun 2016 06:03:52 +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 u5N63jB6058139 for ; Wed, 22 Jun 2016 23:03:49 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201606230603.u5N63jB6058139@gw.catspoiler.org> Date: Wed, 22 Jun 2016 23:03:45 -0700 (PDT) From: Don Lewis Subject: patch for potential race-condition triggered panic in dummynet PIE AQM To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 06:03:52 -0000 There is a race in the PIE AQM code that can cause a panic. A patch is up for review here: . I'd appreciate it if some callout gurus could take a look. From owner-freebsd-current@freebsd.org Thu Jun 23 06:19:10 2016 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 A4891B7353B for ; Thu, 23 Jun 2016 06:19:10 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6456C2EDE; Thu, 23 Jun 2016 06:19:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7402D25D3AB2; Thu, 23 Jun 2016 06:19:06 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B8A85D1F823; Thu, 23 Jun 2016 06:19:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id QCho6ajiRjm2; Thu, 23 Jun 2016 06:19:04 +0000 (UTC) Received: from [192.168.124.1] (unknown [IPv6:fde9:577b:c1a9:4410:21bf:e4ab:2432:b9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9C8CDD1F80E; Thu, 23 Jun 2016 06:19:03 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Kurt Lidl" Cc: "Glen Barber" , FreeBSD-Current Subject: Re: head is broken after recent sys_pipe changes Date: Thu, 23 Jun 2016 06:19:02 +0000 Message-ID: In-Reply-To: <1532f7dd-67e7-ee41-0456-8f2e50a74ca4@FreeBSD.org> References: <4e11a1e3-2815-2979-822c-ddac44113392@pix.net> <20160623044406.GZ10155@FreeBSD.org> <20160623044528.GA10155@FreeBSD.org> <34e6a7d5-d96e-8277-3848-07aedf832c20@pix.net> <1532f7dd-67e7-ee41-0456-8f2e50a74ca4@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate Trial (2.0BETAr6032) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 06:19:10 -0000 Hi, On 23 Jun 2016, at 5:54, Kurt Lidl wrote: > On 6/23/16 12:46 AM, Kurt Lidl wrote: >> On 6/23/16 12:45 AM, Glen Barber wrote: >>> On Thu, Jun 23, 2016 at 04:44:06AM +0000, Glen Barber wrote: >>>> On Thu, Jun 23, 2016 at 12:42:20AM -0400, Kurt Lidl wrote: >>>>> As of this commit: >>>>> >>>>> r302106 | adrian | 2016-06-22 21:15:35 -0400 (Wed, 22 Jun 2016) | >>>>> 4 >>>>> lines >>>>> >>>>> revert error commit from previous commit. my bad! >>>>> >>>>> Approved by: re (implicit) >>>>> >>>>> Head still doesn't compile doing: >>>>> >>>>> make -k -s -j24 tinderbox TARGETS="amd64 sparc64" >>>>> >>>>> Tinderbox failed: >>>>> amd64.amd64 buildworld failed, check _.amd64.amd64.buildworld for >>>>> details >>>>> >>>>> ===> lib/csu/amd64 (obj) >>>>> ===> lib/csu/amd64 (all) >>>>> ===> lib/csu/amd64 (install) >>>>> bmake[6]: /usr/obj/p/fbsd/GIT/lib/libc/.depend.pipe.o, 5: ignoring >>>>> stale >>>>> .depend >>>>> for /p/fbsd/GIT/lib/libc/amd64/sys/pipe.S >>>>> cc: error: no such file or directory: >>>>> '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' >>>>> cc: error: no input files >>>>> --- pipe.So --- >>>>> *** [pipe.So] Error code 1 >>>>> >>>>> bmake[6]: stopped in /p/fbsd/GIT/lib/libcr302114 >>>>> cc: error: no such file or directory: >>>>> '/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S' >>>>> cc: error: no input files >>>>> --- pipe.o --- >>>>> *** [pipe.o] Error code 1 >>>>> >>>> >>>> What revision? It builds for me on r302113. >>>> >>> >>> I see you mentioned the revision, sorry for not noticing. >>> >>> I think you hit a bug that brooks fixed later, which should build >>> fine >>> now. >>> >>> Glen >>> >> >> OK, I'll update and try again. This spoiled all my builds on my >> sparc64 >> machines too. >> >> -Kurt > > I updated to r302114, deleted my /usr/obj tree for the amd64 build, > and > this time it successfully built. > > Sorry for the false alarm. > > I'll kick off my native sparc64 builds again. My sparc64 cross-builds seem to still show an error; I am waiting for a full universe to finish currently to confirm this. Everything else so far looks good. /bz From owner-freebsd-current@freebsd.org Thu Jun 23 08:21:59 2016 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 CD5A1AC6540 for ; Thu, 23 Jun 2016 08:21:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 8D3241ACA for ; Thu, 23 Jun 2016 08:21:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1718 invoked from network); 23 Jun 2016 08:22:28 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 23 Jun 2016 08:22:28 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 23 Jun 2016 04:22:36 -0400 (EDT) Received: (qmail 24946 invoked from network); 23 Jun 2016 08:22:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 Jun 2016 08:22:36 -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 Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 4182C1C407A; Thu, 23 Jun 2016 01:21:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: WITH_SYSTEM_COMPILER default on From: Mark Millard In-Reply-To: <39C98FFD-B0BB-4F25-A1D1-2447A2FDDFBD@dsl-only.net> Date: Thu, 23 Jun 2016 01:21:49 -0700 Cc: freebsd-arm , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <6C3A4F2A-9583-49FB-B1E7-69A0044B3887@dsl-only.net> References: <39C98FFD-B0BB-4F25-A1D1-2447A2FDDFBD@dsl-only.net> To: Bryan Drewery , FreeBSD Current , FreeBSD Toolchain X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 08:21:59 -0000 On 2016-Jun-21, at 3:11 PM, Mark Millard wrote: > Bryan Drewery bdrewery at FreeBSD.org wrote on Tue Jun 21 19:03:46 UTC = 2016 : >=20 >> This feature is where the bootstrap compiler in buildworld is not = built >> if the one in /usr/bin/cc matches what would be built. It is very >> conservative and requires a complete match of major/minor version and >> the compiler revision (__FreeBSD_cc_version). >>=20 >> The only complaint so far about this feature was that when we bumped = the >> compiler revision, too much of clang would rebuild. That was = addressed >> in r301277. >>=20 >> I would like to enable this feature by default in head for 11.0. >>=20 >> Unless there are any objections I will do so in a few days. >>=20 >> --=20 >> Regards, >> Bryan Drewery >=20 > I've only been using WITH_SYSTEM_COMPILER=3D for system-clang based = builds with the host matching TARGET_ARCH ("self hosted"). >=20 > For xtoolchain use (self-hosted or not) I've been using in my src.conf = files for such contexts:=20 >=20 > WITHOUT_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > WITHOUT_BINUTILS_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D >=20 > For cross builds (all being amd64 -> something else, such as armv6, = powerpc64, or powerpc) based on using some build of the system clang = 3.8.0 I've been using: >=20 > WITH_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG_BOOTSTRAP=3D >=20 > As I understand the history the paths for finding tools, headers, etc. = built into the clang cross compiler were not necessarily the same as for = the live the system compiler that has paths appropriate specifically to = self-hosting. This helped avoid getting the wrong versions of files = involved. A historical example was cross builds running the live-system's ld when = the use of ld was implicit in a clang/clang++ command instead of being a = direct use of ${XLD}. In other words: such implicit use of ld by /usr/bin/clang and = /usr/bin/clang++ would not go find the ld built by = WITH_BINUTILS_BOOTSTRAP=3D but would instead use /usr/bin/ld (which was = for the wrong TARGET_ARCH). It looks like testing the current handling of such WITH_SYSTEM_COMPILER=3D= issues in a form that allows WITHOUT_CROSS_COMPILER=3D operation = requires building not using WITH_META_MODE=3D : man src.conf says that = WITH_META_MODE=3D enforces WITHOUT_SYSTEM_COMPILER=3D . My normal build procedures now use WITH_META_MODE=3D so such a test = would be special. Let me know if you want my to make such a test. > This was true despite the normal clang code generation being able to = target other architectures. >=20 > As for self-hosted system-clang based builds I've been using: >=20 > #WITH_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > WITH_BINUTILS_BOOTSTRAP=3D > #WITH_CLANG_BOOTSTRAP=3D >=20 > (So in this case I've left some things implicit in operation.) >=20 > As stands I'll not notice the SYSTEM_COMPILER default's consequences = because I'm always explicit about WITH vs. WITHOUT for SYSTM_COMPILER. = If you want some sort of experiment(s), let me know. >=20 > But I only currently have an amd64 context and a rpi2 armv6 context. = The dual-proessor, each dual-core powerpc64 was much faster at = self-hosted xtoolchain builds compared to any self-hosted rpi2 build but = I do not have access to the powerpc family for now. Self-hosted amd64 = xtoolchain builds do not work yet for normal settings: duplicate = declarations tend to stop the builds if one leaves on the = warnings-as-errors status for buildkernel. (At least last that I tried = such.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Jun 23 08:54:50 2016 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 9F163AC6ECF for ; Thu, 23 Jun 2016 08:54:50 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 31DBA11B2 for ; Thu, 23 Jun 2016 08:54:50 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id v199so117216749wmv.0 for ; Thu, 23 Jun 2016 01:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=IX6JeH/ZG6Sk5sux844iwaNt4bQUY9p/8IFuRENLGj4=; b=S2ArQsyAOTb/Qaf7OOBEVB7mNZIDCzMnC6GNWoVGzlz2fC/kf2J4O9Q+vGzeVle2Md mRsSTvRd4UhSq81Kdi8RsIRt9JGsFiYcB/lDKXW30WCrbbqW5TMMevMR5ZO0TCsf2a5Y U8rVeJt1RLUSLwW1HCxp2ATiHxKgUE9EDjIrufJAh8GeU3XNh78zYQJ+52ljnaN5WoYu eaWdNIBQQGYuzJUsT+qJOWqEkuNsI4Ky5kxugb/yTwDnQHxk0h2BeJI66p9uSD47xo8P fe9UVHUEOpfAXgfvw7b+sZhQGR2IZVxQodMiOiaY/NT2Su2572YRAOaozavUdE0BwMJm nvhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IX6JeH/ZG6Sk5sux844iwaNt4bQUY9p/8IFuRENLGj4=; b=XwBxN7+PyEYVIwESg0NCm7m3ztZq0omgB9h42TsBtLXH3JYdo20HYZJX3TopFVCqfs BPYSsHAdFOs/vZvRidk5h4EHsb0YNabBmbuTDBo78R2eYtveksgjhXcUoAqjrQpbHRAB wQ+Mi2vgbQcZ7oeXdJBal2CyECGovttt61QkGBY41DjefEBeDpM7K/XzC95TVo0nL35h F/mveqpn6Od37hPXcZBLKz8k4dv2TVo577OAMIeB0K0UIh6LhgsXDn/Z2nAnbNV5C82j D1CpwKlpceeQ26rWXt4/ecqKsFzdkphje2G4800xxITsNyNbA6H8v+v6jJ772FJ8g5LA tOUQ== X-Gm-Message-State: ALyK8tIoEbLVQmXY0JzFI625jlIKxPU7Hpdy0/3C7MYizcjIxuc1YphFrtWdRZItrQX0QQ== X-Received: by 10.28.173.8 with SMTP id w8mr12245293wme.39.1466672088129; Thu, 23 Jun 2016 01:54:48 -0700 (PDT) Received: from Johans-MacBook-Air-2.local (92-111-79-242.static.chello.nl. [92.111.79.242]) by smtp.googlemail.com with ESMTPSA id k3sm3294419wju.29.2016.06.23.01.54.47 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Jun 2016 01:54:47 -0700 (PDT) Subject: Re: Fatal trap 12 To: freebsd-current@freebsd.org References: <20160622203636.050ac83a@nonamehost.local> <20160622204526.427fa6ea@nonamehost.local> <20160622205607.472ea221@nonamehost.local> <589E375F-8518-4849-AA0C-E4FE8F1D85E1@lists.zabbadoz.net> From: Johan Hendriks Message-ID: <72a04a4e-f210-7f44-20df-1834bb86c08c@gmail.com> Date: Thu, 23 Jun 2016 10:54:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <589E375F-8518-4849-AA0C-E4FE8F1D85E1@lists.zabbadoz.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 08:54:50 -0000 I have the following in my kernel config # pf options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ device pf device pflog device pfsync I can not alter the order the modules load as far as I know. I changed the following in /usr/src/sys/netpfil/pf/if_pflog.c from DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); to DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PROTO_FIREWALL, SI_ORDER_ANY); But after a buildworld the same error. Op 23/06/16 om 02:01 schreef Bjoern A. Zeeb: > On 22 Jun 2016, at 17:56, Ivan Klymenko wrote: > >> On Wed, 22 Jun 2016 20:45:26 +0300 >> Ivan Klymenko wrote: >> >>> On Wed, 22 Jun 2016 20:36:36 +0300 >>> Ivan Klymenko wrote: >>> >>>> Hello. >>>> After update from r302000 to r302083 i have panic >>>> http://i.imgur.com/YfvvhdS.png >>>> >>>> Thanks. >>> Sorry, the first time discovered a revision r302060. >> >> There is a suspicion that the reason for this commit: >> https://svnweb.freebsd.org/base?view=revision&revision=302054 > > Do you compile pflog into the kernel or load it from loader by any > chance? I can see what might happen here. > > Can you try to see if this goes away if you load pflog after pf is > loaded? If that helps change the SI_SUB_PSEUDO at the end of > sys/netpfil/pf/if_pflog.c to SI_SUB_PROTO_FIREWALL ; that should fix it. > > /bz > _______________________________________________ > 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 Jun 23 09:24:55 2016 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 3E619A790AE for ; Thu, 23 Jun 2016 09:24:55 +0000 (UTC) (envelope-from joh.hendriks@gmail.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 D77732F94 for ; Thu, 23 Jun 2016 09:24:54 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id a66so40728764wme.0 for ; Thu, 23 Jun 2016 02:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=klhNSR2l6YLT7MQChPRinem4a71KKydjvWhbOIggSvk=; b=Qwr1sF7DGiCJMOfh41ItWuqmC0LdFilXFZcSX2oty3GbaTMrMun+nozcVmxFb6j3pA lXSW+yx964YMzJjkE1YJaZybXhCtuq56AmZTgRTQ5Yr6Y/BlQ6Y2I5KZv8Ye1QyY+dp+ k0YvX6sap04Qr6Nc2kJyUNIv3U81CvprbtIYH25ZYlpnELr4XmubyMAMxLbKHXZLkQZd 8UCi35a9+AG55jpvJf2Hoqee1AfZ3/V0dBpRURB25zU5V8qUQepc5Zb3QperkPhsKv+d 4iQGIjyKqk0yUon+4RiG1Hwn9zVNRPe0qsnhYQNR1XHp5u14ag553+qvZV/h9NtmgTIx G3Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=klhNSR2l6YLT7MQChPRinem4a71KKydjvWhbOIggSvk=; b=UgZGyEmX98tJMwDR1FYxUj99shbOdCaEBreuvFGXOVg+zCrjZTWfZiE1clsj9LuZJ7 +QgGlxHrxx+hkYsv1jK1CZiKfny+bVN8vifqCd353+spfPmRbjHV/+bDYlVW0bMSPoFU jN4KNI/NSnRfKkM0CTlUAQuZ1ygKBW2Xz0135HQVak8ZWY5Vi8fstqXEQQy+aRwZmSKt ndYVD3DjISWpXk8ZN3Dvh1MzWtA+zzX0/4GqrvESYt5VsC2btUoc6+hjV61d1pnRuA11 SCMNvkt3ABf1hx3VJTAlIXhMETVYovo2pZqoQ4vfR34BWCvLlAguyIeaAKWz/hg7ycSc Tidw== X-Gm-Message-State: ALyK8tKSKgDBTh9JlGebBXYqE2XI7AdQktIqom7wOhP6L7TOWARbkv5e5lQZY/b3yaNd4g== X-Received: by 10.194.159.98 with SMTP id xb2mr31958895wjb.29.1466673893147; Thu, 23 Jun 2016 02:24:53 -0700 (PDT) Received: from Johans-MacBook-Air-2.local (92-111-79-242.static.chello.nl. [92.111.79.242]) by smtp.googlemail.com with ESMTPSA id b4sm3448839wjd.16.2016.06.23.02.24.52 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Jun 2016 02:24:52 -0700 (PDT) Subject: Re: Fatal trap 12 To: freebsd-current@freebsd.org References: <20160622203636.050ac83a@nonamehost.local> <20160622204526.427fa6ea@nonamehost.local> <20160622205607.472ea221@nonamehost.local> <589E375F-8518-4849-AA0C-E4FE8F1D85E1@lists.zabbadoz.net> From: Johan Hendriks Message-ID: <047919a8-8e50-152e-8ff2-20dc049035d1@gmail.com> Date: Thu, 23 Jun 2016 11:24:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <589E375F-8518-4849-AA0C-E4FE8F1D85E1@lists.zabbadoz.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 09:24:55 -0000 I just removed the following from my kernel file #device pf #device pflog #device pfsync Changed back the SI_SUB_PSEUDO in sys/netpfil/pf/if_pflog.c Rebuild the kernel and now the kernel is booting normally. regards Johan Op 23/06/16 om 02:01 schreef Bjoern A. Zeeb: > On 22 Jun 2016, at 17:56, Ivan Klymenko wrote: > >> On Wed, 22 Jun 2016 20:45:26 +0300 >> Ivan Klymenko wrote: >> >>> On Wed, 22 Jun 2016 20:36:36 +0300 >>> Ivan Klymenko wrote: >>> >>>> Hello. >>>> After update from r302000 to r302083 i have panic >>>> http://i.imgur.com/YfvvhdS.png >>>> >>>> Thanks. >>> Sorry, the first time discovered a revision r302060. >> >> There is a suspicion that the reason for this commit: >> https://svnweb.freebsd.org/base?view=revision&revision=302054 > > Do you compile pflog into the kernel or load it from loader by any > chance? I can see what might happen here. > > Can you try to see if this goes away if you load pflog after pf is > loaded? If that helps change the SI_SUB_PSEUDO at the end of > sys/netpfil/pf/if_pflog.c to SI_SUB_PROTO_FIREWALL ; that should fix it. > > /bz > _______________________________________________ > 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 Jun 23 09:25:13 2016 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 62FB7A790E8 for ; Thu, 23 Jun 2016 09:25:13 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv157.fwdcdn.com (frv157.fwdcdn.com [212.42.77.157]) (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 27E7F1194 for ; Thu, 23 Jun 2016 09:25:12 +0000 (UTC) (envelope-from fidaj@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=OlhID2S1pprDoeq5KMaQVK4164ZT8QpGt/kIrdgMSy8=; b=eNkxu6RF8PVK5QvC73SEYgO5C4fyDPeZDYvbhdxwyjYi79cvKWk769UzizlF1cs/xyndcZ5Q914h9NCjv4IBSh6Wh5aCGiVKzYTobTv7xAZk5WYbW9h089YCU5JuPNYCzEopl2pP8jewADLSTzY/3WLzisbdmS3WNvL7Zz5O3rk=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1bG0sn-0007wT-8k ; Thu, 23 Jun 2016 12:25:09 +0300 Date: Thu, 23 Jun 2016 12:25:08 +0300 From: Ivan Klymenko To: Johan Hendriks Cc: freebsd-current@freebsd.org Subject: Re: Fatal trap 12 Message-ID: <20160623122508.73262da4@nonamehost.local> In-Reply-To: <72a04a4e-f210-7f44-20df-1834bb86c08c@gmail.com> References: <20160622203636.050ac83a@nonamehost.local> <20160622204526.427fa6ea@nonamehost.local> <20160622205607.472ea221@nonamehost.local> <589E375F-8518-4849-AA0C-E4FE8F1D85E1@lists.zabbadoz.net> <72a04a4e-f210-7f44-20df-1834bb86c08c@gmail.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 09:25:13 -0000 On Thu, 23 Jun 2016 10:54:46 +0200 Johan Hendriks wrote: > I have the following in my kernel config > # pf > options ALTQ > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_CDNR > options ALTQ_PRIQ > device pf > device pflog > device pfsync > > I can not alter the order the modules load as far as I know. > I changed the following in /usr/src/sys/netpfil/pf/if_pflog.c > > from > > DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); > > to > > DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PROTO_FIREWALL, SI_ORDER_ANY); > > But after a buildworld the same error. > +1 > Do you compile pflog into the kernel or load it from loader by any > chance? I can see what might happen here. Yes, i have kernel options: device pf device pflog device pfsync ALTQ... > > Can you try to see if this goes away if you load pflog after pf is > loaded? If that helps change the SI_SUB_PSEUDO at the end of > sys/netpfil/pf/if_pflog.c to SI_SUB_PROTO_FIREWALL ; that should fix This does not solve the problem. From owner-freebsd-current@freebsd.org Thu Jun 23 12:53:51 2016 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 E084FA7A642 for ; Thu, 23 Jun 2016 12:53:51 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "courriel.site.uottawa.ca", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 926862DDC for ; Thu, 23 Jun 2016 12:53:50 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from [10.0.2.15] (ppp-66-185-207-71.vianet.ca [66.185.207.71]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id u5NCrfxa093368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 23 Jun 2016 08:53:42 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Thu, 23 Jun 2016 08:53:39 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: freebsd-current@freebsd.org Subject: gstat(8) regression Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 12:53:52 -0000 This regression still exists as of r302073: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204852 Run /usr/sbin/gstat, press 'q' Prior to 11-CURRENT gstat would exit. "Currently" gstat regressively also requires . ...keith From owner-freebsd-current@freebsd.org Thu Jun 23 16:45:38 2016 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 06E7AB73905 for ; Thu, 23 Jun 2016 16:45:38 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BC77110FC for ; Thu, 23 Jun 2016 16:45:37 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 579AE25D37C2; Thu, 23 Jun 2016 16:45:34 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 98851D1F813; Thu, 23 Jun 2016 16:45:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id GiaNzFEfzgrC; Thu, 23 Jun 2016 16:45:32 +0000 (UTC) Received: from [192.168.124.1] (unknown [IPv6:fde9:577b:c1a9:4410:21bf:e4ab:2432:b9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id DB4C8D1F7F8; Thu, 23 Jun 2016 16:45:31 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Ivan Klymenko" Cc: "Johan Hendriks" , freebsd-current@freebsd.org Subject: Re: Fatal trap 12 Date: Thu, 23 Jun 2016 16:45:30 +0000 Message-ID: In-Reply-To: <20160623122508.73262da4@nonamehost.local> References: <20160622203636.050ac83a@nonamehost.local> <20160622204526.427fa6ea@nonamehost.local> <20160622205607.472ea221@nonamehost.local> <589E375F-8518-4849-AA0C-E4FE8F1D85E1@lists.zabbadoz.net> <72a04a4e-f210-7f44-20df-1834bb86c08c@gmail.com> <20160623122508.73262da4@nonamehost.local> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate Trial (2.0BETAr6032) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 16:45:38 -0000 Hi, can you try checking out svn://svn.freebsd.org/base/projects/vnet and see if a kernel from there works better? It contains further pf/pflog/pfsync changes; mostly for VIMAGE which will go into head the next days. Thanks /bz From owner-freebsd-current@freebsd.org Thu Jun 23 21:07:52 2016 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 A3F3DB738A7 for ; Thu, 23 Jun 2016 21:07:52 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 831E32CDD for ; Thu, 23 Jun 2016 21:07:52 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 702495A9F09; Thu, 23 Jun 2016 21:07:51 +0000 (UTC) Date: Thu, 23 Jun 2016 21:07:51 +0000 From: Brooks Davis To: freebsd-current@freebsd.org Subject: HEADS UP: caution required with updates using custom kernels Message-ID: <20160623210751.GB7860@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 21:07:52 -0000 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kernel config minimalists and those running aarch64 and riscv systems will want to head this UPDATING message. In practice, if you're fairly up to date, doing installworld before installkernel will also work (I've tested that case from ALPHA4), but is always somewhat risky. -- Brooks ----- Forwarded message from Brooks Davis ----- Date: Thu, 23 Jun 2016 21:02:05 +0000 (UTC) =46rom: Brooks Davis To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r302152 - head Author: brooks Date: Thu Jun 23 21:02:05 2016 New Revision: 302152 URL: https://svnweb.freebsd.org/changeset/base/302152 Log: Add an UPDATING entry for the pipe() -> pipe2() transition. =20 Approved by: re (gjb) Sponsored by: DARPA, AFRL Modified: head/UPDATING Modified: head/UPDATING =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/UPDATING Thu Jun 23 20:59:13 2016 (r302151) +++ head/UPDATING Thu Jun 23 21:02:05 2016 (r302152) @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11 disable the most expensive debugging functionality run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) =20 +20160622: + The the libc stub for the pipe(2) system call has been replaced with + a wrapper which calls the pipe2(2) system call and the pipe(2) is now + only implemented by the kernels which include "options + FREEBSD10_COMPAT" in their config file (this is the default). + Users should ensure that this option is enabled in their kernel + or upgrade userspace to r302092 before upgrading their kernel. + 20160527: CAM will now strip leading spaces from SCSI disks' serial numbers. This will effect users who create UFS filesystems on SCSI disks using ----- End forwarded message ----- --l76fUT7nc3MelDdI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXbE+mAAoJEKzQXbSebgfA72UH/0uku/f6d8UhC9CzNGBFvphB huX1TGuXSqZbO7a2Tr4ILUDa4eiMtXF8I48qy+JKr+JBdWlWuz2VnTKIwb14pAt0 9gdJAsHSTmrJMFsQ5e274NkuVdSMBKmbnKOm7V66m7PIcvw+6Z41JEN1rDVI/kR8 ECKBJmS7xnfek7qoNdeAWeId/ZfwIFZkIfX2flTEf/0mGRjrRCzqrh4BGQMuk7pc 9CctlRxpXy3/RAiXVMi574WN7ncczOCnZxQYQUnWqG72hYarbGYsePgcezaeqaJ0 o/AX+QdGUaKkS3fmACv1PdQyE2bcSWk8AcL5WsBOmKsCDRquwx3d4nEjoaZ4UGI= =PJQF -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI-- From owner-freebsd-current@freebsd.org Thu Jun 23 22:31:47 2016 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 0193BB74D40; Thu, 23 Jun 2016 22:31:47 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BC4CE2BB3; Thu, 23 Jun 2016 22:31:46 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id DE525358C5A; Fri, 24 Jun 2016 00:31:43 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id CC6BE28494; Fri, 24 Jun 2016 00:31:43 +0200 (CEST) Date: Fri, 24 Jun 2016 00:31:43 +0200 From: Jilles Tjoelker To: Maxim Sobolev Cc: Konstantin Belousov , John Baldwin , Adrian Chadd , Alan Somers , Alan Cox , Alan Cox , freebsd-current , performance@freebsd.org, "current@freebsd.org" Subject: Re: PostgreSQL performance on FreeBSD Message-ID: <20160623223143.GC5381@stack.nl> References: <20140627125613.GT93733@kib.kiev.ua> <1603235.2ShtoCfSqO@ralph.baldwin.cx> <20160622100241.GM38613@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 23 Jun 2016 22:50:08 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Jun 2016 22:31:47 -0000 On Wed, Jun 22, 2016 at 07:26:52AM -0700, Maxim Sobolev wrote: > Konstantin, > Not if you do sem_unlink() immediately, AFAIK. And that's what PG does. So > the window of opportunity for the leakage is quite small, much smaller than > for SYSV primitives. Sorry for missing your status update message, I've > missed it somehow. True, but if your process architecture supports that, you can also put unnamed process-shared semaphores into a piece of shared memory (pad sem_t to a cache line if contention is expected). This is more natural API use (fully avoiding the leak) and uses less memory. It has been supported for a long time, at least since FreeBSD 9.0. Process-shared mutexes, condition variables, reader/writer locks, etc. are available in FreeBSD 11 but use more memory (a 1-page object per synchronization object), somewhat like named semaphores. -- Jilles Tjoelker From owner-freebsd-current@freebsd.org Fri Jun 24 00:27:29 2016 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 18C63AC6E77; Fri, 24 Jun 2016 00:27:29 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from mail01.lax1.stackjet.com (mon01.lax1.stackjet.com [174.136.104.178]) (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 DE5432F2C; Fri, 24 Jun 2016 00:27:28 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from [172.20.10.9] (unknown [172.56.39.215]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sean@chittenden.org) by mail01.lax1.stackjet.com (Postfix) with ESMTPSA id 1E1BD2F88F5; Thu, 23 Jun 2016 17:19:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: PostgreSQL performance on FreeBSD From: Sean Chittenden In-Reply-To: Date: Thu, 23 Jun 2016 15:42:32 -0700 Cc: Konstantin Belousov , Adrian Chadd , performance@freebsd.org, John Baldwin , Alan Somers , Alan Cox , Alan Cox , freebsd-current , "current@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140627125613.GT93733@kib.kiev.ua> <1603235.2ShtoCfSqO@ralph.baldwin.cx> <20160622100241.GM38613@kib.kiev.ua> To: Maxim Sobolev X-Mailer: Apple Mail (2.3124) X-Mailman-Approved-At: Fri, 24 Jun 2016 01:15:42 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 00:27:29 -0000 Small nit: PostgreSQL used SYSV because it allowed for the detection of dead = processes. If you `kill -9`=E2=80=99ed a process, PostgreSQL can detect = that and then shut down and perform an automatic recovery. In this = regard, sysv is pretty clever. The move to POSIX shared mem was done = for a host of reasons, but it means that you don=E2=80=99t have to = adjust your SYSV limits. My understanding from a few years ago is that = there is still a ~64KB SYSV memory segment that is still used to act as = the latch to signal if a process was killed, but all of the shared = buffers are stored in posix mmap=E2=80=99ed regions. At this point in time this could be replaced with kqueue(2) EVFILT_PROC, = but no one has done that yet. -sc -- Sean Chittenden sean@chittenden.org > On Jun 22, 2016, at 07:26 , Maxim Sobolev wrote: >=20 > Konstantin, >=20 > Not if you do sem_unlink() immediately, AFAIK. And that's what PG = does. So > the window of opportunity for the leakage is quite small, much smaller = than > for SYSV primitives. Sorry for missing your status update message, = I've > missed it somehow. >=20 > ---- > mySem =3D sem_open(semname, O_CREAT | O_EXCL, > (mode_t) = IPCProtection, > (unsigned) 1); >=20 > #ifdef SEM_FAILED > if (mySem !=3D (sem_t *) SEM_FAILED) > break; > #else > if (mySem !=3D (sem_t *) (-1)) > break; > #endif >=20 > /* Loop if error indicates a collision */ > if (errno =3D=3D EEXIST || errno =3D=3D EACCES || errno = =3D=3D EINTR) > continue; >=20 > /* > * Else complain and abort > */ > elog(FATAL, "sem_open(\"%s\") failed: %m", semname); > } >=20 > /* > * Unlink the semaphore immediately, so it can't be accessed > externally. > * This also ensures that it will go away if we crash. > */ > sem_unlink(semname); >=20 > return mySem; > ---- >=20 > -Max >=20 > On Wed, Jun 22, 2016 at 3:02 AM, Konstantin Belousov = > wrote: >=20 >> On Tue, Jun 21, 2016 at 12:48:00PM -0700, Maxim Sobolev wrote: >>> Thanks, Konstantin for the great work, we are definitely looking = forward >> to >>> get all those improvements to be part of the default FreeBSD = kernel/port. >>> Would be nice if you can post an update some day later as to what's >>> integrated and what's not. >> I did posted the update several days earlier. Since you replying to = this >> thread, it would be not unreasonable to read recent messages that = were >> sent. >>=20 >>>=20 >>> Just in case, I've opened #14206 with PG to switch us to using POSIX >>> semaphores by default. Apart from the mentioned performance = benefits, >> SYSV >>> semaphores are PITA to deal with as they come in very limited = quantities >> by >>> default. Also they might stay around if PG dies/gets nuked and = prevent it >>> from starting again due to overflow. We've got some quite ugly code = to >>> clean up those using ipcrm(1) in our build scripts to deal with just >> that. >>> I am happy that code could be retired now. >>=20 >> Named semaphores also stuck around if processes are killed without = cleanup. >>=20 >>=20 > _______________________________________________ > freebsd-performance@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to = "freebsd-performance-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Jun 24 04:00:24 2016 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 27636B7405C for ; Fri, 24 Jun 2016 04:00:24 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 DEEA71302; Fri, 24 Jun 2016 04:00:23 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bGIHt-003HUz-LZ>; Fri, 24 Jun 2016 06:00:13 +0200 Received: from x55b38678.dyn.telefonica.de ([85.179.134.120] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bGIHt-003IU1-8E>; Fri, 24 Jun 2016 06:00:13 +0200 Date: Fri, 24 Jun 2016 06:00:19 +0200 From: "O. Hartmann" To: Brooks Davis Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> In-Reply-To: <20160623210751.GB7860@spindle.one-eyed-alien.net> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/ryuPDdHnuhiiYjNnIRXfYn9"; protocol="application/pgp-signature" X-Originating-IP: 85.179.134.120 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 04:00:24 -0000 --Sig_/ryuPDdHnuhiiYjNnIRXfYn9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 23 Jun 2016 21:07:51 +0000 Brooks Davis schrieb: > Kernel config minimalists and those running aarch64 and riscv systems will > want to head this UPDATING message. >=20 > In practice, if you're fairly up to date, doing installworld before > installkernel will also work (I've tested that case from ALPHA4), but is > always somewhat risky. >=20 > -- Brooks >=20 > ----- Forwarded message from Brooks Davis ----- >=20 > Date: Thu, 23 Jun 2016 21:02:05 +0000 (UTC) > From: Brooks Davis > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > Subject: svn commit: r302152 - head >=20 > Author: brooks > Date: Thu Jun 23 21:02:05 2016 > New Revision: 302152 > URL: https://svnweb.freebsd.org/changeset/base/302152 >=20 > Log: > Add an UPDATING entry for the pipe() -> pipe2() transition. > =20 > Approved by: re (gjb) > Sponsored by: DARPA, AFRL >=20 > Modified: > head/UPDATING >=20 > Modified: head/UPDATING > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/UPDATING Thu Jun 23 20:59:13 2016 (r302151) > +++ head/UPDATING Thu Jun 23 21:02:05 2016 (r302152) > @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11 > disable the most expensive debugging functionality run > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > =20 > +20160622: > + The the libc stub for the pipe(2) system call has been replaced with > + a wrapper which calls the pipe2(2) system call and the pipe(2) is now > + only implemented by the kernels which include "options > + FREEBSD10_COMPAT" in their config file (this is the default). > + Users should ensure that this option is enabled in their kernel > + or upgrade userspace to r302092 before upgrading their kernel. > + > 20160527: > CAM will now strip leading spaces from SCSI disks' serial numbers. > This will effect users who create UFS filesystems on SCSI disks using >=20 >=20 > ----- End forwarded message ----- Is this showing up, when one doesn't have the expected COMPAT_FREEBSD10 in = kernel and updated kernel __before___ world?: most recent CURRENT (FreeBSD 11.0-ALPHA4 #41 r302149: Thu Jun 23 21:58:25 C= EST 2016 amd64, custom kernel) dies when trying to make buildworld=20 or make buildkernel/kernel with the message shown below: root@localhost: [src] make buildkernel *** Signal 12 Stop. make: stopped in /usr/src .ERROR_TARGET=3D'buildkernel' .ERROR_META_FILE=3D'' .MAKE.LEVEL=3D'0' MAKEFILE=3D'' .MAKE.MODE=3D'normal' .CURDIR=3D'/usr/src' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/usr/src' .TARGETS=3D'buildkernel' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20160606' PATH=3D'/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/usr/src' Regards, oh --Sig_/ryuPDdHnuhiiYjNnIRXfYn9 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXbLBTAAoJEOgBcD7A/5N8IEgIALP7SSw2kVzR9NsQt3G6e7cm ppC6aTrsc03C5mTCAs5nrRiir00V0TtXlKUwarYmbYAbD67yZyiSqfsPsAtia4dm G0UMkAERrgDIOSQjuOulAvMCJy5MYGwZGI/H7qKHY3i+mdZ3PQGJQU7EyXQup8Iw kOCqF2voJagLKMQry4MujEu+w1HsuZHBBMYwArH1l063lsJdI/LJOeOoQ2OyIf7F NSmgX5JGYaxkHPtwx3RViw3oc0ni3WarTjQDmax/Dsj71hxQKDCm87zOPQDYWZIn IbakkJU4sku82u+VQ0ytynNZK4q4CTW8t8ncAHEMJ9qyqxpPp2rmcxJP6KmlNrk= =KV7v -----END PGP SIGNATURE----- --Sig_/ryuPDdHnuhiiYjNnIRXfYn9-- From owner-freebsd-current@freebsd.org Fri Jun 24 07:41:46 2016 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 E533DA7712C for ; Fri, 24 Jun 2016 07:41:46 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv157.fwdcdn.com (frv157.fwdcdn.com [212.42.77.157]) (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 A80F92AEF for ; Fri, 24 Jun 2016 07:41:46 +0000 (UTC) (envelope-from fidaj@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Ff0I/8ksqEMjmujcnnbbElMpf1JASb9ix7CiwhvI7Uo=; b=la24nP/hn29ibub7xrZZwsGpXBVRUQrp2fuXh2HzXX77CRmxSwMqVZ6+66u/6kwGRiVXDbhoTrpxtJzzgR7S8qSsCPuNp+jKfrN7Ivsdqs7gWodZ6HqZPzmd9SSTQ3JfShJ1i5ePtQ4/va4brOXxGaJ8PPvIb1XFI0rvL+VmSFE=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1bGLk8-0002jV-HX ; Fri, 24 Jun 2016 10:41:36 +0300 Date: Fri, 24 Jun 2016 10:41:35 +0300 From: Ivan Klymenko To: "Bjoern A. Zeeb" Cc: "Johan Hendriks" , freebsd-current@freebsd.org Subject: Re: Fatal trap 12 Message-ID: <20160624104135.4f93c40b@nonamehost.local> In-Reply-To: References: <20160622203636.050ac83a@nonamehost.local> <20160622204526.427fa6ea@nonamehost.local> <20160622205607.472ea221@nonamehost.local> <589E375F-8518-4849-AA0C-E4FE8F1D85E1@lists.zabbadoz.net> <72a04a4e-f210-7f44-20df-1834bb86c08c@gmail.com> <20160623122508.73262da4@nonamehost.local> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 07:41:47 -0000 On Thu, 23 Jun 2016 16:45:30 +0000 "Bjoern A. Zeeb" wrote: > Hi, > > can you try checking out svn://svn.freebsd.org/base/projects/vnet and > see if a kernel from there works better? > > It contains further pf/pflog/pfsync changes; mostly for VIMAGE which > will go into head the next days. > > > Thanks > > /bz Update to r302164 - solved problem. Thanks! From owner-freebsd-current@freebsd.org Fri Jun 24 15:51:12 2016 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 41967B80B3B for ; Fri, 24 Jun 2016 15:51:12 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 0202425C6 for ; Fri, 24 Jun 2016 15:51:12 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 0C5EC5A9F27; Fri, 24 Jun 2016 15:51:11 +0000 (UTC) Date: Fri, 24 Jun 2016 15:51:11 +0000 From: Brooks Davis To: "O. Hartmann" Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160624155111.GB20770@spindle.one-eyed-alien.net> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hQiwHBbRI9kgIhsi" Content-Disposition: inline In-Reply-To: <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 15:51:12 -0000 --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: > Am Thu, 23 Jun 2016 21:07:51 +0000 > Brooks Davis schrieb: >=20 > > Kernel config minimalists and those running aarch64 and riscv systems w= ill > > want to head this UPDATING message. > >=20 > > In practice, if you're fairly up to date, doing installworld before > > installkernel will also work (I've tested that case from ALPHA4), but is > > always somewhat risky. > >=20 > > -- Brooks > >=20 > > ----- Forwarded message from Brooks Davis ----- > >=20 > > Date: Thu, 23 Jun 2016 21:02:05 +0000 (UTC) > > From: Brooks Davis > > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > > svn-src-head@freebsd.org > > Subject: svn commit: r302152 - head > >=20 > > Author: brooks > > Date: Thu Jun 23 21:02:05 2016 > > New Revision: 302152 > > URL: https://svnweb.freebsd.org/changeset/base/302152 > >=20 > > Log: > > Add an UPDATING entry for the pipe() -> pipe2() transition. > > =20 > > Approved by: re (gjb) > > Sponsored by: DARPA, AFRL > >=20 > > Modified: > > head/UPDATING > >=20 > > Modified: head/UPDATING > > =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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > --- head/UPDATING Thu Jun 23 20:59:13 2016 (r302151) > > +++ head/UPDATING Thu Jun 23 21:02:05 2016 (r302152) > > @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11 > > disable the most expensive debugging functionality run > > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > > =20 > > +20160622: > > + The the libc stub for the pipe(2) system call has been replaced with > > + a wrapper which calls the pipe2(2) system call and the pipe(2) is now > > + only implemented by the kernels which include "options > > + FREEBSD10_COMPAT" in their config file (this is the default). > > + Users should ensure that this option is enabled in their kernel > > + or upgrade userspace to r302092 before upgrading their kernel. > > + > > 20160527: > > CAM will now strip leading spaces from SCSI disks' serial numbers. > > This will effect users who create UFS filesystems on SCSI disks using > >=20 > >=20 > > ----- End forwarded message ----- >=20 > Is this showing up, when one doesn't have the expected COMPAT_FREEBSD10 i= n kernel and > updated kernel __before___ world?: You must include COMPAT_FREEBSD10 or have a new userspace. Otherwise things like your shell are unlikely to work. -- Brooks >=20 > most recent CURRENT (FreeBSD 11.0-ALPHA4 #41 r302149: Thu Jun 23 21:58:25= CEST 2016 > amd64, custom kernel) dies when trying to >=20 > make buildworld=20 >=20 > or >=20 > make buildkernel/kernel >=20 > with the message shown below: >=20 > root@localhost: [src] make buildkernel > *** Signal 12 >=20 > Stop. > make: stopped in /usr/src > .ERROR_TARGET=3D'buildkernel' > .ERROR_META_FILE=3D'' > .MAKE.LEVEL=3D'0' > MAKEFILE=3D'' > .MAKE.MODE=3D'normal' > .CURDIR=3D'/usr/src' > .MAKE=3D'make' > .OBJDIR=3D'/usr/obj/usr/src' > .TARGETS=3D'buildkernel' > DESTDIR=3D'' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'amd64' > MACHINE_ARCH=3D'amd64' > MAKEOBJDIRPREFIX=3D'/usr/obj' > MAKESYSPATH=3D'/usr/src/share/mk' > MAKE_VERSION=3D'20160606' > PATH=3D'/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP=3D'/usr/src' > OBJTOP=3D'/usr/obj/usr/src' >=20 > Regards, >=20 > oh --hQiwHBbRI9kgIhsi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXbVbuAAoJEKzQXbSebgfAzXoH/ji1RWuD83eiMWx4Pb6rSQZw kJ0vGJNPISHz770HOFH4agyhqpK/vsUrRrNsTkFPPEVGoL7/cZn4XxSngzaJ811F DTJBsiA2S33Tn4FAaGpiR1Sl6DVnAnC/Ye4G4BqFYNXCxX2XNymmfZmXzzNT908L 6V2y6nc+Efn1bXJ4P/nY1lqfm6KuWyp5QTAOmrQUVuqpvE6ZXa0kwCP4dijARs1k OmST7v9RcfNBWS5aG+7GrUmg2vEbwuILFgkvtrdUWgMwu5BW4UrT8eUFq6yzzmpg puIkMW0oSOrby08FuD+H+RV1mPGpSxjmEWvm6+pRrzoQ2ylJl2hrat4vBeE/094= =J17T -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi-- From owner-freebsd-current@freebsd.org Fri Jun 24 16:25:58 2016 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 59627B802AC for ; Fri, 24 Jun 2016 16:25:58 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 1AFDF195D; Fri, 24 Jun 2016 16:25:57 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bGTvX-0037nF-W4>; Fri, 24 Jun 2016 18:25:56 +0200 Received: from x4e348a50.dyn.telefonica.de ([78.52.138.80] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bGTvX-0007uN-M2>; Fri, 24 Jun 2016 18:25:55 +0200 Date: Fri, 24 Jun 2016 18:25:59 +0200 From: "O. Hartmann" To: Brooks Davis Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160624182559.77b96295.ohartman@zedat.fu-berlin.de> In-Reply-To: <20160624155111.GB20770@spindle.one-eyed-alien.net> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/dJw1gBWIKmF5mrJZHRt+YQy"; protocol="application/pgp-signature" X-Originating-IP: 78.52.138.80 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 16:25:58 -0000 --Sig_/dJw1gBWIKmF5mrJZHRt+YQy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 24 Jun 2016 15:51:11 +0000 Brooks Davis schrieb: > On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: > > Am Thu, 23 Jun 2016 21:07:51 +0000 > > Brooks Davis schrieb: > > =20 > > > Kernel config minimalists and those running aarch64 and riscv systems= will > > > want to head this UPDATING message. > > >=20 > > > In practice, if you're fairly up to date, doing installworld before > > > installkernel will also work (I've tested that case from ALPHA4), but= is > > > always somewhat risky. > > >=20 > > > -- Brooks > > >=20 > > > ----- Forwarded message from Brooks Davis ----- > > >=20 > > > Date: Thu, 23 Jun 2016 21:02:05 +0000 (UTC) > > > From: Brooks Davis > > > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > > > svn-src-head@freebsd.org > > > Subject: svn commit: r302152 - head > > >=20 > > > Author: brooks > > > Date: Thu Jun 23 21:02:05 2016 > > > New Revision: 302152 > > > URL: https://svnweb.freebsd.org/changeset/base/302152 > > >=20 > > > Log: > > > Add an UPDATING entry for the pipe() -> pipe2() transition. > > > =20 > > > Approved by: re (gjb) > > > Sponsored by: DARPA, AFRL > > >=20 > > > Modified: > > > head/UPDATING > > >=20 > > > Modified: head/UPDATING > > > =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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > --- head/UPDATING Thu Jun 23 20:59:13 2016 (r302151) > > > +++ head/UPDATING Thu Jun 23 21:02:05 2016 (r302152) > > > @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11 > > > disable the most expensive debugging functionality run > > > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > > > =20 > > > +20160622: > > > + The the libc stub for the pipe(2) system call has been replaced with > > > + a wrapper which calls the pipe2(2) system call and the pipe(2) is n= ow > > > + only implemented by the kernels which include "options > > > + FREEBSD10_COMPAT" in their config file (this is the default). > > > + Users should ensure that this option is enabled in their kernel > > > + or upgrade userspace to r302092 before upgrading their kernel. > > > + > > > 20160527: > > > CAM will now strip leading spaces from SCSI disks' serial numbers. > > > This will effect users who create UFS filesystems on SCSI disks usi= ng > > >=20 > > >=20 > > > ----- End forwarded message ----- =20 > >=20 > > Is this showing up, when one doesn't have the expected COMPAT_FREEBSD10= in kernel and > > updated kernel __before___ world?: =20 >=20 > You must include COMPAT_FREEBSD10 or have a new userspace. Otherwise > things like your shell are unlikely to work. >=20 > -- Brooks How can I fix this? On two boxes, I'm like a dead man in the water now. >=20 > >=20 > > most recent CURRENT (FreeBSD 11.0-ALPHA4 #41 r302149: Thu Jun 23 21:58:= 25 CEST 2016 > > amd64, custom kernel) dies when trying to > >=20 > > make buildworld=20 > >=20 > > or > >=20 > > make buildkernel/kernel > >=20 > > with the message shown below: > >=20 > > root@localhost: [src] make buildkernel > > *** Signal 12 > >=20 > > Stop. > > make: stopped in /usr/src > > .ERROR_TARGET=3D'buildkernel' > > .ERROR_META_FILE=3D'' > > .MAKE.LEVEL=3D'0' > > MAKEFILE=3D'' > > .MAKE.MODE=3D'normal' > > .CURDIR=3D'/usr/src' > > .MAKE=3D'make' > > .OBJDIR=3D'/usr/obj/usr/src' > > .TARGETS=3D'buildkernel' > > DESTDIR=3D'' > > LD_LIBRARY_PATH=3D'' > > MACHINE=3D'amd64' > > MACHINE_ARCH=3D'amd64' > > MAKEOBJDIRPREFIX=3D'/usr/obj' > > MAKESYSPATH=3D'/usr/src/share/mk' > > MAKE_VERSION=3D'20160606' > > PATH=3D'/sbin:/bin:/usr/sbin:/usr/bin' > > SRCTOP=3D'/usr/src' > > OBJTOP=3D'/usr/obj/usr/src' > >=20 > > Regards, > >=20 > > oh =20 >=20 >=20 --Sig_/dJw1gBWIKmF5mrJZHRt+YQy Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXbV8XAAoJEOgBcD7A/5N8gFIH/0Dbu/JF6pHM6AZArNO8QQbE V0kEeZXWsacxOa68a9huaAVPuf1cFjBaCFmnlgqKAWch73qIPi+BmVqgizGCa9B1 XGl5uZB4/ClIeRp4VbVQxHwYfKB4vLUUq6crA/O5hbG/WPDIWihKV65l4Ea4/BVx HKIG6xeIOgT96Wv9ZnuyTG52DxEK53MkuDZU7N2kbVjFGkHXv3znfu2hkPCAYQ5v aAi3QahVXmW6tS4VxDm8jI5G/CtR28YkKvvTmTwMJwMXYaISYt/3MWK21qWwmjaH 18TWatZCdnNnzv7JSiHfaIFIYiQQlxriYms/2L/rlVocABPGFJuCvd9VxMpFsi0= =fxxg -----END PGP SIGNATURE----- --Sig_/dJw1gBWIKmF5mrJZHRt+YQy-- From owner-freebsd-current@freebsd.org Fri Jun 24 17:35:47 2016 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 B41F3B73273 for ; Fri, 24 Jun 2016 17:35:47 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9178C1EA1; Fri, 24 Jun 2016 17:35:47 +0000 (UTC) (envelope-from null@pozo.com) Received: from octo.pozo.com (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id u5OHUHjC034058; Fri, 24 Jun 2016 10:30:17 -0700 (PDT) (envelope-from null@pozo.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: HEADS UP: caution required with updates using custom kernels From: Manfred Antar In-Reply-To: <20160624182559.77b96295.ohartman@zedat.fu-berlin.de> Date: Fri, 24 Jun 2016 10:30:17 -0700 Cc: Brooks Davis , freebsd-current@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> <20160624182559.77b96295.ohartman@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3124) X-Spam-Status: No, score=-102.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED, USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: u5OHUHjC034058 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 17:35:47 -0000 I put a GENERIC kernel plus modules for amd64 at: http://www.pozo.com/kernel/kernel.tar.bz2 From owner-freebsd-current@freebsd.org Fri Jun 24 18:57:46 2016 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 EF241AC4202 for ; Fri, 24 Jun 2016 18:57:46 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C90312627 for ; Fri, 24 Jun 2016 18:57:46 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net (torb.pix.net [192.168.16.32]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id u5OIvjI2081073; Fri, 24 Jun 2016 14:57:45 -0400 (EDT) (envelope-from lidl@pix.net) To: freebsd-current@freebsd.org References: <20160624182559.77b96295.ohartman@zedat.fu-berlin.de> Subject: Re: HEADS UP: caution required with updates using custom kernels From: Kurt Lidl Message-ID: <7d2b3b80-d6a4-555a-bb0a-4051b62f5506@pix.net> Date: Fri, 24 Jun 2016 14:57:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160624182559.77b96295.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 18:57:47 -0000 > Am Fri, 24 Jun 2016 15:51:11 +0000 > Brooks Davis schrieb: > >> On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: >> > Am Thu, 23 Jun 2016 21:07:51 +0000 >> > Brooks Davis schrieb: >> > >> > > Kernel config minimalists and those running aarch64 and riscv systems will >> > > want to head this UPDATING message. >> > > >> > > In practice, if you're fairly up to date, doing installworld before >> > > installkernel will also work (I've tested that case from ALPHA4), but is >> > > always somewhat risky. >> > > >> > > -- Brooks >> > > >> > > ----- Forwarded message from Brooks Davis ----- >> > > >> > > Date: Thu, 23 Jun 2016 21:02:05 +0000 (UTC) >> > > From: Brooks Davis >> > > To: src-committers at freebsd.org, svn-src-all at freebsd.org, >> > > svn-src-head at freebsd.org >> > > Subject: svn commit: r302152 - head >> > > >> > > Author: brooks >> > > Date: Thu Jun 23 21:02:05 2016 >> > > New Revision: 302152 >> > > URL: https://svnweb.freebsd.org/changeset/base/302152 >> > > >> > > Log: >> > > Add an UPDATING entry for the pipe() -> pipe2() transition. >> > > >> > > Approved by: re (gjb) >> > > Sponsored by: DARPA, AFRL >> > > >> > > Modified: >> > > head/UPDATING >> > > >> > > Modified: head/UPDATING >> > > ============================================================================== >> > > --- head/UPDATING Thu Jun 23 20:59:13 2016 (r302151) >> > > +++ head/UPDATING Thu Jun 23 21:02:05 2016 (r302152) >> > > @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11 >> > > disable the most expensive debugging functionality run >> > > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) >> > > >> > > +20160622: >> > > + The the libc stub for the pipe(2) system call has been replaced with >> > > + a wrapper which calls the pipe2(2) system call and the pipe(2) is now >> > > + only implemented by the kernels which include "options >> > > + FREEBSD10_COMPAT" in their config file (this is the default). >> > > + Users should ensure that this option is enabled in their kernel >> > > + or upgrade userspace to r302092 before upgrading their kernel. >> > > + >> > > 20160527: >> > > CAM will now strip leading spaces from SCSI disks' serial numbers. >> > > This will effect users who create UFS filesystems on SCSI disks using >> > > >> > > >> > > ----- End forwarded message ----- >> > >> > Is this showing up, when one doesn't have the expected COMPAT_FREEBSD10 in kernel and >> > updated kernel __before___ world?: >> >> You must include COMPAT_FREEBSD10 or have a new userspace. Otherwise >> things like your shell are unlikely to work. >> >> -- Brooks > > > How can I fix this? > > On two boxes, I'm like a dead man in the water now. Having just worked out how to recover from this on a mips64 host (edgerouter lite), here's more or less what I did (minus all the experimentation to get to a working solution). What follows worked for me - but no warranty is implied or given. My machine with the new kernel, but old user binaries, failed to reboot properly, and was left at a single user prompt: start_init: trying /sbin/init pid 23 (sh), uid 0: exited on signal 12 Jun 24 18:17:54 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: I hit return, and got a shell, albeit one that cannot call pipe(). If you cannot get to a single-user shell on the console, I don't have any recommendations for recovering your system. You will need to be able to get access to the /usr/src and /usr/obj filesystems that you compiled from. In my case, those filesystems are NFS mounted, so I had to get some networking going, and then mount those filesystems. Commands I typed are after the $ prompts: $ ifconfig octe0 192.168.16.138/24 $ ifconfig octe0 On the ERL, the Ethernet autoconfig is a bit unstable, until you tickle the interface with the second 'ifconfig', the interface stays down. You probably don't need to do the second ifconfig $ mount -u / $ mount /boot $ mount /tmp Start some daemons needed for NFS. $ rpcbind $ rpc.lockd $ rpc.statd Mount the remote filesystems. $ mount /usr/src $ mount /usr/obj At this point, I have access to the new user binaries, but 'make' does not work (it calls pipe() a lot), so let's get it working: First, fixup /sbin/init for the next reboot. Note the rename into /sbin/init.bak, which is one of the backup names for init that the kernel knows about. $ chflags noschg /sbin/init $ cd /usr/obj/usr/src/sbin/init $ mv /sbin/init /sbin/init.bak $ cp -p init /sbin/init Next, get the new /bin/sh installed. $ cp -p /bin/sh /bin/sh.old $ cd /usr/obj/usr/src/bin/sh $ cp -p sh /bin/sh.new $ mv /bin/sh.new /bin/sh The tricky part: atomically replace the libc.so shared library. $ chflags noschg /lib/libc.so.7 $ cp -p /lib/libc.so.7 /lib/libc.so.7.old $ cd /usr/obj/usr/src/lib/libc $ cp -p libc.so.7 /lib/libc.so.7.new $ mv /lib/libc.so.7.new /lib/libc.so.7 If you system is still responding now, you're probably going to make it! Fixup make next: $ cd /usr/obj/usr/src/usr.bin/bmake $ mv /usr/bin/make /usr/bin/make.old $ cp -p make /usr/bin/make At this point, 'make' should function again, so you can just do stuff like: $ cd /usr/src/lib && make install $ cd /usr/src/bin && make install $ cd /usr/src/sbin && make install $ cd /usr/src/usr.bin && make install $ cd /usr/src/usr.sbin && make install If you reboot after this, you should have a mostly working system. Doing a full 'make installworld' would probably be a good idea. -Kurt From owner-freebsd-current@freebsd.org Fri Jun 24 21:50:17 2016 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 5E7E6B74FD5; Fri, 24 Jun 2016 21:50:17 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003: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 2B6CB29A4; Fri, 24 Jun 2016 21:50:17 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x22b.google.com with SMTP id u201so132794375oie.0; Fri, 24 Jun 2016 14:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R+Db2jnteBDchBtPpumnS4RxaLoIddNRKhfR8AxOIUQ=; b=XKfgpz/fHdepqGVvxaEDakHI/tJtnMxN0ICzj/vlMi6cBLPDO3AI2LbaCL7B+hYa8K CYYOSfEMgbqmBcr1pm8pYonx0Ci/41QTic0LaIl2XsT1AKohnu2GekumkjOTzBIwY/5q qVpMjwNCT0HgfhnuVE2J1RrFhVJirJsk9w9uCvM8Rj7V+j9kPTiDVcvvxoHhLtdmuQ6Z X4SnvPtVO2/kKCL8CR4z6jNNpLVrNqq2PeQFo2+32Efr+hPoikY4EROnHzZCVc0Ptoff wlgFvXk4YMGXg9yRp6TJxNSQLjNKyWgEKnng0iq4s0IO4dhpZ6gqVTWExJZNHvVybRWS roCA== 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:from :date:message-id:subject:to:cc; bh=R+Db2jnteBDchBtPpumnS4RxaLoIddNRKhfR8AxOIUQ=; b=h8lcXRB2myo6xkUoZSlXw6RUhsh1j+GXdFQXc9Q9l+uf2F20nFHC89yJvyMiSYTEU9 ToX8eEG8NIT2o7+tEMGw3C379nNeXUcEpu0vkTKXD3b/Hfa/v9zOaiYPz0HjTDGgCjmj SxbhSCqroQM3KpbgOldx+vdzy1BkGIXZzU9ASzF4u3UcfOrzSdKvePMaCIvRo15+8uz3 AR6GZGbK++pXkvzTwl2ni/pQoSMNCEsthUrc2M0OpiG7fbjDsqQLxfZKD47xRL7Hmogq edJpkvIdyA7j4M9TgjFU6ZbLgrU02mAq8kNX7YSvuakwIpGNxczjLKbNVPwm3tkjywcn ER9w== X-Gm-Message-State: ALyK8tJGyZQzIx1AArBDV6ZG0ucRcJxV7JRs6xI2EEAxs4AS+luAsZ9q6vG+4ndDREoa6IGuRmzvfCBCRNiy9w== X-Received: by 10.157.29.106 with SMTP id m97mr4365447otm.164.1466805016220; Fri, 24 Jun 2016 14:50:16 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.168.149 with HTTP; Fri, 24 Jun 2016 14:50:15 -0700 (PDT) In-Reply-To: <1465862808.1188.129.camel@freebsd.org> References: <1465862808.1188.129.camel@freebsd.org> From: Alan Somers Date: Fri, 24 Jun 2016 15:50:15 -0600 X-Google-Sender-Auth: WrAnhoFxie9sUqBc5jnL9f8p0uA Message-ID: Subject: Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists To: Ian Lepore Cc: "Conrad E. Meyer" , Mark Millard , freebsd-arm , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 21:50:17 -0000 >> > On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard > > > wrote: >> > > With the newly less strict alignment requirements "kyua test -k >> > > /usr/tests/Kyuafile" runs to completion, unlike before. >> > > >> > > > ===> Summary >> > > > Results read from /root/.kyua/store/results.usr_tests.20160613 >> > > > -080302-120731.db >> > > > Test cases: 5694 total, 54 skipped, 21 expected failures, 24 >> > > > broken, 59 failed >> > > > Total time: 8723.243s >> > > >> > > >> > > I only list the one line summaries below. Then I list various >> > > context details. >> > > >> > > > ===> Broken tests >> > > > lib/msun/cexp_test:main -> broken: Received signal 6 >> > > > [1.054s] >> > > > lib/msun/ctrig_test:main -> broken: Received signal 6 >> > > > [1.074s] >> > > > lib/msun/exponential_test:main -> broken: Received signal 6 >> > > > [1.045s] >> > > > lib/msun/fenv_test:main -> broken: Received signal 6 >> > > > [1.048s] >> > > > lib/msun/fma_test:main -> broken: Received signal 6 [1.080s] >> > > > lib/msun/invctrig_test:main -> broken: Received signal 6 >> > > > [1.091s] >> > > > lib/msun/invtrig_test:main -> broken: Received signal 6 >> > > > [1.086s] >> > > > lib/msun/logarithm_test:main -> broken: Received signal 6 >> > > > [1.054s] >> > > > lib/msun/lrint_test:main -> broken: Received signal 6 >> > > > [1.069s] >> > > > lib/msun/nearbyint_test:main -> broken: Received signal 6 >> > > > [1.066s] >> > > > lib/msun/rem_test:main -> broken: Received signal 6 [1.069s] >> > > > lib/msun/trig_test:main -> broken: Received signal 6 >> > > > [1.070s] >> > > > sbin/growfs/legacy_test:main -> broken: Reported plan differs >> > > > from actual executed tests [0.459s] >> > > > sys/geom/class/eli/integrity_copy_test:main -> broken: Test >> > > > case timed out [1200.082s] >> > > > sys/geom/class/eli/integrity_hmac_test:main -> broken: Test >> > > > case timed out [600.138s] >> > > > sys/geom/class/eli/onetime_a_test:main -> broken: Test case >> > > > timed out [600.044s] >> > > > sys/sys/bitstring_test:bit_clear -> broken: Test case body >> > > > timed out [300.032s] >> > > > sys/sys/bitstring_test:bit_count -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.080s] >> > > > sys/sys/bitstring_test:bit_ffc -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.077s] >> > > > sys/sys/bitstring_test:bit_ffc_at -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.081s] >> > > > sys/sys/bitstring_test:bit_ffs -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.082s] >> > > > sys/sys/bitstring_test:bit_ffs_at -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.077s] >> > > > sys/sys/bitstring_test:bit_nclear -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.083s] >> > > > sys/sys/bitstring_test:bit_nset -> broken: Premature exit; >> > > > test case received signal 11 (core dumped) [1.079s] >> > > >> > > >> > > > ===> Failed tests >> > > > lib/libc/c063/fstatat_test:fstatat_fd -> failed: >> > > > /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: >> > > > memcmp(&st1, &st2, sizeof(st1)) == 0 not met [0. >> > > > 027s] >> > > > lib/libc/nss/gethostby_test:getipnodebyname_getaddrinfo_ipv4 >> > > > -> failed: /usr/src/lib/libc/tests/nss/gethostby_test.c:1335: >> > > > run_tests(_hostlist_file, _snapshot >> > > > _file, 2, TEST_GETHOSTBYNAME2_GETADDRINFO, 0) == 0 not met >> > > > [15.315s] >> > > > lib/libc/ssp/ssp_test:fgets -> failed: Test case body >> > > > returned a non-ok exit code, but this is not allowed [0.153s] >> > > > lib/libc/ssp/ssp_test:gets -> failed: Test case body returned >> > > > a non-ok exit code, but this is not allowed [0.158s] >> > > > lib/libc/ssp/ssp_test:memcpy -> failed: atf-check failed; see >> > > > the output of the test for details [0.148s] >> > > > lib/libc/ssp/ssp_test:memmove -> failed: atf-check failed; >> > > > see the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:memset -> failed: atf-check failed; see >> > > > the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:read -> failed: Test case body returned >> > > > a non-ok exit code, but this is not allowed [0.154s] >> > > > lib/libc/ssp/ssp_test:readlink -> failed: atf-check failed; >> > > > see the output of the test for details [0.155s] >> > > > lib/libc/ssp/ssp_test:snprintf -> failed: atf-check failed; >> > > > see the output of the test for details [0.149s] >> > > > lib/libc/ssp/ssp_test:sprintf -> failed: atf-check failed; >> > > > see the output of the test for details [0.149s] >> > > > lib/libc/ssp/ssp_test:stpcpy -> failed: atf-check failed; see >> > > > the output of the test for details [0.149s] >> > > > lib/libc/ssp/ssp_test:stpncpy -> failed: atf-check failed; >> > > > see the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:strcat -> failed: atf-check failed; see >> > > > the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:strcpy -> failed: atf-check failed; see >> > > > the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:strncat -> failed: atf-check failed; >> > > > see the output of the test for details [0.147s] >> > > > lib/libc/ssp/ssp_test:strncpy -> failed: atf-check failed; >> > > > see the output of the test for details [0.146s] >> > > > lib/libc/ssp/ssp_test:vsnprintf -> failed: atf-check failed; >> > > > see the output of the test for details [0.150s] >> > > > lib/libc/ssp/ssp_test:vsprintf -> failed: atf-check failed; >> > > > see the output of the test for details [0.148s] >> > > > lib/libc/stdio/printbasic_test:int_within_limits -> failed: >> > > > printf("%tu", (size_t)-1) ==> [18446744073709551615], expected >> > > > [4294967295]<> [0.030s] >> > > > lib/libc/stdio/scanfloat_test:infinities_and_nans -> failed: >> > > > /usr/src/lib/libc/tests/stdio/scanfloat_test.c:191: >> > > > fetestexcept(FE_INVALID) == 0 not met [0.031 >> > > > s] >> > > > lib/libc/sys/mincore_test:mincore_resid -> failed: >> > > > /usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:225: >> > > > check_residency(addr, npgs) == 0 not met [0.04 >> > > > 0s] >> > > > lib/libc/sys/mincore_test:mincore_shmseg -> failed: >> > > > /usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:298: >> > > > check_residency(addr, npgs) == 0 not met [0.0 >> > > > 29s] >> > > > lib/libc/tls/tls_dynamic_test:t_tls_dynamic -> failed: 15 >> > > > checks failed; see output for more details [0.035s] >> > > > lib/libproc/proc_test:symbol_lookup -> failed: >> > > > /usr/src/lib/libproc/tests/proc_test.c:116: state != PS_STOP: >> > > > process has state 4 [0.177s] >> > > > lib/libxo/functional_test:test_02__E -> failed: atf-check >> > > > failed; see the output of the test for details [0.166s] >> > > > lib/libxo/functional_test:test_02__H -> failed: atf-check >> > > > failed; see the output of the test for details [0.168s] >> > > > lib/libxo/functional_test:test_02__HIPx -> failed: atf-check >> > > > failed; see the output of the test for details [0.170s] >> > > > lib/libxo/functional_test:test_02__HP -> failed: atf-check >> > > > failed; see the output of the test for details [0.164s] >> > > > lib/libxo/functional_test:test_02__J -> failed: atf-check >> > > > failed; see the output of the test for details [0.169s] >> > > > lib/libxo/functional_test:test_02__JP -> failed: atf-check >> > > > failed; see the output of the test for details [0.166s] >> > > > lib/libxo/functional_test:test_02__T -> failed: atf-check >> > > > failed; see the output of the test for details [0.168s] >> > > > lib/libxo/functional_test:test_02__X -> failed: atf-check >> > > > failed; see the output of the test for details [0.169s] >> > > > lib/libxo/functional_test:test_02__XP -> failed: atf-check >> > > > failed; see the output of the test for details [0.168s] >> > > > lib/msun/conj_test:main -> failed: 9 tests of 42 failed >> > > > [0.034s] >> > > > lib/msun/ldexp_test:ldexp_denormal -> failed: 4 checks >> > > > failed; see output for more details [0.034s] >> > > > local/kyua/model/metadata_test:override_all_with_set_string -> >> > > > failed: Line 253: disk_space != md.required_disk_space() >> > > > (16777216.00T != 2.00G) [0.047s] >> > > > local/kyua/testers/stacktrace_test:dump__cannot_find_gdb -> >> > > > failed: testers/stacktrace_test.c:281: >> > > > atf_utils_grep_file("execvp failed", "stacktrace") not met >> > > > [0.611s] >> > > > local/kyua/testers/stacktrace_test:dump__gdb_fail -> failed: >> > > > testers/stacktrace_test.c:294: atf_utils_grep_file("foo", >> > > > "stacktrace") not met [0.610s] >> > > > local/kyua/testers/stacktrace_test:dump__gdb_times_out -> >> > > > failed: testers/stacktrace_test.c:311: >> > > > atf_utils_grep_file("foo", "stacktrace") not met [0.614s] >> > > > local/kyua/testers/stacktrace_test:dump__integration -> >> > > > failed: testers/stacktrace_test.c:233: >> > > > atf_utils_grep_file("#0", "stacktrace") not met [0.613s] >> > > > local/kyua/testers/stacktrace_test:dump__ok -> failed: >> > > > testers/stacktrace_test.c:249: atf_utils_grep_file("frame 1", >> > > > "stacktrace") not met [0.614s] >> > > > local/kyua/testers/stacktrace_test:find_core__found__long -> >> > > > failed: Core dumped, but no candidates found [0.606s] >> > > > local/kyua/testers/stacktrace_test:find_core__found__short -> >> > > > failed: Core dumped, but no candidates found [0.603s] >> > > > local/kyua/testers/tap_parser_test:try_parse_plan__insane -> >> > > > failed: testers/tap_parser_test.c:135: 'too long' not matched >> > > > in 'Plan line includes out of range >> > > > numbers' [0.032s] >> > > > sys/geom/class/eli/resize_test:main -> failed: 15 tests of 27 >> > > > failed [1.292s] >> > > > sys/kern/pipe/pipe_fstat_bug_test:main -> failed: Returned >> > > > non-success exit status 1 [0.044s] >> > > > usr.bin/lastcomm/legacy_test:main -> failed: 4 tests of 6 >> > > > failed [0.151s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_bindip -> failed: 1 >> > > > checks failed; see output for more details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_bindip_rev -> >> > > > failed: 1 checks failed; see output for more details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_localhost_only -> >> > > > failed: 1 checks failed; see output for more details [0.034s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_one_addr_on_each_subn >> > > > et -> failed: 1 checks failed; see output for more details >> > > > [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_one_addr_on_each_subn >> > > > et_rev -> failed: 1 checks failed; see output for more >> > > > details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_point2point -> >> > > > failed: 1 checks failed; see output for more details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_point2point_rev -> >> > > > failed: 1 checks failed; see output for more details [0.033s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_recvdstaddr -> >> > > > failed: 1 checks failed; see output for more details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_recvdstaddr_rev -> >> > > > failed: 1 checks failed; see output for more details [0.035s] >> > > > usr.sbin/rpcbind/addrmerge_test:addrmerge_singlehomed -> >> > > > failed: 1 checks failed; see output for more details [0.032s] >> > > > usr.sbin/sa/legacy_test:main -> failed: 12 tests of 13 failed >> > > > [0.340s] >> > > >> > > >> > > As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring tests should all be fixed. I opened PR 210329 for the usr.bin/lastcomm test. I haven't investigated the others. -Alan From owner-freebsd-current@freebsd.org Fri Jun 24 22:03:16 2016 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 DAA9CB8035A for ; Fri, 24 Jun 2016 22:03:16 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 6700A1290 for ; Fri, 24 Jun 2016 22:03:16 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id c82so8472276wme.3 for ; Fri, 24 Jun 2016 15:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=2b/pY3RAeRzRujlQ14aUdKDuUZxvZtl7pJ9fXduUeM0=; b=AdiLvp4MtVdCRTOT5pJNp9FmUftRaYJsnx4NlIbraRtJw8Luq2JOJDFayDSZg1238/ AStoNZyXO5dskw1FBrMlgnk2UhfH1jER1eHQkFPMm6h/jelhU6MwEVMpNc9HmWSqgJRY mo7C9dLiyguLQv9c1OvJ+m0ivT/tudRrML06xR7hNLGzgX1gWmUE4+vVxhugLUIAOGcs fgirSbzwjBMTEmn6hC0Fw1RtFaR1h/Evqz5xEgJl4xFEVuyfFQsxxFjWaPfoHHSyNYmD KdoFTNG3WgGh3aaca4hUDv+CIvBzuNr88K3BLVznqT/YXQxJgLJD2Hj+/7PPJV0GX2eC DKNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=2b/pY3RAeRzRujlQ14aUdKDuUZxvZtl7pJ9fXduUeM0=; b=anzDcAw7REVq7kxsZRv5AkU3JLjHXspwTBSa5Qx0O2JsyLMCSVlxR7mEMQ28zam95N wu/gxhb3F0s0hXK6WaP6SigBuko11YL682XhssVqKZBkS9mCWefGL1W+0iqgDuDRdYTf u5DluTqG3J9B/KwM2sT5SfD5h/BbL8fqIpMvGVSkekonfcg0m/8qbvrZe+hc1LJxenhD asvO/JhvgJJi7TPbWO93SP/STCAemR50cBfPTR74MkMyYfEK8W7OR/fVsJOdQQgXjB9C uDAMFEmclV5p1MY0YwvWs+PHew6VSKwgct7J3aFizOl9lzYf7RZRD2d94qtyAp/ST75g dgZQ== X-Gm-Message-State: ALyK8tIADH4fkeguPV0KCI3CUkmrkbjUTjp7+CLOFCKPquVNxIcUgqpTNQMnJmCKvDWAvI24ICBeGBSYDmyPHA== X-Received: by 10.28.50.131 with SMTP id y125mr269219wmy.94.1466805794569; Fri, 24 Jun 2016 15:03:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.9.142 with HTTP; Fri, 24 Jun 2016 15:03:13 -0700 (PDT) From: Guy Yur Date: Sat, 25 Jun 2016 01:03:13 +0300 Message-ID: Subject: Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4 To: Konstantin Belousov Cc: Daniel Engberg , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 22:03:17 -0000 Hi, I got the same crash on a VirtualBox VM with r302170 and samba43-4.3.9, tdb-1.3.9,1. Based on the smbd log, when I was on r301989 smbd didn't crash. smbd started crashing when I installed r302170 today. gdb 6.1.1 and 7.11.1 don't see the shared libraries for some reason so I don't get the symbols when opening the core file. lldb works fine. smbclient, smbd, nmbd all panic at the same location: tdb_runtime_check_for_robust_mutexes when calling _pthread_mutex_destroy. When running 'lldb /usr/local/bin/smbclient //HOST/Share', If I point a breakpoint at mutex_assert_not_owned and 'cont' each time, there is no crash (m_qe pointers are both null). Putting a breakpoint at mutex.c:957 and then breaking at mutex_assert_not_owned, I see m_qe.tqe_prev is not null. It points to a null pointer. Core file '/var/tmp/smbclient.50434.core' (x86_64) was loaded. (lldb) bt * thread #1: tid = 100179, 0x00000008047bfcda libc.so.7`thr_kill + 10, name = 'smbclient', stop reason = signal SIGABRT * frame #0: 0x00000008047bfcda libc.so.7`thr_kill + 10 frame #1: 0x00000008047bfcab libc.so.7`__raise(s=6) + 59 at raise.c:52 [opt] frame #2: 0x00000008047bfc19 libc.so.7`abort + 73 at abort.c:65 [opt] frame #3: 0x0000000801481d7a libthr.so.3`_thread_exitf(fname=, lineno=, fmt=) + 138 at thr_exit.c:190 [opt] frame #4: 0x000000080147bcf9 libthr.so.3`mutex_assert_not_owned(curthread=, m=) + 121 at thr_mutex.c:152 [opt] frame #5: 0x000000080147bc27 libthr.so.3`_pthread_mutex_destroy(mutex=0x00000008012e9000) + 87 at thr_mutex.c:474 [opt] frame #6: 0x0000000809abdce3 libtdb.so.1`tdb_runtime_check_for_robust_mutexes + 1475 at mutex.c:957 ... (lldb) f 6 frame #6: 0x0000000809abdce3 libtdb.so.1`tdb_runtime_check_for_robust_mutexes + 1475 at mutex.c:957 954 } 955 } 956 if (m != NULL) { -> 957 pthread_mutex_destroy(m); 958 } 959 if (cleanup_ma) { 960 pthread_mutexattr_destroy(&ma); lldb for smbclient with breakpoint: * thread #1: tid = 100104, 0x000000080147bc8b libthr.so.3`mutex_assert_not_owned(curthread=0x0000000810816000, m=0x0000000801352000) + 11 at thr_mutex.c:150, stop reason = breakpoint 2.1 frame #0: 0x000000080147bc8b libthr.so.3`mutex_assert_not_owned(curthread=0x0000000810816000, m=0x0000000801352000) + 11 at thr_mutex.c:150 [opt] 147 { 148 149 #if defined(_PTHREADS_INVARIANTS) -> 150 if (__predict_false(m->m_qe.tqe_prev != NULL || 151 m->m_qe.tqe_next != NULL)) 152 PANIC("mutex %p own %#x is on list %p %p", 153 m, m->m_lock.m_owner, m->m_qe.tqe_prev, m->m_qe.tqe_next); (lldb) p *m (pthread_mutex) $3 = { m_lock = { m_owner = 100180 m_flags = 17 m_ceilings = ([0] = 0, [1] = 0) m_rb_lnk = 0 m_spare = ([0] = 0, [1] = 0) } m_flags = 1 m_count = 0 m_spinloops = 0 m_yieldloops = 0 m_ps = 2 m_qe = { tqe_next = 0x0000000000000000 tqe_prev = 0x00000008108161a0 } m_pqe = { tqe_next = 0x0000000000000000 tqe_prev = 0x0000000000000000 } m_rb_prev = 0x0000000000000000 } (lldb) p *m->m_qe.tqe_prev (pthread_mutex *) $5 = 0x0000000000000000 Regards, Guy From owner-freebsd-current@freebsd.org Fri Jun 24 22:23:42 2016 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 400F5B8090B for ; Fri, 24 Jun 2016 22:23:42 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 F0C071EF6 for ; Fri, 24 Jun 2016 22:23:41 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u5OMOE5G000605 for ; Fri, 24 Jun 2016 15:24:21 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <20160624155111.GB20770@spindle.one-eyed-alien.net> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de>, <20160624155111.GB20770@spindle.one-eyed-alien.net> From: "Chris H" Subject: Re: HEADS UP: caution required with updates using custom kernels Date: Fri, 24 Jun 2016 15:24:21 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <330789230754140e38fb527973e23405@ultimatedns.net> Content-Transfer-Encoding: 8bit X-Milter: Spamilter (Reciever: udns.ultimatedns.net; Sender-ip: 127.0.0.1; Sender-helo: ultimatedns.net; ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 22:23:42 -0000 On Fri, 24 Jun 2016 15:51:11 +0000 Brooks Davis wrote > On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: > > Am Thu, 23 Jun 2016 21:07:51 +0000 > > Brooks Davis schrieb: > > > > > Kernel config minimalists and those running aarch64 and riscv systems > > > will want to head this UPDATING message. > > > > > > In practice, if you're fairly up to date, doing installworld before > > > installkernel will also work (I've tested that case from ALPHA4), but is > > > always somewhat risky. > > > > > > -- Brooks > > > > > > ----- Forwarded message from Brooks Davis ----- > > > > > > Date: Thu, 23 Jun 2016 21:02:05 +0000 (UTC) > > > From: Brooks Davis > > > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > > > svn-src-head@freebsd.org > > > Subject: svn commit: r302152 - head > > > > > > Author: brooks > > > Date: Thu Jun 23 21:02:05 2016 > > > New Revision: 302152 > > > URL: https://svnweb.freebsd.org/changeset/base/302152 > > > > > > Log: > > > Add an UPDATING entry for the pipe() -> pipe2() transition. > > > > > > Approved by: re (gjb) > > > Sponsored by: DARPA, AFRL > > > > > > Modified: > > > head/UPDATING > > > > > > Modified: head/UPDATING > > > > > > ============================================================================= > > > = --- head/UPDATING Thu Jun 23 20:59:13 2016 (r302151) > > > +++ head/UPDATING Thu Jun 23 21:02:05 2016 (r302152) > > > @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11 > > > disable the most expensive debugging functionality run > > > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > > > > > > +20160622: > > > + The the libc stub for the pipe(2) system call has been replaced with > > > + a wrapper which calls the pipe2(2) system call and the pipe(2) is > > > now + only implemented by the kernels which include "options > > > + FREEBSD10_COMPAT" in their config file (this is the default). > > > + Users should ensure that this option is enabled in their kernel > > > + or upgrade userspace to r302092 before upgrading their kernel. > > > + > > > 20160527: > > > CAM will now strip leading spaces from SCSI disks' serial numbers. > > > This will effect users who create UFS filesystems on SCSI disks > > > using > > > > > > > > ----- End forwarded message ----- > > > > Is this showing up, when one doesn't have the expected COMPAT_FREEBSD10 in > > kernel and updated kernel __before___ world?: > > You must include COMPAT_FREEBSD10 or have a new userspace. Otherwise > things like your shell are unlikely to work. > > -- Brooks > Hi. I don't see any indication of why this change was required (the obsolescence of pipe(2)) Can you elaborate a little, please? Thanks. --Chris From owner-freebsd-current@freebsd.org Fri Jun 24 22:50:41 2016 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 DF2C8B80D8C for ; Fri, 24 Jun 2016 22:50:41 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 BE0472B7F for ; Fri, 24 Jun 2016 22:50:41 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 5895E5A9F2A; Fri, 24 Jun 2016 22:50:34 +0000 (UTC) Date: Fri, 24 Jun 2016 22:50:34 +0000 From: Brooks Davis To: Chris H Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160624225034.GC20770@spindle.one-eyed-alien.net> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> <330789230754140e38fb527973e23405@ultimatedns.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5QAgd0e35j3NYeGe" Content-Disposition: inline In-Reply-To: <330789230754140e38fb527973e23405@ultimatedns.net> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 22:50:42 -0000 --5QAgd0e35j3NYeGe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 24, 2016 at 03:24:21PM -0700, Chris H wrote: > On Fri, 24 Jun 2016 15:51:11 +0000 Brooks Davis wrote >=20 > > On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: > > > Am Thu, 23 Jun 2016 21:07:51 +0000 > > > Brooks Davis schrieb: > > >=20 > > > > Kernel config minimalists and those running aarch64 and riscv syste= ms > > > > will want to head this UPDATING message. > > > >=20 > > > > In practice, if you're fairly up to date, doing installworld before > > > > installkernel will also work (I've tested that case from ALPHA4), b= ut is > > > > always somewhat risky. > > > >=20 > > > > -- Brooks > > > >=20 > > > > ----- Forwarded message from Brooks Davis ----- > > > >=20 > > > > Date: Thu, 23 Jun 2016 21:02:05 +0000 (UTC) > > > > From: Brooks Davis > > > > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > > > > svn-src-head@freebsd.org > > > > Subject: svn commit: r302152 - head > > > >=20 > > > > Author: brooks > > > > Date: Thu Jun 23 21:02:05 2016 > > > > New Revision: 302152 > > > > URL: https://svnweb.freebsd.org/changeset/base/302152 > > > >=20 > > > > Log: > > > > Add an UPDATING entry for the pipe() -> pipe2() transition. > > > > =20 > > > > Approved by: re (gjb) > > > > Sponsored by: DARPA, AFRL > > > >=20 > > > > Modified: > > > > head/UPDATING > > > >=20 > > > > Modified: head/UPDATING > > > > > > > > > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > > =3D --- head/UPDATING Thu Jun 23 20:59:13 2016 (r302151) > > > > +++ head/UPDATING Thu Jun 23 21:02:05 2016 (r302152) > > > > @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11 > > > > disable the most expensive debugging functionality run > > > > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > > > > =20 > > > > +20160622: > > > > + The the libc stub for the pipe(2) system call has been replace= d with > > > > + a wrapper which calls the pipe2(2) system call and the pipe(2)= is > > > > now + only implemented by the kernels which include "options > > > > + FREEBSD10_COMPAT" in their config file (this is the default). > > > > + Users should ensure that this option is enabled in their kernel > > > > + or upgrade userspace to r302092 before upgrading their kernel. > > > > + > > > > 20160527: > > > > CAM will now strip leading spaces from SCSI disks' serial numb= ers. > > > > This will effect users who create UFS filesystems on SCSI disks > > > > using > >=20 > > > >=20 > > > > ----- End forwarded message ----- > > >=20 > > > Is this showing up, when one doesn't have the expected COMPAT_FREEBSD= 10 in > > > kernel and updated kernel __before___ world?: > >=20 > > You must include COMPAT_FREEBSD10 or have a new userspace. Otherwise > > things like your shell are unlikely to work. > >=20 > Hi. I don't see any indication of why this change was required > (the obsolescence of pipe(2)) > Can you elaborate a little, please? pipe(2) had an unnecessarily odd calling convention (ignoring the argument the user thought they were passing and returning the two file descriptors via the two return registers). This required machine dependent assembly for every target and special handling in tracing tools (ktrace, dtrace, etc). On 64-bit platforms, pipe(2)'s implementation is the only reason the two-register return model needs to exist at all (on 32-bit platforms it allows off_t to be returned from lseek). I'll own that my timing on this was terrible. In an ideal world the user space change would have gone in months ago with the COMPAT10 change now. Unfortunately I only realized this was something that made sense while at BSDCan. Strictly speaking, this change isn't required, but making it making it now allows aarch64 and riscv to be free of this dubious calling convention and tidying up libc a bit. Opportunities to remove cruft at the scale of syscall interfaces are rare so I've been pushing to clean up aarch64 and riscv while we have a chance. -- Brooks --5QAgd0e35j3NYeGe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXbbk5AAoJEKzQXbSebgfA52YH/2Jpr8OD5TiT1K7G4fYypL3g YjsO4XqkcTXp/5JArTMvjdEB0xpVjtVNwZSpjCUApxYdTBOkfKOvr1Ihx63BX+xM BB2hr0umGKFnvgpcBTqG5zYlmOpoAF+Ikk/JBOudl1Uz/NrTMP0uvYrBLRDQ+Er7 rgUlsqWp3zBNsDTc52hTGpS/3VwlyAPXNw/IaFOYk9x8uosKdttYhtftRTiJifCq nYBUsg0vr7X/UQxIGZQivxhC1u9Jd9G3rE+EH4EJVDT4W6KBgeGPMFrDP0uhma/G d005AwQ+2XjJ0AG8iCnmGwVi8YBLCJ9xiWIDa5hTIV7Zg0gKgo9oTnMWcWRZZ4E= =2yyI -----END PGP SIGNATURE----- --5QAgd0e35j3NYeGe-- From owner-freebsd-current@freebsd.org Fri Jun 24 23:02:07 2016 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 9879CB802C3 for ; Fri, 24 Jun 2016 23:02:07 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 78C5E16C8; Fri, 24 Jun 2016 23:02:06 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u5ON2eNO004278; Fri, 24 Jun 2016 16:02:47 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: Brooks Davis Cc: In-Reply-To: <20160624225034.GC20770@spindle.one-eyed-alien.net> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> <330789230754140e38fb527973e23405@ultimatedns.net>, <20160624225034.GC20770@spindle.one-eyed-alien.net> From: "Chris H" Subject: Re: HEADS UP: caution required with updates using custom kernels Date: Fri, 24 Jun 2016 16:02:47 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <6700ea22b95dfa74f972e877c5b3b13c@ultimatedns.net> Content-Transfer-Encoding: 8bit X-Milter: Spamilter (Reciever: udns.ultimatedns.net; Sender-ip: 127.0.0.1; Sender-helo: ultimatedns.net; ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Jun 2016 23:02:07 -0000 On Fri, 24 Jun 2016 22:50:34 +0000 Brooks Davis wrote > On Fri, Jun 24, 2016 at 03:24:21PM -0700, Chris H wrote: > > On Fri, 24 Jun 2016 15:51:11 +0000 Brooks Davis wrote > > > > > On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: > > > > Am Thu, 23 Jun 2016 21:07:51 +0000 > > > > Brooks Davis schrieb: > > > > > > > > > Kernel config minimalists and those running aarch64 and riscv systems > > > > > will want to head this UPDATING message. > > > > > > > > > > In practice, if you're fairly up to date, doing installworld before > > > > > installkernel will also work (I've tested that case from ALPHA4), but > > > is > > always somewhat risky. > > > > > > > > > > -- Brooks > > > > > > > > > > ----- Forwarded message from Brooks Davis ----- > > > > > > > > > > Date: Thu, 23 Jun 2016 21:02:05 +0000 (UTC) > > > > > From: Brooks Davis > > > > > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > > > > > svn-src-head@freebsd.org > > > > > Subject: svn commit: r302152 - head > > > > > > > > > > Author: brooks > > > > > Date: Thu Jun 23 21:02:05 2016 > > > > > New Revision: 302152 > > > > > URL: https://svnweb.freebsd.org/changeset/base/302152 > > > > > > > > > > Log: > > > > > Add an UPDATING entry for the pipe() -> pipe2() transition. > > > > > > > > > > Approved by: re (gjb) > > > > > Sponsored by: DARPA, AFRL > > > > > > > > > > Modified: > > > > > head/UPDATING > > > > > > > > > > Modified: head/UPDATING > > > > > > > > > > > > > > ============================================================================= > > > > > = --- head/UPDATING Thu Jun 23 20:59:13 2016 (r302151) > > > > > +++ head/UPDATING Thu Jun 23 21:02:05 2016 (r302152) > > > > > @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11 > > > > > disable the most expensive debugging functionality run > > > > > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > > > > > > > > > > +20160622: > > > > > + The the libc stub for the pipe(2) system call has been replaced > > > with > > + a wrapper which calls the pipe2(2) system call and the > > > pipe(2) is > > now + only implemented by the kernels which include > > > "options > > + FREEBSD10_COMPAT" in their config file (this is the > > > default). > > + Users should ensure that this option is enabled in > > > their kernel > > + or upgrade userspace to r302092 before upgrading > > > their kernel. > > + > > > > > 20160527: > > > > > CAM will now strip leading spaces from SCSI disks' serial > > > numbers. > > This will effect users who create UFS filesystems on > > > SCSI disks > > using > > > > > > > > > > > > ----- End forwarded message ----- > > > > > > > > Is this showing up, when one doesn't have the expected COMPAT_FREEBSD10 > > > in > kernel and updated kernel __before___ world?: > > > > > > You must include COMPAT_FREEBSD10 or have a new userspace. Otherwise > > > things like your shell are unlikely to work. > > > > > Hi. I don't see any indication of why this change was required > > (the obsolescence of pipe(2)) > > Can you elaborate a little, please? > > pipe(2) had an unnecessarily odd calling convention (ignoring the > argument the user thought they were passing and returning the two file > descriptors via the two return registers). This required machine > dependent assembly for every target and special handling in tracing > tools (ktrace, dtrace, etc). On 64-bit platforms, pipe(2)'s > implementation is the only reason the two-register return model needs to > exist at all (on 32-bit platforms it allows off_t to be returned from > lseek). > > I'll own that my timing on this was terrible. In an ideal world the > user space change would have gone in months ago with the COMPAT10 change > now. Unfortunately I only realized this was something that made sense > while at BSDCan. > > Strictly speaking, this change isn't required, but making it making > it now allows aarch64 and riscv to be free of this dubious calling > convention and tidying up libc a bit. Opportunities to remove cruft at > the scale of syscall interfaces are rare so I've been pushing to clean > up aarch64 and riscv while we have a chance. > > -- Brooks Ahh. Pity that pipe(2) couldn't remain, well, pipe(2). None the less, thank you very much for such an informative reply, Brook. Greatly appreciated! Also, thanks for taking the time to fix it! --Chris -- From owner-freebsd-current@freebsd.org Sat Jun 25 02:13:25 2016 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 74C41B73F02; Sat, 25 Jun 2016 02:13:25 +0000 (UTC) (envelope-from gjb@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 6253D16C0; Sat, 25 Jun 2016 02:13:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 173AB1B8D; Sat, 25 Jun 2016 02:13:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 25 Jun 2016 02:13:24 +0000 From: Glen Barber To: freebsd-snapshots@FreeBSD.org, freebsd-current@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: New FreeBSD snapshots available: head (20160624 r302164) Message-ID: <20160625021324.GA21010@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 02:13:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 11.0-ALPHA5 amd64 GENERIC o 11.0-ALPHA5 i386 GENERIC o 11.0-ALPHA5 armv6 BANANAPI o 11.0-ALPHA5 armv6 BEAGLEBONE o 11.0-ALPHA5 armv6 CUBIEBOARD o 11.0-ALPHA5 armv6 CUBIEBOARD2 o 11.0-ALPHA5 armv6 CUBOX-HUMMINGBOARD o 11.0-ALPHA5 armv6 GUMSTIX o 11.0-ALPHA5 armv6 RPI-B o 11.0-ALPHA5 armv6 RPI2 o 11.0-ALPHA5 armv6 PANDABOARD o 11.0-ALPHA5 armv6 WANDBOARD o 11.0-ALPHA5 aarch64 GENERIC Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root, which it is strongly recommended to change the password for both users after gaining access to the system. Snapshots may be downloaded from the corresponding architecture directory from: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Please be patient if your local FTP mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list such as -current@ or -stable@ . === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 11.0-ALPHA5 amd64 o 11.0-ALPHA5 i386 o 11.0-ALPHA5 aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-0969a464 us-west-1 region: ami-8ba6e2eb us-west-2 region: ami-d419deb4 sa-east-1 region: ami-1ceb7e70 eu-west-1 region: ami-b93ea6ca eu-central-1 region: ami-1241a97d ap-northeast-1 region: ami-7ba1571a ap-northeast-2 region: ami-d8559eb6 ap-southeast-1 region: ami-a1c113c2 ap-southeast-2 region: ami-ecf3db8f === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-ALPHA5 % vagrant up == ISO CHECKSUMS == o 11.0-ALPHA5 amd64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-bootonly.iso) = f03a6b92be685afff6fe9788c90bde0957638cc094850929aa9ee532d86f38af4561ef80eaeee5fd2d823bc5bea872ea6711b3c81dc6e284ab4f81cad16892ca SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-bootonly.iso.xz) = 23e7a9c078ed1653454843f383c7695e7d81e7e12f92b8cb06c52c07d76b998e6f0d419ccdd5d8c19aab0d094d1b58a596f11664eb9c9dc96ea1c90b8613cb26 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-disc1.iso) = 940c18ba1f3d589bf6d0e66058bea0310388110bf64dc3df97d5f6402bc149137b05c41e02c3bf6bb188a7b285967324217265820e0d0a0ad83522c450ab0679 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-disc1.iso.xz) = 881e68e8399a1a26c6907d4e3bf8945c59660b6e74c27d432745bffbe0ac1b0aad2f728d4574f71b09f9b1728cd053107d24a0a2b5ae3d15c2b2e9aa760739ec SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-dvd1.iso) = 4dbc2bee256aa005d4620f998468890464e1517467cbd16509c6821b18283aaad29c173c1f3b3639f109cb8ba55de5bbe26c6d6a8823af4abe368b4339b875d5 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-dvd1.iso.xz) = 4601ccb01269c5cf55c81a050543e7f82e18527863d6b7fd24f374c31bab2c93f29f419c2ed336df64bd1f82e8b352780c14c7a49ea347fa0d600b7bd7224027 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-memstick.img) = e3657eaa8c7c6d32353c917fe3ccdbd1c6948d0ae947f4a3f1b247d8e3494346e4e5ede9c9c994110d377222485aba876b24d18555c1789578eae242203d03b7 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-memstick.img.xz) = 924b197c33b85cc9033f4b6808df5f211974a1a01719f5c6d4fee9db9751a3deed24d7117e4e2ef52413a46477a36021bdba8c2f9e66db0612f6cb9d943249a3 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-mini-memstick.img) = ce803ffc13ce9ce986adb36dbc22ca437a0c364e5a05689fc0d3ffbaffcb4e2e37434707051aa70732309246c02c77377576a94a8064dfbfd3137914b89466cf SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-mini-memstick.img.xz) = ec68cb54f6688c26cda367998dfc40ae85040ff3216b4e06dfa3ed3b656e7024d2f8d25989f2958754a9877a018343079a94c46a6b497ce1ee471614c014da69 SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-bootonly.iso) = 1f5cbd6c375987219a5a6ec8934df44e165dffdd8074c549a3c8b3e8dcd87d56 SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-bootonly.iso.xz) = 0376d6f40f53d066de808e21fcb7a19c40fdf900111394680668f6793356dc89 SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-disc1.iso) = 51a06ee18953dd903d73bc9e54b1b0402a176afab4026eb63bc37b5c0b88c294 SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-disc1.iso.xz) = 6ea5f21e394c2e55913fb05e014cf7c1e38c7a27bd26a7cd010aad96e061947d SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-dvd1.iso) = 9463ed91bfd5e13e07ef42e8711eba9b444030a21e48aac40e5a2f18861fb37e SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-dvd1.iso.xz) = bde44da8243f05fc216f3c5d94b7d0eb0d3118a8f5e63df3e09fa4b028f08fbc SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-memstick.img) = a407389cbba400e0b9c0f52afb3755a38b6da97fb3dad74608d88669aa959f80 SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-memstick.img.xz) = f400d587a6386ac9ae2034af28d1aca6135232a941a0ab95c7234f3465d2262c SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-mini-memstick.img) = bd555f799041972503303c901d5aacc0857be379870d73dd5b8e25b3d270a410 SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-mini-memstick.img.xz) = 08e327f1323657b7e75d6f2173ae7dbbfc8f4fdeae9ae1f596728bffa59f007e o 11.0-ALPHA5 i386 GENERIC: SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-bootonly.iso) = 493f2cacbb4e15327a5e5f55bfd73caf5d737aad00430556972f8e4ef5a801231595ad3ff0455d2dff8e6eb411ef54f44ad13e2af17b2010276e13840d12e1af SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-bootonly.iso.xz) = 10cad1b999f30a112d03944336203609f9424dbee2689a30c88cf1cfbe093d03ad1e5778e55e7320f39d673f4f52c1521bd64e0589f25f27c22734c935ce1348 SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-disc1.iso) = 76ffe92c95f12b2f68908a8dfbcfa58a3b78949126dbeb1f0e3852a7fe9150bd9409562a45b27032cd384e4d9ba8d83a49247fd3a1c413f7f5496e92bcdad290 SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-disc1.iso.xz) = dd68fa1085019d7a0b692c8a7e26a4963fa4caf53cef97ed5ecfac015ee3bbb9b5f8967cbe8afd992deaad01635143df9961be52e8d28dba61411e1ae4bfb2e5 SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-dvd1.iso) = 995d4e72af22d344d233ecedd5a90b2f610607d45c8eb6382509a285e39f560d9c8d843b5bd4832a9398cce8f2630a9f291f9a1b0fc9216d727c83efb5793951 SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-dvd1.iso.xz) = f64f15475b088aaab7d8628d265ad384a1cea68b251a2d75ddda20036a28a859ea3261c680ebe97c59609431df144c02ac1c3def21677ad39b4697bc090ad945 SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-memstick.img) = 5cb04723b6577b27a1ab364532a227bca7b8b280d5320e9638352bc5fd838a4d5677c3e117963e7bd9f54f68b17f5f995d09d6222cb13c6342af48e6b94b076a SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-memstick.img.xz) = 7c179fef4df1b8a51cfe3333710e8133558e83ae7c9e4b8f1f34a65d35b78618ce63f4ba4ec6c715b57bed45efe56f8547d6081730cb2fd11cb12a0c16e489dc SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-mini-memstick.img) = 6376f697771c3e7a6ecbc004a889353f4e0e4038e91e8528e26381835de15d79e091a9c4322b7f26b90aa51cc22f44f12b1ff1f2cc312e86681ca0905e6d69ee SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-mini-memstick.img.xz) = a24a281d6b3bf99bfcda7b47d93a30723fde49afc9973bb63120c0c944e3d6968aad502d5cc78afa95bf8c94801426f47b1b918582e8fb236728cfe582dca467 SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-bootonly.iso) = a58649ca9ae372a0e71f1902e4092b7b7ef4adc34929c39a83e74ad1a5ba0f10 SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-bootonly.iso.xz) = a2a1610178326c28c99a8ebc03ff89c396e7387b02631c4fb716e4fb07d83ea8 SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-disc1.iso) = af66c042cb900305cb3553293450f7fed1569cde9ef1b07fd826a2742225812b SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-disc1.iso.xz) = 981b4fa2123c6bc62a28385ea180c81008cbf438321a43896a044105ea328369 SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-dvd1.iso) = d3f20c61679ea681dcbe09c7d83e18247187027c493bc3f5d156bf6ac8d98776 SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-dvd1.iso.xz) = 9ba1e15b9ac429135c518494ccdd27ebb12d410ea0e682df5ed069325339cb7b SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-memstick.img) = d61e67c47a4eb84eba4319f5f39dee34efd81e6e72ee636cb3701fb29e05d8ff SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-memstick.img.xz) = dd5b9319deaba388717321cbd6b609d25b23ebf034690efddbc2152fe89c4e43 SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-mini-memstick.img) = 68b7ed4affc8f288eb822f50dd7eab699b0bc0610299708c579cc1f155446056 SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164-mini-memstick.img.xz) = a5520b57b0db00d88d67abe73c588de279e9f5f83f478105158c1630d8a28064 o 11.0-ALPHA5 armv6 BANANAPI: SHA512 (FreeBSD-11.0-ALPHA5-arm-armv6-BANANAPI-20160624-r302164.img.xz) = ad4c3a96620ce25c350c043368a5ea682fd1383e5dd399c5a9feefaae49d59ae0d29339b3866533ec1d093083727b24d811bedb6afd3ac6b223784ad84e98d4b SHA256 (FreeBSD-11.0-ALPHA5-arm-armv6-BANANAPI-20160624-r302164.img.xz) = a0c9874cff027909d64621a19334380d1d50c9ac0ce1b96f17423c0a49876075 o 11.0-ALPHA5 armv6 BEAGLEBONE: SHA512 (FreeBSD-11.0-ALPHA5-arm-armv6-BEAGLEBONE-20160624-r302164.img.xz) = 072bbf516fbbeedcf384df5e41fa6a66d65e0dae4b1da0f819300e2c48c920bc29db482e760d318d51bb65b7068fbac4e366d1ee9c3343dcd56b325260e56954 SHA256 (FreeBSD-11.0-ALPHA5-arm-armv6-BEAGLEBONE-20160624-r302164.img.xz) = 236d82c627faafe4cc34b22f7d0346501c740fe5d2b12a024903ad4d5df9b2ef o 11.0-ALPHA5 armv6 CUBIEBOARD: SHA512 (FreeBSD-11.0-ALPHA5-arm-armv6-CUBIEBOARD-20160624-r302164.img.xz) = 2ede315398aa940f1e545694f45b3fed9f6b12a0cfa95ba9bd321cf82be218ceab44c4e78abc2ef9cb7967e6aebc328f884c324ae2b209e6ff8f02342211dae0 SHA256 (FreeBSD-11.0-ALPHA5-arm-armv6-CUBIEBOARD-20160624-r302164.img.xz) = 01ff0f0443f6924a9fa50fb16a454d801591777a1739c7e16148be7122968423 o 11.0-ALPHA5 armv6 CUBIEBOARD2: SHA512 (FreeBSD-11.0-ALPHA5-arm-armv6-CUBIEBOARD2-20160624-r302164.img.xz) = 7c22c2bfebb9726c136ea765c1f7964d12b0aaf4bc4012be6c0edc523c51e735fe84c653b03999c96f9b93d05be7a8e4ee43ea6064271884e7c8a20a7cecc4df SHA256 (FreeBSD-11.0-ALPHA5-arm-armv6-CUBIEBOARD2-20160624-r302164.img.xz) = ffa3fcad7a34943929a61aae81f6fd71b447c0fe0d35007554098a26d20382e9 o 11.0-ALPHA5 armv6 CUBOX-HUMMINGBOARD: SHA512 (FreeBSD-11.0-ALPHA5-arm-armv6-CUBOX-HUMMINGBOARD-20160624-r302164.img.xz) = 6af51b0a6eef230ba4fa60b20bfc21e3ccf1405b26685ee0543f3cfbbd9921dccc667a0d324ce4cbc1e52f1fdf70a7a74be00c76fb26887d1a8a47c58c6da87e SHA256 (FreeBSD-11.0-ALPHA5-arm-armv6-CUBOX-HUMMINGBOARD-20160624-r302164.img.xz) = 426e0a787084b69749157699724b21e4c5d5ecb4a8acc0534060382b36cf11c9 o 11.0-ALPHA5 armv6 GUMSTIX: SHA512 (FreeBSD-11.0-ALPHA5-arm-armv6-GUMSTIX-20160624-r302164.img.xz) = c7f0bf4236f62453675f3de170300c149ebcb42da48cb660feb8f4ce81d0fd3b6224496f8d08af8344ca5afbc9e49209c809cbf606456fef71e8c336e5be544e SHA256 (FreeBSD-11.0-ALPHA5-arm-armv6-GUMSTIX-20160624-r302164.img.xz) = a6e810e39d35ba254075948766dc54eaf560baac12f50862518398c5ad824078 o 11.0-ALPHA5 armv6 RPI-B: SHA512 (FreeBSD-11.0-ALPHA5-arm-armv6-RPI-B-20160624-r302164.img.xz) = 385291746b7b6650fac94c97137b0f1593f694999e38e4708726863ecd9e3b7f47c6c73a73fe47cd5ab1e9f0af9f2b6b887c81d1ed1b6a1e245db57b73159142 SHA256 (FreeBSD-11.0-ALPHA5-arm-armv6-RPI-B-20160624-r302164.img.xz) = 3d351daa4b255d18e28a450cbf6e0904f9ec1cfb59eac4377e3fa4827e2d82d4 o 11.0-ALPHA5 armv6 RPI2: SHA512 (FreeBSD-11.0-ALPHA5-arm-armv6-RPI2-20160624-r302164.img.xz) = a496e18ab72ecad7119e8e7929a6625b7051ad6bfe589b7166147a61a9559ec655444dc41b7fff45459d804d9edcc273cc093eb2fd259f46be26657abe8f2d68 SHA256 (FreeBSD-11.0-ALPHA5-arm-armv6-RPI2-20160624-r302164.img.xz) = e3c840f18f73f3108f3f3b1c75e45998a542c1bfc42241e04bec193813b17778 o 11.0-ALPHA5 armv6 PANDABOARD: SHA512 (FreeBSD-11.0-ALPHA5-arm-armv6-PANDABOARD-20160624-r302164.img.xz) = c4b101830800daaed1408b8249ff29657cf2ed5da77881dd9735b827c8d308107f73c075ca6a31d1dfdcf1576eeae6fd36f0a4eccb9381f61d1d893a5fe7fb2b SHA256 (FreeBSD-11.0-ALPHA5-arm-armv6-PANDABOARD-20160624-r302164.img.xz) = dfe08d598c938b816ac214032ca31e42f1b93a0bdd32b9bf801ba36f90afcac8 o 11.0-ALPHA5 armv6 WANDBOARD: SHA512 (FreeBSD-11.0-ALPHA5-arm-armv6-WANDBOARD-20160624-r302164.img.xz) = 0b4bce2d4bdbe6bc68dc7a224da1f2c9a19caa724a1fa50447b93b67ef77cdaa82b5cf5fec0891873842f2e9e04b680a47ddceb14fcb9ed503c10ba10e0fbfc1 SHA256 (FreeBSD-11.0-ALPHA5-arm-armv6-WANDBOARD-20160624-r302164.img.xz) = 21c2272d0695602bf3a7d7c45c4484d1ecab3813102600669986de6d2ee99354 o 11.0-ALPHA5 aarch64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164-memstick.img) = 061e28d14a7b46d9a76df47e0add96e8f824cceea3375927f9cfaf0fc40866e9ff6eb29e6c4bedf14d89b5157796e2407545555e8602629b3916a2311c087987 SHA512 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164-memstick.img.xz) = 3aca714bc5cb714f6c82d36b6eb1d321204627edc795429167d1e0f32669110bebca491446ff8f5709b3cf643a5a54aa30c43b03f877e825718fb3ff3e052704 SHA512 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164-mini-memstick.img) = 48e24c47b2f74da21cbc3173e40dbd2bcd704943eaaa81c9e2247ac291bb916474be9326a00d13a3228d8fb180be9ce66f76cf7e81088cdded37ec11b63c442a SHA512 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164-mini-memstick.img.xz) = acbfb02fdc2e28f2c8ecd9a1d10aca8e6589b89b5209b44bb3a0e33f79a960bf2d5a98e28167aa47b8bc64e07467d55c69d0aeb93f8d8a070154714348b5be00 SHA256 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164-memstick.img) = 47697957e7a175eeb31488af34460b61fb753c1117da25895b3c8736b57a7c5e SHA256 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164-memstick.img.xz) = 6d7b029186c631cdd92c49a5806d9c0e5996eb4daf078d8c54197738d928c99c SHA256 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164-mini-memstick.img) = f462e91dfe4f36968afaa58f5262d418ea31d77895da59d40608ddd19be30de3 SHA256 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164-mini-memstick.img.xz) = 1684a0dfba38165eaff2ce709e82342f9248048d9c8001e66944ba7d75bdb099 == VM IMAGE CHECKSUMS == o 11.0-ALPHA5 amd64: SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164.qcow2.xz) = 3060f63fe802433faa158b8c6dd46ce676c54c61128e636cfed30484067d829e1e247ee876cb62867717934c23764154f5b3e27f26bc1a2c4135aeabd83ac17f SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164.raw.xz) = f43b744a8689a4cc9c7df6650af8ca56f1bf9957358eadf63e2d8c826b4559f5df4aa90d9f84d1207ffb33ed5ff77365bbc52464f7ade5a8575fecf243b17e65 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164.vhd.xz) = 36cb0c6abb908e64d365ec8ff83e7cb7e9731d5b7921ca423777340852c49ff786b2dddb207e1459117aec71af8ea092da1562f700cb710a06f15daf147cc6f4 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164.vmdk.xz) = c347937bad7e2b04714ca31ce864a047903dd602d68c6ccf140af35c018228e459d42078adce48dab9c9424d76fb83b524d7d7920a30cb3cb64d9f418ede06b6 SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164.qcow2.xz) = 4ec5d46bffcf542cc7623ce9cc5af55f8370830d0ba9e4a17483cff1febc408b SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164.raw.xz) = 6316fba95713df0d6b469432b90b2d76f643b16f71dfc5e6ed03d48ef80119d1 SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164.vhd.xz) = 495adba3b753eb7b407b4e7f65da89f375825277468c2143b0d8b015300932ab SHA256 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164.vmdk.xz) = 142c04308c740ec5c1a62a28adcfd818634883222c124780177e746423329bdb o 11.0-ALPHA5 i386: SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164.qcow2.xz) = 9a7b7d2797849d412b669da6ee0d357c1ef0d58edc2ba321482825b91926473d54ccf2f0719b501814954cb23d08179682be710eb858ffacacfe59cd3a1b1bd7 SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164.raw.xz) = 25a31db2183cf43f196e3fcf57d6f3c392e057f05a79f8f2f8742e411d441ec87130a24bfde5da59b3db82c5943050b0f5d25a8cbaa865f264f5af4e0ddbaf60 SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164.vhd.xz) = b092ca4aec54b0757dbe2ac0c948bcc3d5f2eb99c1404a1f2afa22a7a95e388b9d44036982c3f706645376d1e0296cd4ab896ff7c7a812d4b0e93084bf77bde3 SHA512 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164.vmdk.xz) = 9f33d4c8c077bfb7867b0a85f290f72cb9088a8a8ade59d78e4817626d4a6d4a2eb5287f59aca8a1001eacca904552046c627af805f72c8ae706f6d54ce2eb32 SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164.qcow2.xz) = 0e3fe60b0ce2c4534b94d9db7496ea3f1b0e723463a73603f534483c2d68fe4a SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164.raw.xz) = 7b031294670c95267f54158a1476e2c98bb13ad0246303813d45a40d3633e7a3 SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164.vhd.xz) = 0cb28988b0f064378e34f1502e1f10ae3d48b0ba6145dfbec876237a4081bd0b SHA256 (FreeBSD-11.0-ALPHA5-i386-20160624-r302164.vmdk.xz) = aa204a87d97cec4093447cb98f152584b22f49ea046cf3aa94900f566e6152d7 o 11.0-ALPHA5 aarch64: SHA512 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164.qcow2.xz) = 05ba7919d8d61f759abce5d9f5b5bd028d2d6e31b151f962b9fb9ac08259947b1cd0c0167fb802dd1719763a4a9473d32fcc1181bf11fce9aaca52a53e67feca SHA512 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164.raw.xz) = 0e8b31c43a7613e26a6b8319279df30760022be3429301fed546a6b4bf29bc4645e410b78680755e9d3104115a572410b9d22240088119becdde8a3ad9bce8ac SHA512 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164.vhd.xz) = 7a9749f3fbc5686f4beb9f3a9b70d94831b36fd2bdb5b5fc28588a74cff27c4494608085c5bf6f53b365617be25aa63c4132a1704ce5882bbd8ff6986da40c31 SHA512 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164.vmdk.xz) = 66a8de65467ab80992a81af68f35c2fb3479f8f46feccaf4eedfc2c2f4840d463a49eefeb1dd59f3fa4513c2f9082f2d768c7931381aa74b99118575ad7e1cbb SHA256 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164.qcow2.xz) = 96f738fe49c7d160af25114a8432364b13bda3efae1caf723f26ad1f0ec43e95 SHA256 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164.raw.xz) = cb27cacc0bd355f0d1db6a8bf4b5abe28aee48f78bdfb9d67628db1c36d380a8 SHA256 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164.vhd.xz) = 3aeffb4ed3e810d499c7717028926fb01e0b69a1132e5fe80de2289c0ee9bbc1 SHA256 (FreeBSD-11.0-ALPHA5-arm64-aarch64-20160624-r302164.vmdk.xz) = 27071a3ab5f9b67a02b2b30916afe7c072964f27c73245bb9daf7667aba941bf Regards, Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXbejEAAoJEAMUWKVHj+KTwAEQAJBtayfroD7vpDNt9K0mQl/z km3w2JQse8TP/ZNBx0RWSVe6WpeqLDjwgLwsZ9WkTxGd84WejhGtXqp8JyqYgTrW HhZZ4A/GlW6OreiSQwfhEAkFMqyFTxUkvpfLpwvUwzIkHe2Gr6bcKNOLAG/97wx3 XGFs2vc9Bw34uu9GHjoYQ9fmuTGAExSUlGLnkGqx2asBMRNLPcPbtkBvdW0EXncB fuY2Ij/f8gceMq7cUoY7RnGWAuClTFGrBNyczUeUDKWA7hY/DmP99tC85OBSo9eB ytZtlvMb6JsbHNX8CddKpIyP3GyfiCTFI1JTHs0cUlYkrQwq7uh4lJeBH+uZmKbv Gbic0By/vQlaUJvhgLlUJbP4QpMTueaTb3Pz07RD7rpdgwe50zoDLTsTwBP6TDrA Xh+7pafRACJ1W6ZZzvhGh8mHMmXzaPe5mlZ+f3kklPRaDtrE3IZQbTGpKZbk+7/T EgoifAGox4q+sstC7HMk8xVEUukWFZx6fPfgb/iQn0XXh5uE4xGSCMYmHw1kItFV 202n5NPxlPi0lgD7eCTEuAh8pIo0v2eSOiCVULPUm4Z6b2iPBmtO1H1UF9PFoncC xEOvf3dlo95NKXqsRUxccIl8ihpR+6Dk/EIFGafUQo7U1FaBYVdp5qWB2c3KQ/9u DtKKgGxrV1SNQy7XHNTu =TwuS -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Sat Jun 25 04:50:41 2016 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 C408FB73F9C for ; Sat, 25 Jun 2016 04:50:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 8794A21EF for ; Sat, 25 Jun 2016 04:50:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18086 invoked from network); 25 Jun 2016 04:51:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Jun 2016 04:51:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 25 Jun 2016 00:50:30 -0400 (EDT) Received: (qmail 15732 invoked from network); 25 Jun 2016 04:50:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Jun 2016 04:50:30 -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 Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id CC8DF1C4079; Fri, 24 Jun 2016 21:50:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists From: Mark Millard In-Reply-To: Date: Fri, 24 Jun 2016 21:50:31 -0700 Cc: Ian Lepore , "Conrad E. Meyer" , freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <6727481C-8BD2-4F00-A6F6-3BEE3CC7F2FA@dsl-only.net> References: <1465862808.1188.129.camel@freebsd.org> To: Alan Somers X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 04:50:41 -0000 On 2016-Jun-24, at 2:50 PM, Alan Somers wrote: > As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring > tests should all be fixed. I opened PR 210329 for the > usr.bin/lastcomm test. I haven't investigated the others. >=20 > -Alan I updated to -r302180 and ran kyua again. It confirms the rpcbind, acl, and bitstring items are gone from the broken and failed lists. This time the totals were 15 broken (down from 24) and 41 failed (down from 59). My results this time were. . . # kyua report --results-filter broken --results-file /usr/tests | more =3D=3D=3D> Broken tests lib/msun/cexp_test:main -> broken: Received signal 6 [1.094s] lib/msun/ctrig_test:main -> broken: Received signal 6 [1.097s] lib/msun/exponential_test:main -> broken: Received signal 6 [1.097s] lib/msun/fenv_test:main -> broken: Received signal 6 [1.099s] lib/msun/fma_test:main -> broken: Received signal 6 [1.114s] lib/msun/invctrig_test:main -> broken: Received signal 6 [1.118s] lib/msun/invtrig_test:main -> broken: Received signal 6 [1.114s] lib/msun/logarithm_test:main -> broken: Received signal 6 [1.096s] lib/msun/lrint_test:main -> broken: Received signal 6 [1.096s] lib/msun/nearbyint_test:main -> broken: Received signal 6 [1.096s] lib/msun/rem_test:main -> broken: Received signal 6 [1.091s] lib/msun/trig_test:main -> broken: Received signal 6 [1.094s] sbin/growfs/legacy_test:main -> broken: Reported plan differs from = actual executed tests [0.479s] sys/geom/class/eli/integrity_copy_test:main -> broken: Test case timed = out [1200.089s] sys/geom/class/eli/onetime_a_test:main -> broken: Test case timed out = [600.041s] =3D=3D=3D> Summary Results read from = /root/.kyua/store/results.usr_tests.20160625-012941-048472.db Test cases: 5700 total, 54 skipped, 20 expected failures, 15 broken, 41 = failed Total time: 9093.092s # kyua report --results-filter failed --results-file /usr/tests | more =3D=3D=3D> Failed tests lib/libc/c063/fstatat_test:fstatat_fd -> failed: = /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: memcmp(&st1, = &st2, sizeof(st1)) =3D=3D 0 not met [0.028s] lib/libc/ssp/ssp_test:fgets -> failed: Test case body returned a = non-ok exit code, but this is not allowed [0.159s] lib/libc/ssp/ssp_test:gets -> failed: Test case body returned a non-ok = exit code, but this is not allowed [0.152s] lib/libc/ssp/ssp_test:memcpy -> failed: atf-check failed; see the = output of the test for details [0.150s] lib/libc/ssp/ssp_test:memmove -> failed: atf-check failed; see the = output of the test for details [0.149s] lib/libc/ssp/ssp_test:memset -> failed: atf-check failed; see the = output of the test for details [0.152s] lib/libc/ssp/ssp_test:read -> failed: Test case body returned a non-ok = exit code, but this is not allowed [0.159s] lib/libc/ssp/ssp_test:readlink -> failed: atf-check failed; see the = output of the test for details [0.161s] lib/libc/ssp/ssp_test:snprintf -> failed: atf-check failed; see the = output of the test for details [0.143s] lib/libc/ssp/ssp_test:sprintf -> failed: atf-check failed; see the = output of the test for details [0.143s] lib/libc/ssp/ssp_test:stpcpy -> failed: atf-check failed; see the = output of the test for details [0.146s] lib/libc/ssp/ssp_test:stpncpy -> failed: atf-check failed; see the = output of the test for details [0.149s] lib/libc/ssp/ssp_test:strcat -> failed: atf-check failed; see the = output of the test for details [0.148s] lib/libc/ssp/ssp_test:strcpy -> failed: atf-check failed; see the = output of the test for details [0.152s] lib/libc/ssp/ssp_test:strncat -> failed: atf-check failed; see the = output of the test for details [0.143s] lib/libc/ssp/ssp_test:strncpy -> failed: atf-check failed; see the = output of the test for details [0.147s] lib/libc/ssp/ssp_test:vsnprintf -> failed: atf-check failed; see the = output of the test for details [0.145s] lib/libc/ssp/ssp_test:vsprintf -> failed: atf-check failed; see the = output of the test for details [0.146s] lib/libc/stdio/printbasic_test:int_within_limits -> failed: = printf("%tu", (size_t)-1) =3D=3D> [18446744073709551615], expected = [4294967295]<> [0.029s] lib/libc/stdio/scanfloat_test:infinities_and_nans -> failed: = /usr/src/lib/libc/tests/stdio/scanfloat_test.c:191: = fetestexcept(FE_INVALID) =3D=3D 0 not met [0.032 s] lib/libc/sys/mincore_test:mincore_resid -> failed: = /usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:225: = check_residency(addr, npgs) =3D=3D 0 not met [0.04 1s] lib/libc/sys/mincore_test:mincore_shmseg -> failed: = /usr/src/contrib/netbsd-tests/lib/libc/sys/t_mincore.c:298: = check_residency(addr, npgs) =3D=3D 0 not met [0.0 32s] lib/libc/tls/tls_dynamic_test:t_tls_dynamic -> failed: 15 checks = failed; see output for more details [0.037s] lib/libproc/proc_test:symbol_lookup -> failed: = /usr/src/lib/libproc/tests/proc_test.c:116: state !=3D PS_STOP: process = has state 4 [0.180s] lib/libxo/functional_test:test_02__E -> failed: atf-check failed; see = the output of the test for details [0.165s] lib/libxo/functional_test:test_02__H -> failed: atf-check failed; see = the output of the test for details [0.169s] lib/libxo/functional_test:test_02__HIPx -> failed: atf-check failed; = see the output of the test for details [0.174s] lib/libxo/functional_test:test_02__HP -> failed: atf-check failed; see = the output of the test for details [0.168s] lib/libxo/functional_test:test_02__J -> failed: atf-check failed; see = the output of the test for details [0.168s] lib/libxo/functional_test:test_02__JP -> failed: atf-check failed; see = the output of the test for details [0.165s] lib/libxo/functional_test:test_02__T -> failed: atf-check failed; see = the output of the test for details [0.169s] lib/libxo/functional_test:test_02__X -> failed: atf-check failed; see = the output of the test for details [0.165s] lib/libxo/functional_test:test_02__XP -> failed: atf-check failed; see = the output of the test for details [0.170s] lib/msun/conj_test:main -> failed: 9 tests of 42 failed [0.034s] lib/msun/ldexp_test:ldexp_denormal -> failed: 4 checks failed; see = output for more details [0.032s] local/kyua/model/metadata_test:override_all_with_set_string -> failed: = Line 253: disk_space !=3D md.required_disk_space() (16777216.00T !=3D = 2.00G) [0.045s] local/kyua/testers/tap_parser_test:try_parse_plan__insane -> failed: = testers/tap_parser_test.c:135: 'too long' not matched in 'Plan line = includes out of range numbers' [0.034s] sys/geom/class/eli/resize_test:main -> failed: 15 tests of 27 failed = [1.094s] sys/kern/pipe/pipe_fstat_bug_test:main -> failed: Returned non-success = exit status 1 [0.038s] usr.bin/lastcomm/legacy_test:main -> failed: 4 tests of 6 failed = [0.139s] usr.sbin/sa/legacy_test:main -> failed: 12 tests of 13 failed = [0.330s] =3D=3D=3D> Summary Results read from = /root/.kyua/store/results.usr_tests.20160625-012941-048472.db Test cases: 5700 total, 54 skipped, 20 expected failures, 15 broken, 41 = failed Total time: 9093.092s =3D=3D=3D Mark Millard markmi@dsl-only.net From owner-freebsd-current@freebsd.org Sat Jun 25 07:02:48 2016 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 69602B80593 for ; Sat, 25 Jun 2016 07:02:48 +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 F35A1129D; Sat, 25 Jun 2016 07:02:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5P72cTL016692 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 25 Jun 2016 10:02:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5P72cTL016692 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5P72cpE016691; Sat, 25 Jun 2016 10:02:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 25 Jun 2016 10:02:38 +0300 From: Konstantin Belousov To: Brooks Davis Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160625070238.GG38613@kib.kiev.ua> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> <330789230754140e38fb527973e23405@ultimatedns.net> <20160624225034.GC20770@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160624225034.GC20770@spindle.one-eyed-alien.net> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 25 Jun 2016 07:02:48 -0000 On Fri, Jun 24, 2016 at 10:50:34PM +0000, Brooks Davis wrote: > pipe(2) had an unnecessarily odd calling convention (ignoring the > argument the user thought they were passing and returning the two file > descriptors via the two return registers). This required machine > dependent assembly for every target and special handling in tracing > tools (ktrace, dtrace, etc). On 64-bit platforms, pipe(2)'s > implementation is the only reason the two-register return model needs to > exist at all (on 32-bit platforms it allows off_t to be returned from > lseek). getpid() is another instance. From owner-freebsd-current@freebsd.org Sat Jun 25 07:44:59 2016 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 BF74EB80F4B; Sat, 25 Jun 2016 07:44:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 70D5B222F; Sat, 25 Jun 2016 07:44:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qk0-x234.google.com with SMTP id p10so168278205qke.3; Sat, 25 Jun 2016 00:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dOUOyXiko7OKNRpyzXMf1z60ejWwD1G+CyA+ouvZ2+A=; b=WqSfxsybTHzNYe0L5V48VEZkwrRM09ppVMBuAgSCZL6UJZgbitXVrrr8w3jp3VPZN3 L2Wc4cEl6s06V6AHogczGB5Hb8SqUh+XLhShtog/ol3zkaXQuifpgBNbiFjN5Oh1pUFN cyf6UYuSfID7P98a5BvI9F0IjuTzP31SNbmTRAKytSEhEr4N6Mh39XTYeIwiDtKxN/MG ok9Voq7eGCCJBUpiOTA4RrYWEPTpzn9UdtNtIBPjqqGQlsfCxRZzG89XqrnqCZ5I5Jf7 wGqm/pz3xKdt8S5zPjFBm9YojqEnT+8lQ9ozm30fEQgGQm39uRdbMFOv8lVwseQsFZPE tfSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dOUOyXiko7OKNRpyzXMf1z60ejWwD1G+CyA+ouvZ2+A=; b=ehp0TdqUm4Cd2lX8aMqyDhrAvKDuOJb2edAkEXS+U/V0K60W33SbPWyaExPo63gZY1 j+jaLGI7WvQh4EuQZXXS5+WvMU8CM/IyD+F1ypuYYC58d4eBFVWhkStmQt4hRDOwQ1g/ 8GJU7+kE0OI2pG5mSjJ37T5UyMn4LJYdUXQqa5ArVspmiq8Q8/kdaX+Gh2rPBbKzk/ld Yoa1/04ygymdW5X5vHHOz6NT9EQFVQ/1mu0dmuIUW+ArQenw8izDEaGtZgBfYAUHowh1 V2/oqkyg94tR1IonV6cifT59CK9cYo6VD8Fh+IUPj2/9rA8xmwVz7dzHRVIZCw5aCF7f Sumw== X-Gm-Message-State: ALyK8tIoPEpjjdXSH4J4amwwJzO4Oou2ine5N/+34V6qr9+CKh33IRegb7uIiefB4wWm9h44LHuqLKBUKijNwg== X-Received: by 10.55.87.194 with SMTP id l185mr8698769qkb.204.1466840698642; Sat, 25 Jun 2016 00:44:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.148.131 with HTTP; Sat, 25 Jun 2016 00:44:58 -0700 (PDT) In-Reply-To: <6727481C-8BD2-4F00-A6F6-3BEE3CC7F2FA@dsl-only.net> References: <1465862808.1188.129.camel@freebsd.org> <6727481C-8BD2-4F00-A6F6-3BEE3CC7F2FA@dsl-only.net> From: Ngie Cooper Date: Sat, 25 Jun 2016 00:44:58 -0700 Message-ID: Subject: Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists To: Mark Millard Cc: Alan Somers , Ian Lepore , "Conrad E. Meyer" , freebsd-arm , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 07:44:59 -0000 On Fri, Jun 24, 2016 at 9:50 PM, Mark Millard wrote: > On 2016-Jun-24, at 2:50 PM, Alan Somers wrote: > >> As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring >> tests should all be fixed. I opened PR 210329 for the >> usr.bin/lastcomm test. I haven't investigated the others. ... > This time the totals were 15 broken (down from 24) and 41 failed (down > from 59). > > My results this time were. . . Hi Mark, Please file bugs for all of the individual component failures, e.g. lib/msun, and CC me on the bugs. Thanks, -Ngie From owner-freebsd-current@freebsd.org Sat Jun 25 08:49:48 2016 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 2CDFFB732E6 for ; Sat, 25 Jun 2016 08:49:48 +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 A25CB1E2A for ; Sat, 25 Jun 2016 08:49:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5P8neot041499 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 25 Jun 2016 11:49:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5P8neot041499 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5P8ndTj041498; Sat, 25 Jun 2016 11:49:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 25 Jun 2016 11:49:39 +0300 From: Konstantin Belousov To: Guy Yur Cc: Daniel Engberg , freebsd-current Subject: Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4 Message-ID: <20160625084939.GI38613@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 25 Jun 2016 08:49:48 -0000 On Sat, Jun 25, 2016 at 01:03:13AM +0300, Guy Yur wrote: > libtdb.so.1`tdb_runtime_check_for_robust_mutexes + 1475 at mutex.c:957 > ... The pointer to tdb_runtime_check_for_robust_mutexes() appeared to be most useful, thanks. The two patches below should fix samba use of robustness. First, kernel erronously reset robust lists locations on fork. Second, the pthread_mutex_trylock() for owned errorcheck mutex must return EDEADLK and not EBUSY. Try that. diff --git a/lib/libthr/thread/thr_mutex.c b/lib/libthr/thread/thr_mutex.c index 5a99605..da71c70 100644 --- a/lib/libthr/thread/thr_mutex.c +++ b/lib/libthr/thread/thr_mutex.c @@ -850,9 +871,12 @@ mutex_self_trylock(struct pthread_mutex *m) switch (PMUTEX_TYPE(m->m_flags)) { case PTHREAD_MUTEX_ERRORCHECK: - case PTHREAD_MUTEX_NORMAL: case PTHREAD_MUTEX_ADAPTIVE_NP: - ret = EBUSY; + ret = EDEADLK; + break; + + case PTHREAD_MUTEX_NORMAL: + ret = EBUSY; break; case PTHREAD_MUTEX_RECURSIVE: diff --git a/sys/sys/proc.h b/sys/sys/proc.h index 6d03062..6162a16 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -282,9 +282,6 @@ struct thread { int td_no_sleeping; /* (k) Sleeping disabled count. */ int td_dom_rr_idx; /* (k) RR Numa domain selection. */ void *td_su; /* (k) FFS SU private */ - uintptr_t td_rb_list; /* (k) Robust list head. */ - uintptr_t td_rbp_list; /* (k) Robust priv list head. */ - uintptr_t td_rb_inact; /* (k) Current in-action mutex loc. */ #define td_endzero td_sigmask /* Copied during fork1() or create_thread(). */ @@ -298,6 +295,9 @@ struct thread { u_char td_base_user_pri; /* (t) Base user pri */ u_int td_dbg_sc_code; /* (c) Syscall code to debugger. */ u_int td_dbg_sc_narg; /* (c) Syscall arg count to debugger.*/ + uintptr_t td_rb_list; /* (k) Robust list head. */ + uintptr_t td_rbp_list; /* (k) Robust priv list head. */ + uintptr_t td_rb_inact; /* (k) Current in-action mutex loc. */ #define td_endcopy td_pcb /* From owner-freebsd-current@freebsd.org Sat Jun 25 09:20:47 2016 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 9CDDCB73FE6 for ; Sat, 25 Jun 2016 09:20:47 +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 4856C2D73 for ; Sat, 25 Jun 2016 09:20:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5P9KeR9049434 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 25 Jun 2016 12:20:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5P9KeR9049434 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5P9Kejq049433; Sat, 25 Jun 2016 12:20:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 25 Jun 2016 12:20:40 +0300 From: Konstantin Belousov To: Guy Yur Cc: Daniel Engberg , freebsd-current Subject: Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4 Message-ID: <20160625092040.GL38613@kib.kiev.ua> References: <20160625084939.GI38613@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160625084939.GI38613@kib.kiev.ua> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 25 Jun 2016 09:20:47 -0000 On Sat, Jun 25, 2016 at 11:49:39AM +0300, Konstantin Belousov wrote: > On Sat, Jun 25, 2016 at 01:03:13AM +0300, Guy Yur wrote: > > libtdb.so.1`tdb_runtime_check_for_robust_mutexes + 1475 at mutex.c:957 > > ... > > The pointer to tdb_runtime_check_for_robust_mutexes() appeared to be > most useful, thanks. > > The two patches below should fix samba use of robustness. First, > kernel erronously reset robust lists locations on fork. Second, the > pthread_mutex_trylock() for owned errorcheck mutex must return EDEADLK > and not EBUSY. Try that. Correction, there was a reason why I initially put the rb list pointers into zeroed region. It still needs to be zeroed on new thread creation. Updated patch. diff --git a/lib/libthr/thread/thr_mutex.c b/lib/libthr/thread/thr_mutex.c index 5a99605..da71c70 100644 --- a/lib/libthr/thread/thr_mutex.c +++ b/lib/libthr/thread/thr_mutex.c @@ -850,9 +871,12 @@ mutex_self_trylock(struct pthread_mutex *m) switch (PMUTEX_TYPE(m->m_flags)) { case PTHREAD_MUTEX_ERRORCHECK: - case PTHREAD_MUTEX_NORMAL: case PTHREAD_MUTEX_ADAPTIVE_NP: - ret = EBUSY; + ret = EDEADLK; + break; + + case PTHREAD_MUTEX_NORMAL: + ret = EBUSY; break; case PTHREAD_MUTEX_RECURSIVE: diff --git a/sys/kern/kern_thr.c b/sys/kern/kern_thr.c index 10ccdab..293574c 100644 --- a/sys/kern/kern_thr.c +++ b/sys/kern/kern_thr.c @@ -234,6 +234,7 @@ thread_create(struct thread *td, struct rtprio *rtp, bcopy(&td->td_startcopy, &newtd->td_startcopy, __rangeof(struct thread, td_startcopy, td_endcopy)); newtd->td_proc = td->td_proc; + newtd->td_rb_list = newtd->td_rbp_list = newtd->td_rb_inact = 0; thread_cow_get(newtd, td); error = initialize_thread(newtd, thunk); diff --git a/sys/sys/proc.h b/sys/sys/proc.h index 6d03062..6162a16 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -282,9 +282,6 @@ struct thread { int td_no_sleeping; /* (k) Sleeping disabled count. */ int td_dom_rr_idx; /* (k) RR Numa domain selection. */ void *td_su; /* (k) FFS SU private */ - uintptr_t td_rb_list; /* (k) Robust list head. */ - uintptr_t td_rbp_list; /* (k) Robust priv list head. */ - uintptr_t td_rb_inact; /* (k) Current in-action mutex loc. */ #define td_endzero td_sigmask /* Copied during fork1() or create_thread(). */ @@ -298,6 +295,9 @@ struct thread { u_char td_base_user_pri; /* (t) Base user pri */ u_int td_dbg_sc_code; /* (c) Syscall code to debugger. */ u_int td_dbg_sc_narg; /* (c) Syscall arg count to debugger.*/ + uintptr_t td_rb_list; /* (k) Robust list head. */ + uintptr_t td_rbp_list; /* (k) Robust priv list head. */ + uintptr_t td_rb_inact; /* (k) Current in-action mutex loc. */ #define td_endcopy td_pcb /* From owner-freebsd-current@freebsd.org Sat Jun 25 10:16:43 2016 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 A06D4B80E08 for ; Sat, 25 Jun 2016 10:16:43 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 361042ABC for ; Sat, 25 Jun 2016 10:16:43 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id r201so53873491wme.1 for ; Sat, 25 Jun 2016 03:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oK+w3Zfb/FF/85damoy2BQqre5cFroYJ15lke9ZUqqQ=; b=ot6Cj3O6eFTCJcizX0k1mdk49BN8VQNbKgEWaCFIG0uMGAutiq+F3xtmMiIDCC/fkS I8G/42ddWUE6JclwQYLKdFbZUavAPfedv1CMwUUzPCrRNvjl6XypYBdGWs1FYJviSTrC XwBFSQJu1kgngHcG7qv2D7eethS/hvjEPjQ1tnVg5gMxi3zn2f839P0NnR507McX/wpZ Zb94iP4fM88Rgppye8qm2aqnrzIQcjdV924+u//5qrYalUG2HSty9N/JRPCiNA8/wBpF C2OTJXv1iNrnOD4L3R9ptr4VNObgQE7Cy0yt/ekP5xGig6mWuSA4uCjSrF6eiKndg4ZI xKHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oK+w3Zfb/FF/85damoy2BQqre5cFroYJ15lke9ZUqqQ=; b=iUW6ZU7TlT3iBJT9ZuQITcRUoUiYkimeILqBsF7F3KL4fckuT2goy52xoPTOSVdLb1 bCjTFD/qJbZwOh4a7L8beMhKggJYWdYm22UfzssC9EZooy/OUagCzuZ8cWXcsV9L+0nP no8kFpS/A3tghHcuYSqkoGaDZ/8jos2QVQlvyfhMOySVgwiZTKZ3hz9WgGncayBkDm0O boCQxYKGHVDC/0MgfkuAi/WtVRWAmhpJO31P8/urEGJAGhCTpNjszQaJxUqPpEhglva+ d/VqcbCkYaMp/dl9kYL9nd/9V4munwMCPkcu/Zu5zoOEDSVqa+nxa0sW6j75TrxNL8kz nesQ== X-Gm-Message-State: ALyK8tLxwYlCvJt6KF75uTfmGot3u9bQboC9RSfjD6RYrzMJgB+u31G3/ttT3nHSnnb/514Vi5V7z/MXXRY7kg== X-Received: by 10.28.50.131 with SMTP id y125mr2382068wmy.94.1466849801251; Sat, 25 Jun 2016 03:16:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.9.142 with HTTP; Sat, 25 Jun 2016 03:16:40 -0700 (PDT) In-Reply-To: <20160625092040.GL38613@kib.kiev.ua> References: <20160625084939.GI38613@kib.kiev.ua> <20160625092040.GL38613@kib.kiev.ua> From: Guy Yur Date: Sat, 25 Jun 2016 13:16:40 +0300 Message-ID: Subject: Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4 To: Konstantin Belousov Cc: Daniel Engberg , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 10:16:43 -0000 Hi, On Sat, Jun 25, 2016 at 12:20 PM, Konstantin Belousov wrote: > On Sat, Jun 25, 2016 at 11:49:39AM +0300, Konstantin Belousov wrote: >> On Sat, Jun 25, 2016 at 01:03:13AM +0300, Guy Yur wrote: >> > libtdb.so.1`tdb_runtime_check_for_robust_mutexes + 1475 at mutex.c:957 >> > ... >> >> The pointer to tdb_runtime_check_for_robust_mutexes() appeared to be >> most useful, thanks. >> >> The two patches below should fix samba use of robustness. First, >> kernel erronously reset robust lists locations on fork. Second, the >> pthread_mutex_trylock() for owned errorcheck mutex must return EDEADLK >> and not EBUSY. Try that. > > Correction, there was a reason why I initially put the rb list pointers > into zeroed region. It still needs to be zeroed on new thread creation. > Updated patch. > With the patch to the 3 files applied, smbd, nmbd and smbclient no longer crash on my machine. Tested with r302191+patch. Thanks, Guy From owner-freebsd-current@freebsd.org Sat Jun 25 10:26:28 2016 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 4A8D7B80117 for ; Sat, 25 Jun 2016 10:26:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 ED4C92F72 for ; Sat, 25 Jun 2016 10:26:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25118 invoked from network); 25 Jun 2016 10:26:59 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Jun 2016 10:26:59 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 25 Jun 2016 06:26:21 -0400 (EDT) Received: (qmail 28810 invoked from network); 25 Jun 2016 10:26:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Jun 2016 10:26:21 -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.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 78E431C407C; Sat, 25 Jun 2016 03:26:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists From: Mark Millard In-Reply-To: Date: Sat, 25 Jun 2016 03:26:23 -0700 Cc: Alan Somers , Ian Lepore , "Conrad E. Meyer" , freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <5D3DEF2A-A14F-456B-B2D5-4E95BD273DB7@dsl-only.net> References: <1465862808.1188.129.camel@freebsd.org> <6727481C-8BD2-4F00-A6F6-3BEE3CC7F2FA@dsl-only.net> To: Ngie Cooper X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 10:26:28 -0000 On 2016-Jun-25, at 12:44 AM, Ngie Cooper = wrote: > On Fri, Jun 24, 2016 at 9:50 PM, Mark Millard = wrote: >> On 2016-Jun-24, at 2:50 PM, Alan Somers wrote: >>=20 >>> As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring >>> tests should all be fixed. I opened PR 210329 for the >>> usr.bin/lastcomm test. I haven't investigated the others. >=20 > ... >=20 >> This time the totals were 15 broken (down from 24) and 41 failed = (down >> from 59). >>=20 >> My results this time were. . . >=20 > Hi Mark, > Please file bugs for all of the individual component failures, > e.g. lib/msun, and CC me on the bugs. > Thanks, > -Ngie Done. I generally omitted the --verbose Metadata output. For a few there = was a large block of Standard output or Standard error text that I = omitted. I was not sure of the intent but I put all the lib/msun "broken" items = in one submittal, for example. Similarly for each of the other "broken" = components. Similarly for lib/msun "failed" items (a separate submittal). Similarly = for each of the other "failed" components. I noted explicitly in each submittal that I'd used -mcpu=3Dcortex-a7 in = my builds. But in more detail: A) buildworld and buildkernel had -march=3Darmv7-a -mcpu=3Dcortex-a7 = both listed B) ports builds (such as kyua itself) had -mcpu=3Dcortex-a7 (but not = -march=3Darmv7-a) This is because for ports I use options that do not complain for either = clang 3.8.0 or for fairly modern gcc and gcc does complain about = specifying both -mcpu=3Darmv7-a and -mcpu=3Dcortex-a7. Even the = "armv7-a" notation is from gcc rejecting armv7a but both clang and gcc = accepting armv7-a notation. (As I remember gcc uses -march=3Darmv7-a where it conflicts with = -mcpu=3Dcortex-a7 when both are listed but gcc does warn about conflict = despite having a resolution rule.) Other than the 11.0 -r302180 being more recent the "context details" in = https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061831.html still apply. I did not repeat that information in the submittals but at = least the src.conf and the like are available for reference. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sat Jun 25 11:18:04 2016 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 F36C0B80C70 for ; Sat, 25 Jun 2016 11:18:04 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 B3A2D1761; Sat, 25 Jun 2016 11:18:04 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bGlb2-002X2m-0k>; Sat, 25 Jun 2016 13:17:56 +0200 Received: from x5ce13214.dyn.telefonica.de ([92.225.50.20] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bGlb1-001NJU-MO>; Sat, 25 Jun 2016 13:17:55 +0200 Date: Sat, 25 Jun 2016 13:18:06 +0200 From: "O. Hartmann" To: Konstantin Belousov Cc: Brooks Davis , freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160625131806.14fa4799.ohartman@zedat.fu-berlin.de> In-Reply-To: <20160625070238.GG38613@kib.kiev.ua> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> <330789230754140e38fb527973e23405@ultimatedns.net> <20160624225034.GC20770@spindle.one-eyed-alien.net> <20160625070238.GG38613@kib.kiev.ua> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/YxFvnhQVDRpMlfk.y.YK6UX"; protocol="application/pgp-signature" X-Originating-IP: 92.225.50.20 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 11:18:05 -0000 --Sig_/YxFvnhQVDRpMlfk.y.YK6UX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 25 Jun 2016 10:02:38 +0300 Konstantin Belousov schrieb: > On Fri, Jun 24, 2016 at 10:50:34PM +0000, Brooks Davis wrote: > > pipe(2) had an unnecessarily odd calling convention (ignoring the > > argument the user thought they were passing and returning the two file > > descriptors via the two return registers). This required machine > > dependent assembly for every target and special handling in tracing > > tools (ktrace, dtrace, etc). On 64-bit platforms, pipe(2)'s > > implementation is the only reason the two-register return model needs to > > exist at all (on 32-bit platforms it allows off_t to be returned from > > lseek). =20 > getpid() is another instance. > _______________________________________________ > 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" That all is a nice explanation, but how to recover from a broken system, on= which the order of installation wasn't performed the right way? --Sig_/YxFvnhQVDRpMlfk.y.YK6UX Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXbmhvAAoJEOgBcD7A/5N8epUH/3j/Rzl8uMsFgdLacDRVW+N8 0xXpsmEPZXTKErtauqrKfPuAbTMwtZuC8PEEhJf+t0yviaCpJ5pqrpnJY5+VeJl5 zbtSxlWf2fvBJFsYXG1VahxrnUTsnJCDfq/JFIwht8/RfGN5JbKN2NQElK7L3RC3 PP4hm4qhBCUbhefdeQaAAtWxf8mRcI1AMgiBUHw1iXhD6f28xqPEJCyGE26v9bBi 2kv31H2eHdUAdR9uHGx82TdcwQv/6EJpUFRi5P9rYgI6+ZHRwS14BhLEPFAXYWRZ FlndJWBQqp4KRcJKNW/tNbESaWMV5Chi8HA7O7wcbsH73/kH/wVbmDk08+mZebw= =Mizc -----END PGP SIGNATURE----- --Sig_/YxFvnhQVDRpMlfk.y.YK6UX-- From owner-freebsd-current@freebsd.org Sat Jun 25 08:48:55 2016 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 9C4DEB73249 for ; Sat, 25 Jun 2016 08:48:55 +0000 (UTC) (envelope-from rrs@netflix.com) 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 79E461D68 for ; Sat, 25 Jun 2016 08:48:55 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 759A2B73246; Sat, 25 Jun 2016 08:48:55 +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 72E40B73245 for ; Sat, 25 Jun 2016 08:48:55 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c: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 2AB991D61 for ; Sat, 25 Jun 2016 08:48:55 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by mail-vk0-x22a.google.com with SMTP id d185so178523861vkg.0 for ; Sat, 25 Jun 2016 01:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tpBM99m1BKG3QPoXTcRmsr7jEgv/ta+6xDZKRAKia1Y=; b=bCEpaLnVowICR96R1x9BJjRu7d6E5Byl+h3uxJYmaq7ApBRu3iQkeTJQ6ZtxQq1isW 6Fyj4Pa8fBkRdeE8goX1wGSm3N0kT+LPitT9RkwPGiqq0PtsbH417Hng2JTFmlMT2qQ/ 49OWYk7EJXyEVgvpsHz63CIfaPGy4lRC8tR2A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tpBM99m1BKG3QPoXTcRmsr7jEgv/ta+6xDZKRAKia1Y=; b=T4wam5uCMyssqRq9GJdGWxmqaXXy1zKWU9YPYJ3iCB+zl0pcy+xb8qJH1i6F+xJvcx Mi0X14KVf17CLkUHYFzN7sJyeisC6yT3glUeWBIiZ4IgTsZrF46mLPvVDaAPfGQhVfgC 5uF5Hupd+EONgnisLMPEaA1GsTJJrAoiQWOdrCto+yL+Nuoaop8pA0qnvPRctEYHIdgs JMCvfCyEBY32y8YLwIDjw0Yh9SluRdWxtTnyois4GrEVA3Ol+efL/uKPK+m8n7LdBir9 wPa69H3ZWIAyfV47QAH8hjyBeaEfxs6b71XJAARJvruf1lpIevompEukNzpwtP06aISp 6OYQ== X-Gm-Message-State: ALyK8tLz6t6gu/F2ENN+b0pUeuzU3CKdrjkc9useJ4t1k74pXrM6qtFo89lHjceXjIjmdaEz X-Received: by 10.176.64.7 with SMTP id h7mr4365555uad.153.1466844534204; Sat, 25 Jun 2016 01:48:54 -0700 (PDT) Received: from [100.127.86.242] ([69.53.246.16]) by smtp.gmail.com with ESMTPSA id g4sm2820025vkb.3.2016.06.25.01.48.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 Jun 2016 01:48:53 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: panic with tcp timers From: Randall Stewart In-Reply-To: <74bb31b7-a9f5-3d0c-eea0-681872e6f09b@freebsd.org> Date: Sat, 25 Jun 2016 04:48:51 -0400 Cc: Gleb Smirnoff , Randall Ray Stewart , hselasky@FreeBSD.org, net@FreeBSD.org, current@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <18D94615-810E-4E79-A889-4B0CC70F9E45@netflix.com> References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> <20160620095822.GJ1076@FreeBSD.org> <74bb31b7-a9f5-3d0c-eea0-681872e6f09b@freebsd.org> To: Julien Charbon X-Mailer: Apple Mail (2.3124) X-Mailman-Approved-At: Sat, 25 Jun 2016 11:19:45 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 08:48:55 -0000 So All of our timers in TCP do something like --------------------- INFO-LOCK INP_WLOCK if (inp needs to be dropped) { drop-it } do other work UNLOCK-INP UNLOCK-INFO ------------------ And generally the path =93inp needs to be dropped=94 is rarely taken. So why don=92t we change the procedure to something like: INP_WLOCK if (inp needs to be dropped) { inp_ref() INP_WUNLOCK() INFO_LOCK() INP_WLOCK() if (inp_release_ref) { /* victory its dead */ INFO_UNLOCK return } do-the-drop } This way we would only go grab the INFO lock in those rarer cases when we *do* actually want to kill the tcb and at the same time it would make the current callout system work correctly.. which as many have pointed out would be much better if we could just let the lock be gotten by the callout system. Hmm maybe with this scheme we could even do that... R > On Jun 20, 2016, at 1:45 PM, Julien Charbon wrote: >=20 >=20 > Hi, >=20 > On 6/20/16 11:58 AM, Gleb Smirnoff wrote: >> On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote: >> J> > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: >> J> > J> > Comparing stable/10 and head, I see two changes that could >> J> > J> > affect that: >> J> > J> >=20 >> J> > J> > - callout_async_drain >> J> > J> > - switch to READ lock for inp info in tcp timers >> J> > J> >=20 >> J> > J> > That's why you are in To, Julien and Hans :) >> J> > J> >=20 >> J> > J> > We continue investigating, and I will keep you updated. >> J> > J> > However, any help is welcome. I can share cores. >> J> >=20 >> J> > Now, spending some time with cores and adding a bunch of >> J> > extra CTRs, I have a sequence of events that lead to the >> J> > panic. In short, the bug is in the callout system. It seems >> J> > to be not relevant to the callout_async_drain, at least for >> J> > now. The transition to READ lock unmasked the problem, that's >> J> > why NetflixBSD 10 doesn't panic. >> J> >=20 >> J> > The panic requires heavy contention on the TCP info lock. >> J> >=20 >> J> > [CPU 1] the callout fires, tcp_timer_keep entered >> J> > [CPU 1] blocks on INP_INFO_RLOCK(&V_tcbinfo); >> J> > [CPU 2] schedules the callout >> J> > [CPU 2] tcp_discardcb called >> J> > [CPU 2] callout successfully canceled >> J> > [CPU 2] tcpcb freed >> J> > [CPU 1] unblocks... panic >> J> >=20 >> J> > When the lock was WLOCK, all contenders were resumed in a >> J> > sequence they came to the lock. Now, that they are readers, >> J> > once the lock is released, readers are resumed in a "random" >> J> > order, and this allows tcp_discardcb to go before the old >> J> > running callout, and this unmasks the panic. >> J>=20 >> J> Highly interesting. I should be able to reproduce that (will be = useful >> J> for testing the corresponding fix). >> J>=20 >> J> Fix proposal: If callout_async_drain() returns 0 (fail) (instead = of 1 >> J> (success) here) when the callout cancellation is a success _but_ = the >> J> callout is current running, that should fix it. >> J>=20 >> J> For the history: It comes back to my old callout question: >> J>=20 >> J> Does _callout_stop_safe() is allowed to return 1 (success) even = if the >> J> callout is still currently running; a.k.a. it is not because you >> J> successfully cancelled a callout that the callout is not currently = running. >> J>=20 >> J> We did propose a patch to make _callout_stop_safe() returns 0 = (fail) >> J> when the callout is currently running: >> J>=20 >> J> callout_stop() should return 0 when the callout is currently being >> J> serviced and indeed unstoppable >> J> = https://reviews.freebsd.org/differential/changeset/?ref=3D62513&whitespace= =3Dignore-most >> J>=20 >> J> But this change impacted too many old code paths and was = interesting >> J> only for TCP timers and thus was abandoned. >>=20 >> The fix I am working on now is doing exactly that. callout_reset must >> return 0 if the callout is currently running. >>=20 >> What are the old paths impacted? >=20 > Actually all the paths that check the callout_stop() return value AND > call both callout_reset() and callout_stop() AND use mpsafe callout(). > And for each path, we would have to check our patch was ok (or not). >=20 > Thus, if you only do the change in callout_async_drain() context, you > don't impact the "old" callout_stop() behavior and get the desired > behavior for the TCP timers. Might be a good trade-off... >=20 > My 2 cents. >=20 > -- > Julien -------- Randall Stewart rrs@netflix.com 803-317-4952 From owner-freebsd-current@freebsd.org Sat Jun 25 11:35:51 2016 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 00689B803D1 for ; Sat, 25 Jun 2016 11:35:51 +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 72CA42738; Sat, 25 Jun 2016 11:35:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5PBZigW029216 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 25 Jun 2016 14:35:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5PBZigW029216 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5PBZiJn029214; Sat, 25 Jun 2016 14:35:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 25 Jun 2016 14:35:44 +0300 From: Konstantin Belousov To: "O. Hartmann" Cc: Brooks Davis , freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160625113544.GS38613@kib.kiev.ua> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> <330789230754140e38fb527973e23405@ultimatedns.net> <20160624225034.GC20770@spindle.one-eyed-alien.net> <20160625070238.GG38613@kib.kiev.ua> <20160625131806.14fa4799.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160625131806.14fa4799.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 25 Jun 2016 11:35:51 -0000 On Sat, Jun 25, 2016 at 01:18:06PM +0200, O. Hartmann wrote: > Am Sat, 25 Jun 2016 10:02:38 +0300 > Konstantin Belousov schrieb: > > > On Fri, Jun 24, 2016 at 10:50:34PM +0000, Brooks Davis wrote: > > > pipe(2) had an unnecessarily odd calling convention (ignoring the > > > argument the user thought they were passing and returning the two file > > > descriptors via the two return registers). This required machine > > > dependent assembly for every target and special handling in tracing > > > tools (ktrace, dtrace, etc). On 64-bit platforms, pipe(2)'s > > > implementation is the only reason the two-register return model needs to > > > exist at all (on 32-bit platforms it allows off_t to be returned from > > > lseek). > > getpid() is another instance. > > _______________________________________________ > > 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" > > That all is a nice explanation, but how to recover from a broken system, on which the > order of installation wasn't performed the right way? Copy the libc.so.7 binary from the build area to /lib manually, e.g. using rescue shell. From owner-freebsd-current@freebsd.org Sat Jun 25 13:11:02 2016 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 6C846B8118E for ; Sat, 25 Jun 2016 13:11:02 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1151AE6 for ; Sat, 25 Jun 2016 13:11:01 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 910CA1604A; Sat, 25 Jun 2016 15:02:07 +0200 (CEST) Date: Sat, 25 Jun 2016 15:02:11 +0200 From: Steffen Nurpmeso To: freebsd-current@freebsd.org Subject: Re: svn commit: r302185 - head/release/doc/en_US.ISO8859-1/relnotes Message-ID: <20160625130211.om_RIztzB%steffen@sdaoden.eu> References: <201606242342.u5ONgXTu041633@repo.freebsd.org> In-Reply-To: <201606242342.u5ONgXTu041633@repo.freebsd.org> Mail-Followup-To: freebsd-current@freebsd.org User-Agent: s-nail v14.8.8-271-g90e1e10 OpenPGP: id=95F382CE; url=https://www.sdaoden.eu/downloads/steffen.asc X-BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 13:11:02 -0000 |Author: gjb |Date: Fri Jun 24 23:42:33 2016 Sigh. |Log: | Update the release notes following r302182. | A selection of system daemons, including: | fingerd, | ftpd, |- rlogind, |- rshd, and |- sshd have been modified to support |+ rlogind, and |+ rshd have been modified to support | sending notifications to the blacklistd | daemon. Allow me to continue hoping nonetheless. In this great future, you can't forget your past. --steffen From owner-freebsd-current@freebsd.org Sat Jun 25 13:21:55 2016 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 2F390B812B1 for ; Sat, 25 Jun 2016 13:21:55 +0000 (UTC) (envelope-from gjb@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 1317D1FAF; Sat, 25 Jun 2016 13:21:55 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id C69E71184; Sat, 25 Jun 2016 13:21:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 25 Jun 2016 13:21:53 +0000 From: Glen Barber To: Steffen Nurpmeso Cc: freebsd-current@freebsd.org Subject: Re: svn commit: r302185 - head/release/doc/en_US.ISO8859-1/relnotes Message-ID: <20160625132153.GP19747@FreeBSD.org> References: <201606242342.u5ONgXTu041633@repo.freebsd.org> <20160625130211.om_RIztzB%steffen@sdaoden.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WOTjKnJ88wpJKlWH" Content-Disposition: inline In-Reply-To: <20160625130211.om_RIztzB%steffen@sdaoden.eu> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 13:21:55 -0000 --WOTjKnJ88wpJKlWH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 25, 2016 at 03:02:11PM +0200, Steffen Nurpmeso wrote: > |Author: gjb > |Date: Fri Jun 24 23:42:33 2016 >=20 > Sigh. >=20 > |Log: > | Update the release notes following r302182. >=20 > | A selection of system daemons, including: > | fingerd, > | ftpd, > |- rlogind, > |- rshd, and > |- sshd have been modified to support > |+ rlogind, and > |+ rshd have been modified to support > | sending notifications to the blacklistd > | daemon. >=20 > Allow me to continue hoping nonetheless. > In this great future, you can't forget your past. >=20 I hope the issues can be resolved before 11.0-RELEASE. I personally look forward to this change, but the revert was necessary. Glen --WOTjKnJ88wpJKlWH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXboVxAAoJEAMUWKVHj+KTC0EP/As9yCmUgMaw7CB1YKTPUDeB DoCXwIaw2yZucMa0aLfs8OCX6PFad28TmYV99F5GOwhjW03PdWuQd76fr7N+amoS 33tKWg0c3Ik8uS972C51T3Q/Zp/ho6r+ifYv1Ch6leRIdZYg2E67sGeXAlDwx8SG WzJVtUAG+el8ShmGOE1WWusiRrseUF+nqydoIJmnoXrRDC8uqItHlU+T1yE7LmYh 33dW/NkywWZB2yk9j3JTgqmFez2AYcseznUBRvZj/n1FqDsNoJwORKgRgJS+0JpK 6fgZIXXa2eNV5Xkpl06lBVt3r+WxG9qMLNeWXV3D0QJs47zg/pOSZmi0GUNv///D 3S5IzeLAiGIi0SZJOV4SvRb9hM3TZRtgI8+FGJw3QWRDypC6/rjS/zWTXyXNgsup 4KL941Oo5VSNoO8M9kvS5FqVpi1+WGRzwoLGDt8/SnmdhZSgKpr/RUcAiNqEfIpe shldhvG5VOBgoBloLJOMip5obQhB7BLchPpx81ZdtmcjmY+SQwxvPDTpR7eFgcOM efnm/giEmxdB+2sQptaWzzpnqAupAVQOfEtRkzc+gSIPf59Iw5RO1d3su49RduF7 Kocuh8zLVZcHsaf6smvDG1htCshLaEZ/NeyX4JsBzurk+BbSd6hnfEC/dGaA+7a0 C2bEWt7Op/Q18N5/6Cyy =mpXp -----END PGP SIGNATURE----- --WOTjKnJ88wpJKlWH-- From owner-freebsd-current@freebsd.org Sat Jun 25 14:04:34 2016 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 9A492B81CE7 for ; Sat, 25 Jun 2016 14:04:34 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (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 62D5F1CF0 for ; Sat, 25 Jun 2016 14:04:34 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from mfilter24-d.gandi.net (mfilter24-d.gandi.net [217.70.178.152]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 6E9FD17209D; Sat, 25 Jun 2016 16:04:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter24-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter24-d.gandi.net (mfilter24-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 7_I3SmEptIfB; Sat, 25 Jun 2016 16:04:30 +0200 (CEST) X-Originating-IP: 90.231.139.91 Received: from [192.168.1.249] (h91n1-gl-a-a31.ias.bredband.telia.com [90.231.139.91]) (Authenticated sender: daniel.engberg@pyret.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 95718172095; Sat, 25 Jun 2016 16:04:29 +0200 (CEST) Subject: Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4 To: Guy Yur , Konstantin Belousov References: <20160625084939.GI38613@kib.kiev.ua> <20160625092040.GL38613@kib.kiev.ua> Cc: freebsd-current From: Daniel Engberg Message-ID: <1a0a1d8e-f325-1ae7-3d85-7013726305a5@pyret.net> Date: Sat, 25 Jun 2016 16:03:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 14:04:34 -0000 On 2016-06-25 12:16, Guy Yur wrote: > Hi, > > On Sat, Jun 25, 2016 at 12:20 PM, Konstantin Belousov > wrote: >> On Sat, Jun 25, 2016 at 11:49:39AM +0300, Konstantin Belousov wrote: >>> On Sat, Jun 25, 2016 at 01:03:13AM +0300, Guy Yur wrote: >>>> libtdb.so.1`tdb_runtime_check_for_robust_mutexes + 1475 at mutex.c:957 >>>> ... >>> >>> The pointer to tdb_runtime_check_for_robust_mutexes() appeared to be >>> most useful, thanks. >>> >>> The two patches below should fix samba use of robustness. First, >>> kernel erronously reset robust lists locations on fork. Second, the >>> pthread_mutex_trylock() for owned errorcheck mutex must return EDEADLK >>> and not EBUSY. Try that. >> >> Correction, there was a reason why I initially put the rb list pointers >> into zeroed region. It still needs to be zeroed on new thread creation. >> Updated patch. >> > > With the patch to the 3 files applied, smbd, nmbd and smbclient > no longer crash on my machine. > > Tested with r302191+patch. > > Thanks, > Guy > Hi, Sorry for being late to the party :/ I've tested your patch (the latest one) and it also seems to do the trick. Thanks! FreeBSD 11.0-ALPHA5 (AMD64) - Samba 4.4 Best regards, Daniel From owner-freebsd-current@freebsd.org Sat Jun 25 14:29:51 2016 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 F2F9CB80020 for ; Sat, 25 Jun 2016 14:29:51 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CBB59135F for ; Sat, 25 Jun 2016 14:29:51 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id Goahb7WWiN9d0GoaibVw7U; Sat, 25 Jun 2016 08:29:50 -0600 X-Authority-Analysis: v=2.2 cv=QZUkhYTv c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=pD_ry4oyNxEA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=FsueQZ-Ksh1tl_JqZ6cA:9 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id C26C713755 for ; Sat, 25 Jun 2016 07:29:47 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id u5PETkfa078605 for ; Sat, 25 Jun 2016 07:29:47 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201606251429.u5PETkfa078605@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-current@freebsd.org Subject: Cross-build Brokenness Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Jun 2016 07:29:46 -0700 X-CMAE-Envelope: MS4wfBFN2RgxnT+bRPzPUrCJrqqr0NCmDc1iADxduEBD5YNOFdVyQK2d52ssnRDyyRNtAFW3QJ1uL5vxYqHvglYfBOhyldxNi1Lbb8t0xFtL4pZiL9PI7PMl dpakioXp0lVNbFOvCpgIUwi443QjzIdTPw/zKIyXjKEQq8oUFY144hPoELJUNufW9XnAWLbvHR7FYA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 14:29:52 -0000 It appears that the i386 cross-build is broken as follows. Builds on native amd64 are OK. --- main.o --- cc -target i386-unknown-freebsd11.0 --sysroot=/usr/obj/i386.i386/opt/src/svn -current/tmp -B/usr/obj/i386.i386/opt/src/svn-current/tmp/usr/bin -O2 -pipe -pipe -DRDUMP -g -MD -MF.depend.main.o -MTmain.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /opt/src/svn-current/sbin/dump/main.c -o main.o --- all_subdir_lib --- /usr/obj/i386.i386/opt/src/svn-current/tmp/usr/bin/ld: /usr/bin/../lib/clang/3.8.0/lib/freebsd/libclang_rt.ubsan_standalone-i386.a: No such file: No such file or directory cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [h_raw.full] Error code 1 make[7]: stopped in /opt/src/svn-current/lib/libc/tests/ssp 1 error make[7]: stopped in /opt/src/svn-current/lib/libc/tests/ssp *** [h_raw] Error code 2 make[6]: stopped in /opt/src/svn-current/lib/libc/tests/ssp 1 error make[6]: stopped in /opt/src/svn-current/lib/libc/tests/ssp --- all_subdir_kerberos5 --- A failure has been detected in another branch of the parallel make make[5]: stopped in /opt/src/svn-current/kerberos5/lib/libheimbase --- all_subdir_lib --- *** [all_subdir_lib/libc/tests/ssp] Error code 2 make[5]: stopped in /opt/src/svn-current/lib/libc/tests 1 error make[5]: stopped in /opt/src/svn-current/lib/libc/tests --- all_subdir_kerberos5 --- *** [all] Error code 2 make[4]: stopped in /opt/src/svn-current/kerberos5/lib 1 error make[4]: stopped in /opt/src/svn-current/kerberos5/lib --- all_subdir_lib --- *** [all] Error code 2 make[4]: stopped in /opt/src/svn-current/lib/libc 1 error make[4]: stopped in /opt/src/svn-current/lib/libc --- all_subdir_kerberos5 --- *** [all_subdir_kerberos5/lib] Error code 2 make[3]: stopped in /opt/src/svn-current/kerberos5 1 error make[3]: stopped in /opt/src/svn-current/kerberos5 *** [all_subdir_kerberos5] Error code 2 make[2]: stopped in /opt/src/svn-current --- all_subdir_lib --- *** [all_subdir_lib/libc] Error code 2 make[3]: stopped in /opt/src/svn-current/lib 1 error make[3]: stopped in /opt/src/svn-current/lib *** [all_subdir_lib] Error code 2 make[2]: stopped in /opt/src/svn-current --- all_subdir_rescue --- A failure has been detected in another branch of the parallel make make[6]: stopped in /opt/src/svn-current/bin/csh *** [csh_make] Error code 2 make[5]: stopped in /export/obj/i386.i386/opt/src/svn-current/rescue/rescue 1 error make[5]: stopped in /export/obj/i386.i386/opt/src/svn-current/rescue/rescue *** [objs] Error code 2 make[4]: stopped in /opt/src/svn-current/rescue/rescue 1 error make[4]: stopped in /opt/src/svn-current/rescue/rescue *** [all] Error code 2 make[3]: stopped in /opt/src/svn-current/rescue 1 error make[3]: stopped in /opt/src/svn-current/rescue *** [all_subdir_rescue] Error code 2 make[2]: stopped in /opt/src/svn-current --- all_subdir_sbin --- A failure has been detected in another branch of the parallel make make[4]: stopped in /opt/src/svn-current/sbin/dump *** [all_subdir_sbin/dump] Error code 2 make[3]: stopped in /opt/src/svn-current/sbin 1 error make[3]: stopped in /opt/src/svn-current/sbin *** [all_subdir_sbin] Error code 2 make[2]: stopped in /opt/src/svn-current 4 errors make[2]: stopped in /opt/src/svn-current *** [everything] Error code 2 make[1]: stopped in /opt/src/svn-current 1 error make[1]: stopped in /opt/src/svn-current *** [buildworld] Error code 2 make: stopped in /opt/src/svn-current 1 error make: stopped in /opt/src/svn-current slippy# The following patch fixes my i386 cross-builds on amd64 native architecture. Index: lib/libc/tests/ssp/Makefile =================================================================== --- lib/libc/tests/ssp/Makefile (revision 302191) +++ lib/libc/tests/ssp/Makefile (working copy) @@ -1,5 +1,6 @@ # $FreeBSD$ +.include .include NO_WERROR= @@ -34,10 +35,12 @@ .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64" .if ${COMPILER_TYPE} == "clang" && ${MK_TOOLCHAIN} == "yes" .if ${COMPILER_VERSION} < 30500 || 30700 <= ${COMPILER_VERSION} +.if ${MACHINE_CPUARCH} == ${_HOST_ARCH} PROGS+= h_raw .endif .endif .endif +.endif PROGS+= h_read PROGS+= h_readlink PROGS+= h_snprintf -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Sat Jun 25 14:55:48 2016 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 D755AB80B69 for ; Sat, 25 Jun 2016 14:55:48 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by mx1.freebsd.org (Postfix) with ESMTP id A287327BA; Sat, 25 Jun 2016 14:55:48 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id A81951604A; Sat, 25 Jun 2016 16:55:47 +0200 (CEST) Date: Sat, 25 Jun 2016 16:55:45 +0200 From: Steffen Nurpmeso To: Glen Barber Cc: freebsd-current@freebsd.org Subject: Re: svn commit: r302185 - head/release/doc/en_US.ISO8859-1/relnotes Message-ID: <20160625145545.-s35vVVMV%steffen@sdaoden.eu> References: <201606242342.u5ONgXTu041633@repo.freebsd.org> <20160625130211.om_RIztzB%steffen@sdaoden.eu> <20160625132153.GP19747@FreeBSD.org> In-Reply-To: <20160625132153.GP19747@FreeBSD.org> Mail-Followup-To: Steffen Nurpmeso , Glen Barber , freebsd-current@freebsd.org User-Agent: s-nail v14.8.8-271-g90e1e10 OpenPGP: id=95F382CE; url=https://www.sdaoden.eu/downloads/steffen.asc X-BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. 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.22 Precedence: 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, 25 Jun 2016 14:55:48 -0000 Glen Barber wrote: |On Sat, Jun 25, 2016 at 03:02:11PM +0200, Steffen Nurpmeso wrote: |>| A selection of system daemons, including: |>| fingerd, |>| ftpd, |>|- rlogind, |>|- rshd, and |>|- sshd have been modified to support |>|+ rlogind, and |>|+ rshd have been modified to support |>| sending notifications to the blacklistd |>| daemon. |>=20 |> Allow me to continue hoping nonetheless. |> In this great future, you can't forget your past. | |I hope the issues can be resolved before 11.0-RELEASE. I personally |look forward to this change, but the revert was necessary. It is very likely that you and D.E. Sm=C3=B8rgrav are right, and then 11.0 is to be expected for September. In fact i was only looking at this from a very narrow user perspective and, in addition, never liked that log files have to be parsed to recollect states that were known by the generating daemon. It can only be that commercial software does this better, more integrated, but i don't know. So once the blacklistd idea came up, which was, if i recall correctly, shortly after DragonFly BSD introduced their own logfile analyzer, didn't they?, i was kind of thrilled, because isn't that the first time that the right thing is done to face that problem? In my opinion it would be great if all servers that listen to the outside world would gain the necessary hooks for "bad command", "bad login", "good login", possibly more. This would create an integrated, synchronous mesh of firewall and servers, so talking about clowds.., i am looking forward to this. If rules would become more sophisticated, e.g., "user IP tried to post messages with more than X KB the Y time", and that could be taken into account. And then it also requires less CPU time and thus energy, then having a logfile analyzer running in addition. Thank you. Have a nice weekend. --steffen From owner-freebsd-current@freebsd.org Sat Jun 25 15:09:05 2016 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 24D06B8100F for ; Sat, 25 Jun 2016 15:09:05 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 DADCF2E4B; Sat, 25 Jun 2016 15:09:04 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bGpCg-003CWH-Gy>; Sat, 25 Jun 2016 17:09:02 +0200 Received: from x55b3a5f8.dyn.telefonica.de ([85.179.165.248] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bGpCg-001dh1-6f>; Sat, 25 Jun 2016 17:09:02 +0200 Date: Sat, 25 Jun 2016 17:09:14 +0200 From: "O. Hartmann" To: Brooks Davis Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160625170914.7eb3d260.ohartman@zedat.fu-berlin.de> In-Reply-To: <20160624155111.GB20770@spindle.one-eyed-alien.net> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/dJZ4RbsmFPHT0fohH8tIVXc"; protocol="application/pgp-signature" X-Originating-IP: 85.179.165.248 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 15:09:05 -0000 --Sig_/dJZ4RbsmFPHT0fohH8tIVXc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 24 Jun 2016 15:51:11 +0000 Brooks Davis schrieb: > On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote: > > Am Thu, 23 Jun 2016 21:07:51 +0000 > > Brooks Davis schrieb: > > =20 > > > Kernel config minimalists and those running aarch64 and riscv systems= will > > > want to head this UPDATING message. > > >=20 > > > In practice, if you're fairly up to date, doing installworld before > > > installkernel will also work (I've tested that case from ALPHA4), but= is > > > always somewhat risky. > > >=20 > > > -- Brooks > > >=20 > > > ----- Forwarded message from Brooks Davis ----- > > >=20 > > > Date: Thu, 23 Jun 2016 21:02:05 +0000 (UTC) > > > From: Brooks Davis > > > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > > > svn-src-head@freebsd.org > > > Subject: svn commit: r302152 - head > > >=20 > > > Author: brooks > > > Date: Thu Jun 23 21:02:05 2016 > > > New Revision: 302152 > > > URL: https://svnweb.freebsd.org/changeset/base/302152 > > >=20 > > > Log: > > > Add an UPDATING entry for the pipe() -> pipe2() transition. > > > =20 > > > Approved by: re (gjb) > > > Sponsored by: DARPA, AFRL > > >=20 > > > Modified: > > > head/UPDATING > > >=20 > > > Modified: head/UPDATING > > > =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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > --- head/UPDATING Thu Jun 23 20:59:13 2016 (r302151) > > > +++ head/UPDATING Thu Jun 23 21:02:05 2016 (r302152) > > > @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11 > > > disable the most expensive debugging functionality run > > > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > > > =20 > > > +20160622: > > > + The the libc stub for the pipe(2) system call has been replaced with > > > + a wrapper which calls the pipe2(2) system call and the pipe(2) is n= ow > > > + only implemented by the kernels which include "options > > > + FREEBSD10_COMPAT" in their config file (this is the default). > > > + Users should ensure that this option is enabled in their kernel > > > + or upgrade userspace to r302092 before upgrading their kernel. > > > + > > > 20160527: > > > CAM will now strip leading spaces from SCSI disks' serial numbers. > > > This will effect users who create UFS filesystems on SCSI disks usi= ng > > >=20 > > >=20 > > > ----- End forwarded message ----- =20 > >=20 > > Is this showing up, when one doesn't have the expected COMPAT_FREEBSD10= in kernel and > > updated kernel __before___ world?: =20 >=20 > You must include COMPAT_FREEBSD10 or have a new userspace. Otherwise > things like your shell are unlikely to work. How to fix this probblem? I have no other machine available to build a gene= ric system/kernel. How to fix this mess with a running system, but with messages like below sh= owing up when try building a new world? The warning came, as usual, too late! The source and changes were out. It s= eems that I'm not the only one with problems like that, so please provide some instructio= ns to salvage the situation. Thanks in advance, oh >=20 > -- Brooks >=20 > >=20 > > most recent CURRENT (FreeBSD 11.0-ALPHA4 #41 r302149: Thu Jun 23 21:58:= 25 CEST 2016 > > amd64, custom kernel) dies when trying to > >=20 > > make buildworld=20 > >=20 > > or > >=20 > > make buildkernel/kernel > >=20 > > with the message shown below: > >=20 > > root@localhost: [src] make buildkernel > > *** Signal 12 > >=20 > > Stop. > > make: stopped in /usr/src > > .ERROR_TARGET=3D'buildkernel' > > .ERROR_META_FILE=3D'' > > .MAKE.LEVEL=3D'0' > > MAKEFILE=3D'' > > .MAKE.MODE=3D'normal' > > .CURDIR=3D'/usr/src' > > .MAKE=3D'make' > > .OBJDIR=3D'/usr/obj/usr/src' > > .TARGETS=3D'buildkernel' > > DESTDIR=3D'' > > LD_LIBRARY_PATH=3D'' > > MACHINE=3D'amd64' > > MACHINE_ARCH=3D'amd64' > > MAKEOBJDIRPREFIX=3D'/usr/obj' > > MAKESYSPATH=3D'/usr/src/share/mk' > > MAKE_VERSION=3D'20160606' > > PATH=3D'/sbin:/bin:/usr/sbin:/usr/bin' > > SRCTOP=3D'/usr/src' > > OBJTOP=3D'/usr/obj/usr/src' > >=20 > > Regards, > >=20 > > oh =20 >=20 >=20 --Sig_/dJZ4RbsmFPHT0fohH8tIVXc Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXbp6aAAoJEOgBcD7A/5N8aWAH/jr2S0/DKSk6Qt3e5Xa49xSj fbEr3t9/2C2TiEmpGpiwza16rNTAzuAtO2lQmNEw2hkpx6LZMSL7OZT5ii2xp58B SLb91kJx8VQaToQE+asrtv+FvfYjdi2rKmr6/WKRDzW8OlNFSowZSw3Q9GuKxKKC IZbFnmCvD90y3Ber+KmeKGu3MW3mkIiV1938N0oMSH0lmOsMqrIaYaxUhFnwPbiw YYaNNhNpu9fifGMGAA0/is8H4EHhm7CJxrVlWXALSBx5Xk9qotA2tG/himAIR2vC aSAHFEw5Ae/Lr+J9jakLdnit0GeHfypnXIqx9VTvXI1h/1mh3dOVUZDpEAOrjLc= =ggXF -----END PGP SIGNATURE----- --Sig_/dJZ4RbsmFPHT0fohH8tIVXc-- From owner-freebsd-current@freebsd.org Sat Jun 25 15:17:00 2016 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 1AAE7B812B3 for ; Sat, 25 Jun 2016 15:17:00 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 CDF9F14B0 for ; Sat, 25 Jun 2016 15:16:59 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bGpKL-003Dkx-Tz>; Sat, 25 Jun 2016 17:16:57 +0200 Received: from x55b3a5f8.dyn.telefonica.de ([85.179.165.248] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bGpKL-001eJv-J0>; Sat, 25 Jun 2016 17:16:57 +0200 Date: Sat, 25 Jun 2016 17:17:14 +0200 From: "O. Hartmann" To: freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160625171714.7e318044.ohartman@zedat.fu-berlin.de> In-Reply-To: <20160625113544.GS38613@kib.kiev.ua> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> <330789230754140e38fb527973e23405@ultimatedns.net> <20160624225034.GC20770@spindle.one-eyed-alien.net> <20160625070238.GG38613@kib.kiev.ua> <20160625131806.14fa4799.ohartman@zedat.fu-berlin.de> <20160625113544.GS38613@kib.kiev.ua> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/AANzYB_0_T849rqDT.tGO4G"; protocol="application/pgp-signature" X-Originating-IP: 85.179.165.248 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 15:17:00 -0000 --Sig_/AANzYB_0_T849rqDT.tGO4G Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 25 Jun 2016 14:35:44 +0300 Konstantin Belousov schrieb: > On Sat, Jun 25, 2016 at 01:18:06PM +0200, O. Hartmann wrote: > > Am Sat, 25 Jun 2016 10:02:38 +0300 > > Konstantin Belousov schrieb: > > =20 > > > On Fri, Jun 24, 2016 at 10:50:34PM +0000, Brooks Davis wrote: =20 > > > > pipe(2) had an unnecessarily odd calling convention (ignoring the > > > > argument the user thought they were passing and returning the two f= ile > > > > descriptors via the two return registers). This required machine > > > > dependent assembly for every target and special handling in tracing > > > > tools (ktrace, dtrace, etc). On 64-bit platforms, pipe(2)'s > > > > implementation is the only reason the two-register return model nee= ds to > > > > exist at all (on 32-bit platforms it allows off_t to be returned fr= om > > > > lseek). =20 > > > getpid() is another instance. > > > _______________________________________________ > > > 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" =20 > >=20 > > That all is a nice explanation, but how to recover from a broken system= , on which the > > order of installation wasn't performed the right way? =20 >=20 > Copy the libc.so.7 binary from the build area to /lib manually, e.g. using > rescue shell. > _______________________________________________ > 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" I did so, but there is no effect. Whenever I try to build a kernel/world, I receive this from the shell: root@localhost: [src] make update *** Signal 12 Stop. make: stopped in /usr/src .ERROR_TARGET=3D'update' .ERROR_META_FILE=3D'' .MAKE.LEVEL=3D'0' MAKEFILE=3D'' .MAKE.MODE=3D'normal' .CURDIR=3D'/usr/src' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/usr/src' .TARGETS=3D'update' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20160606' PATH=3D'/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/usr/src' These two machines in question are victims "of the early adopter" - the war= ning came way too late! At work, I did the same update - but I did an installworld prior = to the usual installkernel - and everything seems so far to work, even without COMAPT_FR= EEBSD10 in the kernel. Is there a way to salvage the situation without relying on "customized" thi= rd party kernels?=20 I usually use /bin/csh - so this might be of use. Thank you in advance for help, kind regards, Oliver --Sig_/AANzYB_0_T849rqDT.tGO4G Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXbqB6AAoJEOgBcD7A/5N8azQH/3Lf3ldgGX1dgobLnzgQsorQ sW/Lyb7Ae3WjoFmIwzsAD1JpWBwBNJ/E4DAHIurMDcQh2BjXKvlHzHoMhmYbwko5 eQIUkKCyVCdt0J0bkRilV3SVnToFFXxdSGlweCXvxc9ISd3fIDGvT3rBEbmKGRY8 PsKU8C4/l1epH9eqEue4YMaTEUcggfiIcErVbGLsbhreTnSVFLcqxe7GtYDcwrXF uP9XhrQFheeCd46zJPFgQkgi2ydvPtvetKW0OSZCNxWui3Yyz3b5sf9SylF/nrM+ v+OGjnSweBI8oB4Qg2HpcMKBfjL71Qm/XZbHIB8jOU78YPeGdk0hwLv2N0JegaQ= =oBCy -----END PGP SIGNATURE----- --Sig_/AANzYB_0_T849rqDT.tGO4G-- From owner-freebsd-current@freebsd.org Sat Jun 25 15:26:50 2016 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 C1AFEB815A4 for ; Sat, 25 Jun 2016 15:26:50 +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 528C61CAE for ; Sat, 25 Jun 2016 15:26:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5PFQjqR084207 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 25 Jun 2016 18:26:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5PFQjqR084207 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5PFQj8r084206; Sat, 25 Jun 2016 18:26:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 25 Jun 2016 18:26:45 +0300 From: Konstantin Belousov To: "O. Hartmann" Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160625152645.GB38613@kib.kiev.ua> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> <330789230754140e38fb527973e23405@ultimatedns.net> <20160624225034.GC20770@spindle.one-eyed-alien.net> <20160625070238.GG38613@kib.kiev.ua> <20160625131806.14fa4799.ohartman@zedat.fu-berlin.de> <20160625113544.GS38613@kib.kiev.ua> <20160625171714.7e318044.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160625171714.7e318044.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 25 Jun 2016 15:26:50 -0000 On Sat, Jun 25, 2016 at 05:17:14PM +0200, O. Hartmann wrote: > Am Sat, 25 Jun 2016 14:35:44 +0300 > Konstantin Belousov schrieb: > > > On Sat, Jun 25, 2016 at 01:18:06PM +0200, O. Hartmann wrote: > > > Am Sat, 25 Jun 2016 10:02:38 +0300 > > > Konstantin Belousov schrieb: > > > > > > > On Fri, Jun 24, 2016 at 10:50:34PM +0000, Brooks Davis wrote: > > > > > pipe(2) had an unnecessarily odd calling convention (ignoring the > > > > > argument the user thought they were passing and returning the two file > > > > > descriptors via the two return registers). This required machine > > > > > dependent assembly for every target and special handling in tracing > > > > > tools (ktrace, dtrace, etc). On 64-bit platforms, pipe(2)'s > > > > > implementation is the only reason the two-register return model needs to > > > > > exist at all (on 32-bit platforms it allows off_t to be returned from > > > > > lseek). > > > > getpid() is another instance. > > > > _______________________________________________ > > > > 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" > > > > > > That all is a nice explanation, but how to recover from a broken system, on which the > > > order of installation wasn't performed the right way? > > > > Copy the libc.so.7 binary from the build area to /lib manually, e.g. using > > rescue shell. > > _______________________________________________ > > 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" > > I did so, but there is no effect. > > Whenever I try to build a kernel/world, I receive this from the shell: > > root@localhost: [src] make update > *** Signal 12 > > Stop. > make: stopped in /usr/src > .ERROR_TARGET='update' > .ERROR_META_FILE='' > .MAKE.LEVEL='0' > MAKEFILE='' > .MAKE.MODE='normal' > .CURDIR='/usr/src' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src' > .TARGETS='update' > DESTDIR='' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='/usr/obj' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20160606' > PATH='/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP='/usr/src' > OBJTOP='/usr/obj/usr/src' > > These two machines in question are victims "of the early adopter" - the warning came way > too late! At work, I did the same update - but I did an installworld prior to the usual > installkernel - and everything seems so far to work, even without COMAPT_FREEBSD10 in the > kernel. > > Is there a way to salvage the situation without relying on "customized" third party > kernels? > > I usually use /bin/csh - so this might be of use. You need either kernel with COMPAT_FREEBSD10, or simpler, newer libc. You could take that libc anywhere, e.g. from the ALPHA5 binaries recently uploaded. There is no way to fix build with the combination of bits you have at present self-hosting. From owner-freebsd-current@freebsd.org Sat Jun 25 15:35:43 2016 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 83215B81787 for ; Sat, 25 Jun 2016 15:35:43 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay104.isp.belgacom.be (mailrelay104.isp.belgacom.be [195.238.20.131]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB6DF1292 for ; Sat, 25 Jun 2016 15:35:42 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2C0BgC9o25X/1dRsVtcgz5JgQquIYl5gg+Be4YSBAICgSE6EwEBAQEBAQFlJ4RNAQEEOhwjEAsOCgklDxIYHgYBEogWAxvDHQ2ECQEBAQEBAQEDAQEBAQEiinWCQ4dYAQSYTTSMM4F6cG2NUYgQh28fATSDcjoyiUgBAQE Received: from 87.81-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.81.87]) by relay.skynet.be with ESMTP; 25 Jun 2016 17:35:33 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id u5PFZWZl030895; Sat, 25 Jun 2016 17:35:32 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Sat, 25 Jun 2016 17:35:31 +0200 From: Tijl Coosemans To: Konstantin Belousov , "O. Hartmann" Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160625173531.104842ac@kalimero.tijl.coosemans.org> In-Reply-To: <20160625152645.GB38613@kib.kiev.ua> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> <330789230754140e38fb527973e23405@ultimatedns.net> <20160624225034.GC20770@spindle.one-eyed-alien.net> <20160625070238.GG38613@kib.kiev.ua> <20160625131806.14fa4799.ohartman@zedat.fu-berlin.de> <20160625113544.GS38613@kib.kiev.ua> <20160625171714.7e318044.ohartman@zedat.fu-berlin.de> <20160625152645.GB38613@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 15:35:43 -0000 On Sat, 25 Jun 2016 18:26:45 +0300 Konstantin Belousov wrote: > On Sat, Jun 25, 2016 at 05:17:14PM +0200, O. Hartmann wrote: >> Is there a way to salvage the situation without relying on "customized" >> third party kernels? >> >> I usually use /bin/csh - so this might be of use. > > You need either kernel with COMPAT_FREEBSD10, or simpler, newer libc. > You could take that libc anywhere, e.g. from the ALPHA5 binaries recently > uploaded. There is no way to fix build with the combination of bits you > have at present self-hosting. Can't he boot kernel.old? From owner-freebsd-current@freebsd.org Sat Jun 25 15:40:08 2016 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 E06BBB81826 for ; Sat, 25 Jun 2016 15:40:08 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 9EFD4143E; Sat, 25 Jun 2016 15:40:08 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bGpgk-003HOq-Is>; Sat, 25 Jun 2016 17:40:06 +0200 Received: from x55b3a5f8.dyn.telefonica.de ([85.179.165.248] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bGpgk-001fwZ-89>; Sat, 25 Jun 2016 17:40:06 +0200 Date: Sat, 25 Jun 2016 17:40:18 +0200 From: "O. Hartmann" To: Tijl Coosemans Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160625174018.1c44c60c.ohartman@zedat.fu-berlin.de> In-Reply-To: <20160625173531.104842ac@kalimero.tijl.coosemans.org> References: <20160623210751.GB7860@spindle.one-eyed-alien.net> <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> <330789230754140e38fb527973e23405@ultimatedns.net> <20160624225034.GC20770@spindle.one-eyed-alien.net> <20160625070238.GG38613@kib.kiev.ua> <20160625131806.14fa4799.ohartman@zedat.fu-berlin.de> <20160625113544.GS38613@kib.kiev.ua> <20160625171714.7e318044.ohartman@zedat.fu-berlin.de> <20160625152645.GB38613@kib.kiev.ua> <20160625173531.104842ac@kalimero.tijl.coosemans.org> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/YuqzO234gUkE92Gcv9KLC0="; protocol="application/pgp-signature" X-Originating-IP: 85.179.165.248 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 15:40:09 -0000 --Sig_/YuqzO234gUkE92Gcv9KLC0= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 25 Jun 2016 17:35:31 +0200 Tijl Coosemans schrieb: > On Sat, 25 Jun 2016 18:26:45 +0300 Konstantin Belousov wrote: > > On Sat, Jun 25, 2016 at 05:17:14PM +0200, O. Hartmann wrote: =20 > >> Is there a way to salvage the situation without relying on "customized" > >> third party kernels? > >>=20 > >> I usually use /bin/csh - so this might be of use. =20 > >=20 > > You need either kernel with COMPAT_FREEBSD10, or simpler, newer libc. > > You could take that libc anywhere, e.g. from the ALPHA5 binaries recent= ly > > uploaded. There is no way to fix build with the combination of bits you > > have at present self-hosting. =20 >=20 > Can't he boot kernel.old? ... he can, but it is the very same as with the recent kernel. Besides - I thought "I would have the most recent libc" in this scenario an= d the kernel is out of sync?=20 --Sig_/YuqzO234gUkE92Gcv9KLC0= Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXbqXiAAoJEOgBcD7A/5N8sG0IANqtKK5DsPIbK4+6+sjAenqR iC2OefInFQ4LU4nZ6/9svIPsoV3g/qadEvxcE3OLSVW4vpfx89OqRozdDnKprx45 ujpDpxiqFlBKOgiIspQydiHCNcAsP+1OMMuCW+pejQzbAoZRLE7/GTlZ+kgGiN5J mqdD0q+3twneJ0okQrDrfXac1jgdtvat2gLvlM5SIMMiAnZblv7DWhzfqw/MMD2S 2Eo1nDTmt9YudZOaHXrf4k+iJbJQRrSB87e5xpTiVjjJk3ZF1m5w6FCpqtadsLYc 1rDnNhUD2cRnYoEgapPYQL/E8QHEUEJfwHIUEL4tgt59x2vzIIrWKoxHz9ynITE= =Cyrx -----END PGP SIGNATURE----- --Sig_/YuqzO234gUkE92Gcv9KLC0=-- From owner-freebsd-current@freebsd.org Sat Jun 25 14:41:27 2016 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 EBED3B80465 for ; Sat, 25 Jun 2016 14:41:27 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id C33D31B45 for ; Sat, 25 Jun 2016 14:41:27 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by mailman.ysv.freebsd.org (Postfix) id BE681B80460; Sat, 25 Jun 2016 14:41:27 +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 BDF1AB8045F for ; Sat, 25 Jun 2016 14:41:27 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DBBB1B3E for ; Sat, 25 Jun 2016 14:41:27 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by mail-vk0-x22e.google.com with SMTP id c2so154194276vkg.1 for ; Sat, 25 Jun 2016 07:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=from:mime-version:subject:in-reply-to:date:cc:message-id:references :to; bh=Duy9BnwOmcR9mCL+dw5z6on0vanDV3plsSQCxKfAZjQ=; b=DDgWUVly6boLZ4Y6k9C1+lCp+YQDoUSLcfYK/iupnpZClD2e4hJICYOigCL2WUkczS 3li1Q2JBYtjgNbyRFC3e5HCwtrFz/+znhMu1LbSbxIZvP3nak4MV73X5EG30Yhc2wGrt jP/QIUf1f7kDTFcrPXd8Vyoxw7El9LgsG3bZE= 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:subject:in-reply-to:date:cc :message-id:references:to; bh=Duy9BnwOmcR9mCL+dw5z6on0vanDV3plsSQCxKfAZjQ=; b=P+DidpU1a/OAOSHkgb6OBbbmj/8gB2OljuPKavS95dBLvGd9I4VxhGjjQfMIjzuGbS QC99CveVsSlcmv4SYhzgYBt/E/9CHol6b2AYzHoaP70GXeA57nRloscLUKr/Em56GisC NQAjVv80W/WQIr7HV9cD8UIUg4RY4c1jdYZGvvpAjKAso5Zgusg1wwN9ms6wu8nsSiSz WX0TwrJRFxvErLyJxpyoaASbIP5v2xOkuTlD3aDHTV+qjC76oHVCILvKUDEzDv+mOqnN DVuXooHnKzGnqU5n7yyqdzAMbkZ7Qa1GolA02n4fiZLK3MMsrUiXMmfYFRCYH+hjneur //+w== X-Gm-Message-State: ALyK8tLIUKvYeZntNn2i73f6hefNgByX88hlDowBASGDC2UEX2poIBxRVGk/xw7HdiW/EJ1m X-Received: by 10.176.4.49 with SMTP id 46mr4269844uav.32.1466865686298; Sat, 25 Jun 2016 07:41:26 -0700 (PDT) Received: from [100.127.86.242] ([69.53.246.16]) by smtp.gmail.com with ESMTPSA id 45sm2914659uaq.6.2016.06.25.07.41.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 Jun 2016 07:41:25 -0700 (PDT) From: Randall Stewart X-Google-Original-From: Randall Stewart Content-Type: multipart/mixed; boundary="Apple-Mail=_F9B158CC-A33B-400F-9DD1-C3982E64FC31" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: panic with tcp timers In-Reply-To: <18D94615-810E-4E79-A889-4B0CC70F9E45@netflix.com> Date: Sat, 25 Jun 2016 10:41:24 -0400 Cc: Julien Charbon , Gleb Smirnoff , hselasky@FreeBSD.org, net@FreeBSD.org Message-Id: <6E52CA6A-2153-4EF9-A3E1-97CB0D07EB28@freebsd.org> References: <20160617045319.GE1076@FreeBSD.org> <1f28844b-b4ea-b544-3892-811f2be327b9@freebsd.org> <20160620073917.GI1076@FreeBSD.org> <1d18d0e2-3e42-cb26-928c-2989d0751884@freebsd.org> <20160620095822.GJ1076@FreeBSD.org> <74bb31b7-a9f5-3d0c-eea0-681872e6f09b@freebsd.org> <18D94615-810E-4E79-A889-4B0CC70F9E45@netflix.com> To: current@freebsd.org X-Mailer: Apple Mail (2.3124) X-Mailman-Approved-At: Sat, 25 Jun 2016 15:43:56 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 14:41:28 -0000 --Apple-Mail=_F9B158CC-A33B-400F-9DD1-C3982E64FC31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ok Lets try this again with my source changed to my @freebsd.net :-) Now I am also attaching a patch for you Gleb, this will take some poking = to get in to your NF-head since it incorporates some changes we made = earlier. I think this will fix the problem.. i.e. dealing with two locks in the = callout system (which it was never meant to have done).. Note we probably can move the code to use the callout lock init now.. = but lets see if this works on your setup on c096 and if so we can think about doing that. R --Apple-Mail=_F9B158CC-A33B-400F-9DD1-C3982E64FC31 Content-Disposition: attachment; filename=for_gleb Content-Type: application/octet-stream; name="for_gleb" Content-Transfer-Encoding: 7bit Index: tcp_timer.c =================================================================== --- tcp_timer.c (revision 302198) +++ tcp_timer.c (working copy) @@ -306,6 +306,33 @@ tcp_timer_delack(void *xtp) CURVNET_RESTORE(); } +static inline int +tcp_inp_lock_exchange(struct tcpcb *tp) +{ + struct inpcb *inp; + + + inp = tp->t_inpcb; + in_pcbref(inp); + INP_WUNLOCK(inp); + INP_INFO_RLOCK(&V_tcbinfo); + INP_WLOCK(inp); + if (inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) { + return(1); + } + return(0); + +} + +static inline void +tcp_inp_unlock_exchange(struct tcpcb *tp) +{ + INP_INFO_RUNLOCK(&V_tcbinfo); + if (tp && in_pcbrele_wlocked(tp->t_inpcb) == 0) { + INP_WUNLOCK(tp->t_inpcb); + } +} + void tcp_timer_2msl(void *xtp) { @@ -317,7 +344,6 @@ tcp_timer_2msl(void *xtp) ostate = tp->t_state; #endif - INP_INFO_RLOCK(&V_tcbinfo); inp = tp->t_inpcb; KASSERT(inp != NULL, ("%s: tp %p tp->t_inpcb == NULL", __func__, tp)); INP_WLOCK(inp); @@ -325,7 +351,6 @@ tcp_timer_2msl(void *xtp) if (callout_pending(&tp->t_timers->tt_2msl) || !callout_active(&tp->t_timers->tt_2msl)) { INP_WUNLOCK(tp->t_inpcb); - INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -332,7 +357,6 @@ tcp_timer_2msl(void *xtp) callout_deactivate(&tp->t_timers->tt_2msl); if ((inp->inp_flags & INP_DROPPED) != 0) { INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -355,7 +379,6 @@ tcp_timer_2msl(void *xtp) */ if ((inp->inp_flags & INP_TIMEWAIT) != 0) { INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -363,7 +386,13 @@ tcp_timer_2msl(void *xtp) tp->t_inpcb && tp->t_inpcb->inp_socket && (tp->t_inpcb->inp_socket->so_rcv.sb_state & SBS_CANTRCVMORE)) { TCPSTAT_INC(tcps_finwait2_drops); + if (tcp_inp_lock_exchange(tp)) { + tcp_inp_unlock_exchange(tp); + goto out; + } tp = tcp_close(tp); + tcp_inp_unlock_exchange(tp); + goto out; } else { if (ticks - tp->t_rcvtime <= TP_MAXIDLE(tp)) { if (!callout_reset(&tp->t_timers->tt_2msl, @@ -370,8 +399,15 @@ tcp_timer_2msl(void *xtp) TP_KEEPINTVL(tp), tcp_timer_2msl, tp)) { tp->t_timers->tt_flags &= ~TT_2MSL_RST; } - } else - tp = tcp_close(tp); + } else { + if (tcp_inp_lock_exchange(tp)) { + tcp_inp_unlock_exchange(tp); + goto out; + } + tp = tcp_close(tp); + tcp_inp_unlock_exchange(tp); + goto out; + } } #ifdef TCPDEBUG @@ -383,7 +419,7 @@ tcp_timer_2msl(void *xtp) if (tp != NULL) INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); +out: CURVNET_RESTORE(); } @@ -399,7 +435,6 @@ tcp_timer_keep(void *xtp) ostate = tp->t_state; #endif - INP_INFO_RLOCK(&V_tcbinfo); inp = tp->t_inpcb; KASSERT(inp != NULL, ("%s: tp %p tp->t_inpcb == NULL", __func__, tp)); INP_WLOCK(inp); @@ -406,7 +441,6 @@ tcp_timer_keep(void *xtp) if (callout_pending(&tp->t_timers->tt_keep) || !callout_active(&tp->t_timers->tt_keep)) { INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -413,7 +447,6 @@ tcp_timer_keep(void *xtp) callout_deactivate(&tp->t_timers->tt_keep); if ((inp->inp_flags & INP_DROPPED) != 0) { INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -468,12 +501,16 @@ tcp_timer_keep(void *xtp) #endif TCP_PROBE2(debug__user, tp, PRU_SLOWTIMO); INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; dropit: TCPSTAT_INC(tcps_keepdrops); + + if (tcp_inp_lock_exchange(tp)) { + tcp_inp_unlock_exchange(tp); + goto out; + } tp = tcp_drop(tp, ETIMEDOUT); #ifdef TCPDEBUG @@ -482,9 +519,8 @@ dropit: PRU_SLOWTIMO); #endif TCP_PROBE2(debug__user, tp, PRU_SLOWTIMO); - if (tp != NULL) - INP_WUNLOCK(tp->t_inpcb); - INP_INFO_RUNLOCK(&V_tcbinfo); + tcp_inp_unlock_exchange(tp); +out: CURVNET_RESTORE(); } @@ -499,7 +535,6 @@ tcp_timer_persist(void *xtp) ostate = tp->t_state; #endif - INP_INFO_RLOCK(&V_tcbinfo); inp = tp->t_inpcb; KASSERT(inp != NULL, ("%s: tp %p tp->t_inpcb == NULL", __func__, tp)); INP_WLOCK(inp); @@ -506,7 +541,6 @@ tcp_timer_persist(void *xtp) if (callout_pending(&tp->t_timers->tt_persist) || !callout_active(&tp->t_timers->tt_persist)) { INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -513,7 +547,6 @@ tcp_timer_persist(void *xtp) callout_deactivate(&tp->t_timers->tt_persist); if ((inp->inp_flags & INP_DROPPED) != 0) { INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -537,7 +570,12 @@ tcp_timer_persist(void *xtp) (ticks - tp->t_rcvtime >= tcp_maxpersistidle || ticks - tp->t_rcvtime >= TCP_REXMTVAL(tp) * tcp_totbackoff)) { TCPSTAT_INC(tcps_persistdrop); + if (tcp_inp_lock_exchange(tp)) { + tcp_inp_unlock_exchange(tp); + goto out; + } tp = tcp_drop(tp, ETIMEDOUT); + tcp_inp_unlock_exchange(tp); goto out; } /* @@ -547,7 +585,12 @@ tcp_timer_persist(void *xtp) if (tp->t_state > TCPS_CLOSE_WAIT && (ticks - tp->t_rcvtime) >= TCPTV_PERSMAX) { TCPSTAT_INC(tcps_persistdrop); + if (tcp_inp_lock_exchange(tp)) { + tcp_inp_unlock_exchange(tp); + goto out; + } tp = tcp_drop(tp, ETIMEDOUT); + tcp_inp_unlock_exchange(tp); goto out; } tcp_setpersist(tp); @@ -555,15 +598,13 @@ tcp_timer_persist(void *xtp) (void) tp->t_fb->tfb_tcp_output(tp); tp->t_flags &= ~TF_FORCEDATA; -out: #ifdef TCPDEBUG if (tp != NULL && tp->t_inpcb->inp_socket->so_options & SO_DEBUG) tcp_trace(TA_USER, ostate, tp, NULL, NULL, PRU_SLOWTIMO); #endif TCP_PROBE2(debug__user, tp, PRU_SLOWTIMO); - if (tp != NULL) - INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); + INP_WUNLOCK(inp); +out: CURVNET_RESTORE(); } @@ -573,7 +614,6 @@ tcp_timer_rexmt(void * xtp) struct tcpcb *tp = xtp; CURVNET_SET(tp->t_vnet); int rexmt; - int headlocked; struct inpcb *inp; #ifdef TCPDEBUG int ostate; @@ -580,8 +620,6 @@ tcp_timer_rexmt(void * xtp) ostate = tp->t_state; #endif - - INP_INFO_RLOCK(&V_tcbinfo); inp = tp->t_inpcb; KASSERT(inp != NULL, ("%s: tp %p tp->t_inpcb == NULL", __func__, tp)); INP_WLOCK(inp); @@ -588,7 +626,6 @@ tcp_timer_rexmt(void * xtp) if (callout_pending(&tp->t_timers->tt_rexmt) || !callout_active(&tp->t_timers->tt_rexmt)) { INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -595,7 +632,6 @@ tcp_timer_rexmt(void * xtp) callout_deactivate(&tp->t_timers->tt_rexmt); if ((inp->inp_flags & INP_DROPPED) != 0) { INP_WUNLOCK(inp); - INP_INFO_RUNLOCK(&V_tcbinfo); CURVNET_RESTORE(); return; } @@ -616,14 +652,15 @@ tcp_timer_rexmt(void * xtp) if (++tp->t_rxtshift > TCP_MAXRXTSHIFT) { tp->t_rxtshift = TCP_MAXRXTSHIFT; TCPSTAT_INC(tcps_timeoutdrop); - + if (tcp_inp_lock_exchange(tp)) { + tcp_inp_unlock_exchange(tp); + goto out; + } tp = tcp_drop(tp, tp->t_softerror ? tp->t_softerror : ETIMEDOUT); - headlocked = 1; + tcp_inp_unlock_exchange(tp); goto out; } - INP_INFO_RUNLOCK(&V_tcbinfo); - headlocked = 0; if (tp->t_state == TCPS_SYN_SENT) { /* * If the SYN was retransmitted, indicate CWND to be @@ -811,7 +848,6 @@ tcp_timer_rexmt(void * xtp) (void) tp->t_fb->tfb_tcp_output(tp); -out: #ifdef TCPDEBUG if (tp != NULL && (tp->t_inpcb->inp_socket->so_options & SO_DEBUG)) tcp_trace(TA_USER, ostate, tp, (void *)0, (struct tcphdr *)0, @@ -818,10 +854,8 @@ tcp_timer_rexmt(void * xtp) PRU_SLOWTIMO); #endif TCP_PROBE2(debug__user, tp, PRU_SLOWTIMO); - if (tp != NULL) - INP_WUNLOCK(inp); - if (headlocked) - INP_INFO_RUNLOCK(&V_tcbinfo); + INP_WUNLOCK(inp); +out: CURVNET_RESTORE(); } @@ -832,7 +866,6 @@ tcp_timer_activate(struct tcpcb *tp, uint32_t time timeout_t *f_callout; struct inpcb *inp = tp->t_inpcb; int cpu = inp_to_cpuid(inp); - uint32_t f_reset; #ifdef TCP_OFFLOAD if (tp->t_flags & TF_TOE) @@ -846,27 +879,22 @@ tcp_timer_activate(struct tcpcb *tp, uint32_t time case TT_DELACK: t_callout = &tp->t_timers->tt_delack; f_callout = tcp_timer_delack; - f_reset = TT_DELACK_RST; break; case TT_REXMT: t_callout = &tp->t_timers->tt_rexmt; f_callout = tcp_timer_rexmt; - f_reset = TT_REXMT_RST; break; case TT_PERSIST: t_callout = &tp->t_timers->tt_persist; f_callout = tcp_timer_persist; - f_reset = TT_PERSIST_RST; break; case TT_KEEP: t_callout = &tp->t_timers->tt_keep; f_callout = tcp_timer_keep; - f_reset = TT_KEEP_RST; break; case TT_2MSL: t_callout = &tp->t_timers->tt_2msl; f_callout = tcp_timer_2msl; - f_reset = TT_2MSL_RST; break; default: if (tp->t_fb->tfb_tcp_timer_activate) { @@ -876,24 +904,9 @@ tcp_timer_activate(struct tcpcb *tp, uint32_t time panic("tp %p bad timer_type %#x", tp, timer_type); } if (delta == 0) { - if ((tp->t_timers->tt_flags & timer_type) && - (callout_stop(t_callout) > 0) && - (tp->t_timers->tt_flags & f_reset)) { - tp->t_timers->tt_flags &= ~(timer_type | f_reset); - } + callout_stop(t_callout); } else { - if ((tp->t_timers->tt_flags & timer_type) == 0) { - tp->t_timers->tt_flags |= (timer_type | f_reset); - callout_reset_on(t_callout, delta, f_callout, tp, cpu); - } else { - /* Reset already running callout on the same CPU. */ - if (!callout_reset(t_callout, delta, f_callout, tp)) { - /* - * Callout not cancelled, consider it as not - * properly restarted. */ - tp->t_timers->tt_flags &= ~f_reset; - } - } + callout_reset_on(t_callout, delta, f_callout, tp, cpu); } } @@ -931,30 +944,23 @@ void tcp_timer_stop(struct tcpcb *tp, uint32_t timer_type) { struct callout *t_callout; - uint32_t f_reset; tp->t_timers->tt_flags |= TT_STOPPED; - switch (timer_type) { case TT_DELACK: t_callout = &tp->t_timers->tt_delack; - f_reset = TT_DELACK_RST; break; case TT_REXMT: t_callout = &tp->t_timers->tt_rexmt; - f_reset = TT_REXMT_RST; break; case TT_PERSIST: t_callout = &tp->t_timers->tt_persist; - f_reset = TT_PERSIST_RST; break; case TT_KEEP: t_callout = &tp->t_timers->tt_keep; - f_reset = TT_KEEP_RST; break; case TT_2MSL: t_callout = &tp->t_timers->tt_2msl; - f_reset = TT_2MSL_RST; break; default: if (tp->t_fb->tfb_tcp_timer_stop) { @@ -968,15 +974,13 @@ tcp_timer_stop(struct tcpcb *tp, uint32_t timer_ty panic("tp %p bad timer_type %#x", tp, timer_type); } - if (tp->t_timers->tt_flags & timer_type) { - if (callout_async_drain(t_callout, tcp_timer_discard) == 0) { - /* - * Can't stop the callout, defer tcpcb actual deletion - * to the last one. We do this using the async drain - * function and incrementing the count in - */ - tp->t_timers->tt_draincnt++; - } + if (callout_async_drain(t_callout, tcp_timer_discard) == 0) { + /* + * Can't stop the callout, defer tcpcb actual deletion + * to the last one. We do this using the async drain + * function and incrementing the count in + */ + tp->t_timers->tt_draincnt++; } } --Apple-Mail=_F9B158CC-A33B-400F-9DD1-C3982E64FC31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jun 25, 2016, at 4:48 AM, Randall Stewart wrote: >=20 > So >=20 > All of our timers in TCP do something like > --------------------- > INFO-LOCK > INP_WLOCK >=20 > if (inp needs to be dropped) { > drop-it > } > do other work >=20 > UNLOCK-INP > UNLOCK-INFO > ------------------ >=20 > And generally the path =93inp needs to be dropped=94 is rarely taken. >=20 > So why don=92t we change the procedure to something like: >=20 > INP_WLOCK > if (inp needs to be dropped) { > inp_ref() > INP_WUNLOCK() > INFO_LOCK() > INP_WLOCK() > if (inp_release_ref) { > /* victory its dead */ > INFO_UNLOCK > return > } > do-the-drop > } >=20 > This way we would only go grab the INFO lock in those rarer cases > when we *do* actually want to kill the tcb and at the same time > it would make the current callout system work correctly.. which as > many have pointed out would be much better if we could just let the > lock be gotten by the callout system. Hmm maybe with this scheme we > could even do that... >=20 > R >=20 >=20 >> On Jun 20, 2016, at 1:45 PM, Julien Charbon wrote: >>=20 >>=20 >> Hi, >>=20 >> On 6/20/16 11:58 AM, Gleb Smirnoff wrote: >>> On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote: >>> J> > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: >>> J> > J> > Comparing stable/10 and head, I see two changes that could >>> J> > J> > affect that: >>> J> > J> >=20 >>> J> > J> > - callout_async_drain >>> J> > J> > - switch to READ lock for inp info in tcp timers >>> J> > J> >=20 >>> J> > J> > That's why you are in To, Julien and Hans :) >>> J> > J> >=20 >>> J> > J> > We continue investigating, and I will keep you updated. >>> J> > J> > However, any help is welcome. I can share cores. >>> J> >=20 >>> J> > Now, spending some time with cores and adding a bunch of >>> J> > extra CTRs, I have a sequence of events that lead to the >>> J> > panic. In short, the bug is in the callout system. It seems >>> J> > to be not relevant to the callout_async_drain, at least for >>> J> > now. The transition to READ lock unmasked the problem, that's >>> J> > why NetflixBSD 10 doesn't panic. >>> J> >=20 >>> J> > The panic requires heavy contention on the TCP info lock. >>> J> >=20 >>> J> > [CPU 1] the callout fires, tcp_timer_keep entered >>> J> > [CPU 1] blocks on INP_INFO_RLOCK(&V_tcbinfo); >>> J> > [CPU 2] schedules the callout >>> J> > [CPU 2] tcp_discardcb called >>> J> > [CPU 2] callout successfully canceled >>> J> > [CPU 2] tcpcb freed >>> J> > [CPU 1] unblocks... panic >>> J> >=20 >>> J> > When the lock was WLOCK, all contenders were resumed in a >>> J> > sequence they came to the lock. Now, that they are readers, >>> J> > once the lock is released, readers are resumed in a "random" >>> J> > order, and this allows tcp_discardcb to go before the old >>> J> > running callout, and this unmasks the panic. >>> J>=20 >>> J> Highly interesting. I should be able to reproduce that (will be = useful >>> J> for testing the corresponding fix). >>> J>=20 >>> J> Fix proposal: If callout_async_drain() returns 0 (fail) = (instead of 1 >>> J> (success) here) when the callout cancellation is a success _but_ = the >>> J> callout is current running, that should fix it. >>> J>=20 >>> J> For the history: It comes back to my old callout question: >>> J>=20 >>> J> Does _callout_stop_safe() is allowed to return 1 (success) even = if the >>> J> callout is still currently running; a.k.a. it is not because you >>> J> successfully cancelled a callout that the callout is not = currently running. >>> J>=20 >>> J> We did propose a patch to make _callout_stop_safe() returns 0 = (fail) >>> J> when the callout is currently running: >>> J>=20 >>> J> callout_stop() should return 0 when the callout is currently = being >>> J> serviced and indeed unstoppable >>> J> = https://reviews.freebsd.org/differential/changeset/?ref=3D62513&whitespace= =3Dignore-most >>> J>=20 >>> J> But this change impacted too many old code paths and was = interesting >>> J> only for TCP timers and thus was abandoned. >>>=20 >>> The fix I am working on now is doing exactly that. callout_reset = must >>> return 0 if the callout is currently running. >>>=20 >>> What are the old paths impacted? >>=20 >> Actually all the paths that check the callout_stop() return value AND >> call both callout_reset() and callout_stop() AND use mpsafe = callout(). >> And for each path, we would have to check our patch was ok (or not). >>=20 >> Thus, if you only do the change in callout_async_drain() context, you >> don't impact the "old" callout_stop() behavior and get the desired >> behavior for the TCP timers. Might be a good trade-off... >>=20 >> My 2 cents. >>=20 >> -- >> Julien >=20 > -------- > Randall Stewart > rrs@netflix.com > 803-317-4952 >=20 >=20 >=20 >=20 >=20 -------- Randall Stewart rrs@netflix.com 803-317-4952 --Apple-Mail=_F9B158CC-A33B-400F-9DD1-C3982E64FC31-- From owner-freebsd-current@freebsd.org Sat Jun 25 15:46:38 2016 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 9EE78B81CCE for ; Sat, 25 Jun 2016 15:46:38 +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 1D7851EAF; Sat, 25 Jun 2016 15:46:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u5PFkXCJ088999 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 25 Jun 2016 18:46:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u5PFkXCJ088999 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u5PFkXaV088998; Sat, 25 Jun 2016 18:46:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 25 Jun 2016 18:46:33 +0300 From: Konstantin Belousov To: Tijl Coosemans Cc: "O. Hartmann" , freebsd-current@freebsd.org Subject: Re: HEADS UP: caution required with updates using custom kernels Message-ID: <20160625154633.GC38613@kib.kiev.ua> References: <20160624060019.5e650ad9.ohartman@zedat.fu-berlin.de> <20160624155111.GB20770@spindle.one-eyed-alien.net> <330789230754140e38fb527973e23405@ultimatedns.net> <20160624225034.GC20770@spindle.one-eyed-alien.net> <20160625070238.GG38613@kib.kiev.ua> <20160625131806.14fa4799.ohartman@zedat.fu-berlin.de> <20160625113544.GS38613@kib.kiev.ua> <20160625171714.7e318044.ohartman@zedat.fu-berlin.de> <20160625152645.GB38613@kib.kiev.ua> <20160625173531.104842ac@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160625173531.104842ac@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.6.1 (2016-04-27) 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.22 Precedence: 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, 25 Jun 2016 15:46:38 -0000 On Sat, Jun 25, 2016 at 05:35:31PM +0200, Tijl Coosemans wrote: > On Sat, 25 Jun 2016 18:26:45 +0300 Konstantin Belousov wrote: > > On Sat, Jun 25, 2016 at 05:17:14PM +0200, O. Hartmann wrote: > >> Is there a way to salvage the situation without relying on "customized" > >> third party kernels? > >> > >> I usually use /bin/csh - so this might be of use. > > > > You need either kernel with COMPAT_FREEBSD10, or simpler, newer libc. > > You could take that libc anywhere, e.g. from the ALPHA5 binaries recently > > uploaded. There is no way to fix build with the combination of bits you > > have at present self-hosting. > > Can't he boot kernel.old? Presumably this was tried. BTW, this situation is a stellar argument to finally switch toolchain to dynamic linking. For dynamically-linked make, LD_PRELOADing a dso like this would solve the problem int pipe(int[] fds) { return (pipe2(fds, 0)); } From owner-freebsd-current@freebsd.org Sat Jun 25 16:19:54 2016 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 B3907B8004D; Sat, 25 Jun 2016 16:19:54 +0000 (UTC) (envelope-from gjb@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 A4A9B2120; Sat, 25 Jun 2016 16:19:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 5A7101828; Sat, 25 Jun 2016 16:19:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 25 Jun 2016 16:19:53 +0000 From: Glen Barber To: freebsd-snapshots@FreeBSD.org, freebsd-current@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: Re: New FreeBSD snapshots available: head (20160624 r302164) Message-ID: <20160625161953.GS19747@FreeBSD.org> References: <20160625021324.GA21010@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Y51z1SGMnxVzkhDv" Content-Disposition: inline In-Reply-To: <20160625021324.GA21010@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 16:19:54 -0000 --Y51z1SGMnxVzkhDv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 25, 2016 at 02:13:24AM +0000, Glen Barber wrote: > New FreeBSD development branch installation ISOs and virtual machine > disk images have been uploaded to the FTP mirrors. >=20 There have been a few reports of "missing" files on the FTP mirrors. This happened last week with the i386 MANIFEST file for base.txz, etc., and FreeBSD-11.0-ALPHA5-arm-armv6-BANANAPI-20160624-r302164.img.xz was missing this week (in addition to other files). I'm looking into the root cause, but if you notice something missing that should exist, please email me privately. (This is not an re@ issue, this is an admins@ issue, and I'm still trying to figure out what is going wrong.) Thanks, and apologies for anything I've missed. Glen --Y51z1SGMnxVzkhDv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXbq8pAAoJEAMUWKVHj+KTTEkP/07aiUcYkMeHEDapu9P89kgF KAmqmLiBz1SJok4UNmByZu9k3kbEg142qV5A7X6jPhfZC1qr41FPfeg25leXaU5k Ckq9FIj6do+zuf5cFpyTIpClRUBXn7etA4XOCPLs1kBO6whTJIaUKL+DeURhq/fO /YjWZGuCyZEw5qlFMywcsVyqTxjqPdC84YNxb38DSXBDCPe6g4T/yHbGCtTXHpdL ZJixYhhb4D1RKCx+0+lkYHm+oR3nIAcPswUUert67QhQEuuNVUZjXms0I8iqCOKw /NPsZgUM67W206QCfW4iuxZZxProNkxLFUOEisqYX9kS1/cYTTapv4VGQbmxmdn3 GJxmQOMRemGSqYlFn7+FTwlMJOAuSuxvFkmveord2Bd4U2Prvwg0PsNSwi9o1SWe p5kr33krjIQoPqHJI8ZK44/4U0MP9uTL4PzrXWHP1Rmfep8NikanDmchXyIk2XMb WI64Eg2yy2U7iNRf1C1rXk2JAib3z0bDu57JcGDzVG0HrkjrFf8PVaARMH5JARIj J7cgvesRQCnwInnORM87bHo0tsrZooEeAYPKDjnHnhakmUjhWMJ77g4ifCd1e/so kv6no0vte2B2+Z49SuPnC0f10HFhQSnERlVN6lNrSqesms0fkYdS2WBliDm2JbCs rMtjRSg7Iqove9GtMw7W =LwlG -----END PGP SIGNATURE----- --Y51z1SGMnxVzkhDv-- From owner-freebsd-current@freebsd.org Sat Jun 25 16:16:03 2016 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 B9EFCB82F45 for ; Sat, 25 Jun 2016 16:16:03 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 77BDB1E91 for ; Sat, 25 Jun 2016 16:16:03 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x22d.google.com with SMTP id h190so35356106ith.1 for ; Sat, 25 Jun 2016 09:16:03 -0700 (PDT) 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:from:date:message-id :subject:to:cc; bh=KPGvviuXJCPPNzg8N0itYWnVzqmvsMZ6wlYso68tcds=; b=Xv7KMMSGluuD2Bkm3wYQR4t04pJCNJ7hQKuQwjd+ONTKflWo3qE5vpWORMqSE9sKYg CuBbXmlNtJYW4C4k1gaIWAd9VxPsu3j+PsxSGBsYPYOlmwFK8dcKLHmWYPZc87Zpp8YZ lEOSirf3Y2sgmfZmOSHqLANHM7A4xtmQiEoMuCcbVr84WGV7vr90CoCaMNI+SCTE0kC3 LKHJL119d6IfVZ11YwW6d6834G2gaLA7o8fristayQP4ybNmpzzMKmU8acYT5tki7pRm LR/CzDb62QNnSREwNmL6d4/dz75gzEAmvOB/N69RBhojxjPixz9K7fDOvAOovtMXTbdA fSZw== 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:from :date:message-id:subject:to:cc; bh=KPGvviuXJCPPNzg8N0itYWnVzqmvsMZ6wlYso68tcds=; b=hxRIzt4nOS4vfNDroVyBCbFhHFC13E25GuWsKKpN2Gfoq6cuhE+leH/0Q53yVPYlvq M9hs4RgRYyuLDQqgFVjULV8cT9DTg1vFaZLi3y44V7D/SuYLAY/qYnmUtQ7RxHfzdii4 ArjJWMMqkWa9SBx5YxNpm2UtIEaZ0VX5X5vIgw4XdpEdYJ7lz21DWLYT+knldjUJhovg 3yBIdJFRfk345MSYZP4EhbGXkZhajQHOpSKRYcupUmUFO2jRR5Nmpu7qVEwpAZ+nHQXO YytiyumKNTEPdCKMPfOxOZe3ZCzIHdPFwABgr9jGf4TnUWuPjBqYOYRsA51+IsTRMEwu N6Xw== X-Gm-Message-State: ALyK8tKMHo3I6E0OXLAntVjE1oYvrZoXOsyzM36n8pLYVlDfUrjDAGsOpvL/yI6qBLRbLmeu1IyODPecBFEUFyQT X-Received: by 10.36.123.75 with SMTP id q72mr2486183itc.44.1466871362552; Sat, 25 Jun 2016 09:16:02 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.125.197 with HTTP; Sat, 25 Jun 2016 09:16:01 -0700 (PDT) In-Reply-To: References: <20140627125613.GT93733@kib.kiev.ua> <1603235.2ShtoCfSqO@ralph.baldwin.cx> <20160622100241.GM38613@kib.kiev.ua> From: Maxim Sobolev Date: Sat, 25 Jun 2016 09:16:01 -0700 X-Google-Sender-Auth: OyT3s5nJ4OaYhoaFUlp5IrO8VdU Message-ID: Subject: Re: PostgreSQL performance on FreeBSD To: Sean Chittenden Cc: Konstantin Belousov , Adrian Chadd , performance@freebsd.org, John Baldwin , Alan Somers , Alan Cox , Alan Cox , freebsd-current , "current@freebsd.org" X-Mailman-Approved-At: Sat, 25 Jun 2016 17:36:04 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Jun 2016 16:16:03 -0000 Sean, to the issue that you are describing it is also might be possible to do it some other way around. One, perhaps more portable, is to share a connected socketpair between two communicating processes, so that you can do non-blocking read on one of its ends from time to time and check if it returns EOF. Which would be the case if whatever process holds the other end of it is no longer there. So instead of shared memory segment, you can have pool of descriptors, one for each worker that you care about. Polling on those would be trivial with just regular poll(2). The only issue might be that postgres forks a lot, so we would probably need to implement FD_CLOFORK to avoid copying those extra fds into every child. Something akin to a solution that I recently posted to work around problem that you cannot really waitpid() on a grand-child see PG BUG #14199 for details & patch. But yes, it would be really nice to get rid of SYSV shared memory use in PG completely as some point one way or another. -Max On Thu, Jun 23, 2016 at 3:42 PM, Sean Chittenden wrote: > Small nit: > > PostgreSQL used SYSV because it allowed for the detection of dead > processes. If you `kill -9`=E2=80=99ed a process, PostgreSQL can detect = that and > then shut down and perform an automatic recovery. In this regard, sysv i= s > pretty clever. The move to POSIX shared mem was done for a host of > reasons, but it means that you don=E2=80=99t have to adjust your SYSV lim= its. My > understanding from a few years ago is that there is still a ~64KB SYSV > memory segment that is still used to act as the latch to signal if a > process was killed, but all of the shared buffers are stored in posix > mmap=E2=80=99ed regions. > > At this point in time this could be replaced with kqueue(2) EVFILT_PROC, > but no one has done that yet. > > -sc > > > > -- > Sean Chittenden > sean@chittenden.org > > > On Jun 22, 2016, at 07:26 , Maxim Sobolev wrote: > > > > Konstantin, > > > > Not if you do sem_unlink() immediately, AFAIK. And that's what PG does. > So > > the window of opportunity for the leakage is quite small, much smaller > than > > for SYSV primitives. Sorry for missing your status update message, I've > > missed it somehow. > > > > ---- > > mySem =3D sem_open(semname, O_CREAT | O_EXCL, > > (mode_t) IPCProtection, > > (unsigned) 1); > > > > #ifdef SEM_FAILED > > if (mySem !=3D (sem_t *) SEM_FAILED) > > break; > > #else > > if (mySem !=3D (sem_t *) (-1)) > > break; > > #endif > > > > /* Loop if error indicates a collision */ > > if (errno =3D=3D EEXIST || errno =3D=3D EACCES || errno = =3D=3D EINTR) > > continue; > > > > /* > > * Else complain and abort > > */ > > elog(FATAL, "sem_open(\"%s\") failed: %m", semname); > > } > > > > /* > > * Unlink the semaphore immediately, so it can't be accessed > > externally. > > * This also ensures that it will go away if we crash. > > */ > > sem_unlink(semname); > > > > return mySem; > > ---- > > > > -Max > > > > On Wed, Jun 22, 2016 at 3:02 AM, Konstantin Belousov < > kostikbel@gmail.com> > > wrote: > > > >> On Tue, Jun 21, 2016 at 12:48:00PM -0700, Maxim Sobolev wrote: > >>> Thanks, Konstantin for the great work, we are definitely looking > forward > >> to > >>> get all those improvements to be part of the default FreeBSD > kernel/port. > >>> Would be nice if you can post an update some day later as to what's > >>> integrated and what's not. > >> I did posted the update several days earlier. Since you replying to > this > >> thread, it would be not unreasonable to read recent messages that were > >> sent. > >> > >>> > >>> Just in case, I've opened #14206 with PG to switch us to using POSIX > >>> semaphores by default. Apart from the mentioned performance benefits, > >> SYSV > >>> semaphores are PITA to deal with as they come in very limited > quantities > >> by > >>> default. Also they might stay around if PG dies/gets nuked and preven= t > it > >>> from starting again due to overflow. We've got some quite ugly code t= o > >>> clean up those using ipcrm(1) in our build scripts to deal with just > >> that. > >>> I am happy that code could be retired now. > >> > >> Named semaphores also stuck around if processes are killed without > cleanup. > >> > >> > > _______________________________________________ > > freebsd-performance@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-performance > > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > >