From owner-freebsd-stable@freebsd.org Sun Oct 23 01:48:15 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38564C1395A for ; Sun, 23 Oct 2016 01:48:15 +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 2C09FE7A; Sun, 23 Oct 2016 01:48:15 +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 B9B5D20D; Sun, 23 Oct 2016 01:48:14 +0000 (UTC) Date: Sun, 23 Oct 2016 01:48:12 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1192162199.39.1477187292183.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #439 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_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 01:48:15 -0000 https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/439/ From owner-freebsd-stable@freebsd.org Sun Oct 23 11:14:24 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD294C1E0F2 for ; Sun, 23 Oct 2016 11:14:24 +0000 (UTC) (envelope-from dgeo@centrale-marseille.fr) Received: from mel0.ec-m.fr (melout.ec-m.fr [147.94.19.37]) (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 708CBF38 for ; Sun, 23 Oct 2016 11:14:23 +0000 (UTC) (envelope-from dgeo@centrale-marseille.fr) Subject: Re: LOR in mpr(4) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=centrale-marseille.fr; s=smtp0; t=1477221254; bh=hSpfqdY3kwsmwBdC6Dn88hfabKjFzCRwtGUmi2a0aOQ=; h=Subject:To:References:From:Date:In-Reply-To; b=EasFbbGcq8bCr1AR27yqq71rbg77MHmR2dvRqKGKmo4WdgOSNiDF8IOHI0udwxWYB TQIdsOL9hBUczvonE8+vfurQayvAVb4K+R5VWT1QyK76tMegEDzRRYvaDoLQSt+qqP GDiQpnybGm3cxvyCqrvoa+KUSc5D/A7N2ekftSjQ6OCeJxQnpkNV8j+1Cxt7YCWF00 07XLo2yQ5+jMUFpwK5orNTU7AoofvQD/4I648TV/5IgOUC+XK+xhU7Mo+ehKx8l94W gH+pp4ppbY5+tAqRYndUWqXDVWtW9Wfr9gjhFuM+t3dB8MMGE8JMhAdD+EYTZBdKW6 YVP4eLGEvoYrg== To: freebsd-stable@freebsd.org References: <5644D014.4080601@nomadlogic.org> <564B917E.4000205@nomadlogic.org> <9fc856a5-c91d-cdfa-5000-5d8fc8ea20f1@centrale-marseille.fr> From: geoffroy desvernay X-Enigmail-Draft-Status: N1210 Message-ID: <5e030ebe-2570-29b4-0c84-39833fa3fbe5@centrale-marseille.fr> Date: Sun, 23 Oct 2016 13:14:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 11:14:24 -0000 On 10/19/2016 06:39 PM, Pete Wright wrote: > > the issue you are seeing is most likely not related to the LOR from the > original email and PR I filed. This looks like a media error with the > disk device on your RAID controller. A quick google search turn's up > quite a few threads on this - ranging from bad RAID/JBOD controllers to > out of date firmware. > > Cheers, > -pete > Thank you for your response, I'll take more time checking around controller. I just fear that this dell-repackaged avago controller may have some 'dell' crapped firmware… I have to look closer then :) Cheers, dgeo. -- *geoffroy desvernay* C.R.I - Administration systèmes et réseaux Ecole Centrale de Marseille Tel: (+33|0)4 91 05 45 24 Fax: (+33|0)4 91 05 45 98 dgeo@centrale-marseille.fr From owner-freebsd-stable@freebsd.org Sun Oct 23 13:53:41 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8F38C1E7B8 for ; Sun, 23 Oct 2016 13:53:41 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (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 84446F34 for ; Sun, 23 Oct 2016 13:53:40 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [217.29.44.10]) by gate2.intern.punkt.de with ESMTP id u9NDrWv2058492; Sun, 23 Oct 2016 15:53:32 +0200 (CEST) Received: from [217.29.46.116] ([217.29.46.116]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id u9NDrUlF097266; Sun, 23 Oct 2016 15:53:31 +0200 (CEST) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: boot0cfg on does not set default selection on gmirror device From: "Patrick M. Hausen" In-Reply-To: <20161022140755.S6806@sola.nimnet.asn.au> Date: Sun, 23 Oct 2016 15:53:59 +0200 Cc: freebsd-stable , Wolfgang Zenker , =?utf-8?Q?J=C3=B6rg_Schweizer?= Content-Transfer-Encoding: quoted-printable Message-Id: References: <14FD5FE6-6277-4EBE-8EE9-630A735F8BEA@punkt.de> <54B556F6-B834-4B0C-A9A4-90B9AD80A668@punkt.de> <20161022140755.S6806@sola.nimnet.asn.au> To: Ian Smith X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 13:53:41 -0000 Hi, Ian, > Am 22.10.2016 um 05:36 schrieb Ian Smith : > [...] > I wonder two things: >=20 > Do 'boot0cfg -v ada0' and 'boot0cfg -v ada1' both report the same? OK, situation before I try to change anything: root@hd45:~ # boot0cfg -v mirror/m0 [...] default_selection=3DF1 (Slice 1) root@hd45:~ # boot0cfg -v ada0 [...] default_selection=3DF1 (Slice 1) root@hd45:~ # boot0cfg -v ada1 [...] default_selection=3DF1 (Slice 1) Now try to change it to F2 through the mirror device: root@hd45:~ # boot0cfg -s 2 mirror/m0 # No error message or other indication that something went wrong! root@hd45:~ # boot0cfg -v mirror/m0 [...] default_selection=3DF1 (Slice 1) root@hd45:~ # boot0cfg -v ada0 [...] default_selection=3DF1 (Slice 1) root@hd45:~ # boot0cfg -v ada1 [...] default_selection=3DF1 (Slice 1) > Might it work properly if you upgraded the boot sectors to version 2,=20= > which is what you should get if you reinstall from current boot0cfg,=20= > presumably without touching the MBR data, but you'll have backups .. Well ... root@hd45:~ # boot0cfg -B mirror/m0 root@hd45:~ # boot0cfg -s 2 mirror/m0 root@hd45:~ # boot0cfg -v mirror/m0 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:63 16065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5 768:254:63 32852925 1920667140 version=3D2.0 drive=3D0x80 mask=3D0xf ticks=3D182 bell=3D# (0x23) options=3Dpacket,update,nosetdrv volume serial ID b100-808f default_selection=3DF2 (Slice 2) root@hd45:~ # boot0cfg -v ada0 [...] default_selection=3DF2 (Slice 2) root@hd45:~ # boot0cfg -v ada1 [...] default_selection=3DF2 (Slice 2) Revert the change: root@hd45:~ # boot0cfg -s 1 mirror/m0 root@hd45:~ # boot0cfg -v mirror/m0 [...] default_selection=3DF1 (Slice 1) That did it! These machines have been in production for some time starting with FreeBSD 8.x and have been upgraded via NanoBSD style dd followed by reboot all the time up to 10.3, now. Hence I never = touched the bootcode. Actual reboot of this production machine in two weeks when we run our regular updates. But I expect that to "just work". Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=C3=BCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@freebsd.org Mon Oct 24 02:50:51 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A124C1E5DF for ; Mon, 24 Oct 2016 02:50:51 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 B2E25381 for ; Mon, 24 Oct 2016 02:50:49 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u9O2oiYA089300; Mon, 24 Oct 2016 13:50:45 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 24 Oct 2016 13:50:44 +1100 (EST) From: Ian Smith To: "Patrick M. Hausen" cc: freebsd-stable Subject: Re: boot0cfg on does not set default selection on gmirror device In-Reply-To: Message-ID: <20161024133403.D6806@sola.nimnet.asn.au> References: <14FD5FE6-6277-4EBE-8EE9-630A735F8BEA@punkt.de> <54B556F6-B834-4B0C-A9A4-90B9AD80A668@punkt.de> <20161022140755.S6806@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 02:50:51 -0000 On Sun, 23 Oct 2016 15:53:59 +0200, Patrick M. Hausen wrote: > > Am 22.10.2016 um 05:36 schrieb Ian Smith : > > [...] > > I wonder two things: > > > > Do 'boot0cfg -v ada0' and 'boot0cfg -v ada1' both report the same? Summary: yes, both equally wrong! > > Might it work properly if you upgraded the boot sectors to version 2, > > which is what you should get if you reinstall from current boot0cfg, > > presumably without touching the MBR data, but you'll have backups .. > > Well ... > > root@hd45:~ # boot0cfg -B mirror/m0 > root@hd45:~ # boot0cfg -s 2 mirror/m0 > root@hd45:~ # boot0cfg -v mirror/m0 > # flag start chs type end chs offset size > 1 0x80 1: 0: 1 0xa5 1022:254:63 16065 16418430 > 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 > 3 0x00 1021: 0: 1 0xa5 768:254:63 32852925 1920667140 > > version=2.0 drive=0x80 mask=0xf ticks=182 bell=# (0x23) > options=packet,update,nosetdrv > volume serial ID b100-808f > default_selection=F2 (Slice 2) > > root@hd45:~ # boot0cfg -v ada0 > [...] > default_selection=F2 (Slice 2) > > root@hd45:~ # boot0cfg -v ada1 > [...] > default_selection=F2 (Slice 2) > > Revert the change: > > root@hd45:~ # boot0cfg -s 1 mirror/m0 > root@hd45:~ # boot0cfg -v mirror/m0 > [...] > default_selection=F1 (Slice 1) > > > That did it! These machines have been in production for some time > starting with FreeBSD 8.x and have been upgraded via NanoBSD style > dd followed by reboot all the time up to 10.3, now. Hence I never touched > the bootcode. Glad that one of my wild ill-informed wonderings was on target, and that gmirror is off the hook. > Actual reboot of this production machine in two weeks when we run our > regular updates. But I expect that to "just work". Warner expected the existing boot0cfg code to "just work" too. And it does, except that the upgrades to it failed to include a method to fix existing installations retrospectively! cheers, Ian From owner-freebsd-stable@freebsd.org Mon Oct 24 06:58:51 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55654C1FE63 for ; Mon, 24 Oct 2016 06:58:51 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (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 E5C7D39D for ; Mon, 24 Oct 2016 06:58:50 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [217.29.44.10]) by gate2.intern.punkt.de with ESMTP id u9O6wle9066025; Mon, 24 Oct 2016 08:58:47 +0200 (CEST) Received: from [217.29.44.130] ([217.29.44.130]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id u9O6wlDF064457; Mon, 24 Oct 2016 08:58:47 +0200 (CEST) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: boot0cfg on does not set default selection on gmirror device From: "Patrick M. Hausen" In-Reply-To: <20161024133403.D6806@sola.nimnet.asn.au> Date: Mon, 24 Oct 2016 08:59:17 +0200 Cc: freebsd-stable Content-Transfer-Encoding: quoted-printable Message-Id: <7273E6C8-9462-4389-95B1-D94A15B5BC15@punkt.de> References: <14FD5FE6-6277-4EBE-8EE9-630A735F8BEA@punkt.de> <54B556F6-B834-4B0C-A9A4-90B9AD80A668@punkt.de> <20161022140755.S6806@sola.nimnet.asn.au> <20161024133403.D6806@sola.nimnet.asn.au> To: Ian Smith X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 06:58:51 -0000 Hi, all, > Am 24.10.2016 um 04:50 schrieb Ian Smith : >=20 > On Sun, 23 Oct 2016 15:53:59 +0200, Patrick M. Hausen wrote: >=20 >> Actual reboot of this production machine in two weeks when we run our >> regular updates. But I expect that to "just work". >=20 > Warner expected the existing boot0cfg code to "just work" too. And it=20= > does, except that the upgrades to it failed to include a method to fix=20= > existing installations retrospectively! If the boot0 code 2.0 was severely broken, don't you think we would have noticed? ;-) One more thing, I just checked: the machines for which it did work all the time are indeed younger and all have the 2.0 bootcode. Thanks for your help. Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=C3=BCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@freebsd.org Mon Oct 24 16:11:24 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A19BC1FA1B for ; Mon, 24 Oct 2016 16:11:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-43.reflexion.net [208.70.210.43]) (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 1FEDAFE7 for ; Mon, 24 Oct 2016 16:11:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21015 invoked from network); 24 Oct 2016 16:05:32 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Oct 2016 16:05:32 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Mon, 24 Oct 2016 12:04:41 -0400 (EDT) Received: (qmail 10367 invoked from network); 24 Oct 2016 16:04:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Oct 2016 16:04:40 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AE0A5EC9091; Mon, 24 Oct 2016 09:04:35 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Subject: BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . . Message-Id: Date: Mon, 24 Oct 2016 09:04:35 -0700 To: freebsd-arm , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3226) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 16:11:24 -0000 The is for a Banana Pi M3 V1.2 board with the barrel power connector. = The 5V 2A supply that I had to fit the barrel hole can not power the = board sufficiently to boot --even when no fan is being powered. In order = to boot with a fan I have both that and an official rpi3 power supply = plugged in. The rpi3 power supply will not power the GPIO fan = connections but can boot the board by itself (V5.1v and 2.5A but cell = phone charger cabling/connections). I've got a heat sink on the CPU as = well. > root@bananapi-m3:~ # uname -apKU > FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon = Oct 24 00:41:16 PDT 2016 = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm armv6 1100505 1 > 100505 > root@bananapi-m3:~ # freebsd-version -ku > 11.0-STABLE > 11.0-STABLE In the below note that "FreeBSD/SMP: Multiprocessor System Detected: 4 = CPUs" but cpulist0 shows cpu0 through cpu7. For now: So much for seeing = how buildworld/buildkernel would go using all 8 cores. (Note: the serial connection tends to drop some text sometimes. That may = have happened some for the below.) > root@bananapi-m3:~ # dmesg | more > 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-STABLE #0 r307797M: Mon Oct 24 00:41:16 PDT 2016 > = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on = LLVM 3.8.0) > VT: init without driver. > CPU: Cortex A7 rev 5 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB enabled LABT branch prediction disabled > LoUU:2 LoC:3 LoUIS:2=20 > Cache level 1:=20 > 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc > 32KB/32B 2-way instruction cache Read-Alloc > Cache level 2:=20 > 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc > real memory =3D 2147483648 (2048 MB) > avail memory =3D 2090852352 (1993 MB) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > aw_ccu0: on ofwbus0 > clk_fixed0: on aw_ccu0 > clk_fixed1: mem 0x1c20028-0x1c2002b on aw_ccu0 > clk_fixed3: on aw_ccu0 > aw_ahbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 > aw_apbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 > aw_apbclk1: mem 0x1c20058-0x1c2005b on aw_ccu0 > aw_ahbclk1: mem 0x1c2005c-0x1c2005f on aw_ccu0 > aw_gate0: mem 0x1c20060-0x1c2006f on = aw_ccu0 > aw_mmcclk0: mem 0x1c20088-0x1c2clk1: mem 0x1c2008c-0x1c2008f on aw_ccu0 > aw_mmcclk2: mem 0x1c20090-0x1c20093 on aw_ccu0 > aw_cpusclk0: mem 0x1f01400-0x1f01403 on aw_ccu0 > clk_fixed4: on aw_ccu0 > aw_apbclk2: mem 0x1f0140c-0x1f0140f on aw_ccu0 > aw_gate1: mem 0x1f01428-0x1f0142b on = aw_ccu0 > aw_pll1: mem 0x1c20044-0x1c20047 on aw_ccu0 > aw_usbclk0: mem 0x1c200cc-0x1c200cf on aw_ccu0 > clk_fixed5: mem 0x1c00030-0x1c00033 on aw_ccu0 > simplebus0: on ofwbus0 > aw_reset0: mem 0x1c202c0-0x1c202cb on = simplebus0 > aw_reset1: mem 0x1c202d0-0x1c202d3 on = simplebus0 > aw_reset2: mem 0x1c202d8-0x1c202db on = simplebus0 > aw_reset3: mem 0x1f014b0-0x1f014b3 on = simplebus0 > iichb0: mem = 0x1c2ac00-0x1c2afff on simplebus0 > iicbus0: hb0 > iichb1: mem = 0x1c2b000-0x1c2b3ff on simplebus0 > iicbus1: on iichb1 > iichb2: mem = 0x1c2b400-0x1c2b7ff on simplebus0 > iicbus2: on iichb2 > regfix0: on ofwbus0 > regfix1: on ofwbus0 > regfix2: on ofwbus0 > regfix3: on ofwbus0 > regfix4: on ofwbus0 > aw_sid0: mem 0x1c14000-0x1c143ff on = simplebus0 > awusbphy0: on simplebu,0x1c86000-0x1c87fff on = simplebus0 > gic0: pn 0x20, arch 0x2, rev 0x1, implementer 0x43b irqs 224 > gpio0: mem 0x1c20800-0x1c20bff on = simplebus0 > gpiobus0: on gpio0 > gpio1: mem 0x1f02c00-0x1f02fff on = simplebus0 > gpiobus1: on gpio1 > aw_nmi0: mem 0x1f00c0c-0x1f00c43 on = simplebus0 > generic_timer0: on ofwbus0 > Timecounter "cy 24000000 Hz quality 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpu1: on cpulist0 > cpu2: on cpulist0 > cpu3: on cpulist0 > cpu4: on cpulist0 > cpu5: on cpulist0 > cpu6: on cpulist0 > cpu7: on cpulist0 > a10_mmc0: mem = 0x1c0f000-0x1c0ffff on simplebus0 > mmc0: on a10_mmc0 > a10_mmc1: mem = 0x1c11000-0x1c11fff on simplebus0 > mmc1: on a10_mmc1 > gpioc0: on gpio0 > aw_wdog0: mem 0x1c20ca0-0x1c20cbf on = simplebus0 > uart0: mem = 0x1c28000-0x1c283ff on simplebus0 > uart0: console (480769,n,8,1) > gpioc1: on gpio1 > iichb3: mem 0x1f03400-0x1f037ff on simplebus0 > iicbus3: on iichb3 > iic0: on iicbus3 > axp81x_pmu0: at addr 0x746 on = iicbus3 > gpiobus2: on axp81x_pmu0 > gpioled0: at pin 0 on gpiobus2 > gpioled1: at pin 1 on gpiobus2 > gpioc2: on axp81x_pmu0 > iic1: on iicbus0 > iic2: on iicbus1 > iic3: on iicbus2 > ehci0: mem = 0x1c1a000-0x1c1a0ff on simplebus0 > usbus0: EHCI version 1.0 > usbus0 on ehci0 > ehci1: mem = 0x1c1b000-0x1c1b0ff on simplebus0 > usbus1: EHCI version 1.0 > usbus1 on ehci1 > awg0: mem 0x1c30000-0x1c300ff on = simplebus0 > miibus0: on awg0 > rgephy0: PHY 0 on = miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FD > X-flow-master, auto, auto-flow > rgephy1: PHY 1 on = miibus0 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FD > X-flow-master, auto, auto-flow > awg0: Ethernet address: f2:00:52:68:6d:d8 > aw_thermal0: mem = 0x1f04000-0x1f043ff on simplebus0 > cryptosoft0: > Timecounters tick every 10.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > ugen1.1: at usbus1 > ugen0.1: at usbus0 > uhub0: on = usbus0 > uhub1: on = usbus1 > mmcsd0: 32GB at mmc0 = 50.0MHz/4bit/65535-block > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00008018 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > a10_mmc1: error rint: 0x00000100 > mmcsd1: 8GB at = mmc1 50.0MHz/8bit/65535-block > Release APs > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > warning: no time-of-day clock registered, system time will not be set = accurately > uhub0: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > ugen0.2: at usbus0 > uhub2 on uhub0 > uhub2: = on usbus0 > uhub2: 4 ports with 4 removable, self powered > ugen0.3: at usbus0 > umass0 on uhub2 > umass0: = on usbus0 > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (probe0:umass-sim0:0:0:0): Retrying command > random: unblocking device. > awg0: link state changed to DOWN > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (probe0:umass-sim0:0:0:0): Retrying command > awg0: link state changed to UP > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (probe0:umass-sim0:0:0:0): Retrying command > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (probe0:umass-sim0:0:0:0): Retrying command > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted So far the probe0 messages stop after just a few like the above. Also it looks like the 8GB eMMC (mmc1 / mmcsd1) is likely not supported = yet. I have not yet tried connecting an external usb drive. Some structure of what was done with the cores shows in the sysctl -a = output: cpu names 0-3 and 100-103. (Note: the serial connection tends to drop some text sometimes. That may = have happened some for the below.) > root@bananapi-m3:~ # sysctl -a | grep cpu > kern.smp.cpus: 4 > kern.smp.maxcpus: 4 > kern.ccpu: 0 > 0, 1, 2, 3 > 0, 1, 2, 3 > kern.sched.cpusetsize: 4 > kern.pin_pcpu_swi: 0 > kern.vt.splash_cpu_duration: 10 > kern.vt.splash_cpu_style: 2 > kern.vt.splash_ncpu: 0 > kern.vt.splash_cpu: 0 > net.inet.tcp.per_cpu_timers: 0 > debug.PMAP1changedcpu: 106 > debug.cpufreq.verbose: 0 > debug.cpufreq.lowest: 0 > hw.ncpu: 4 > dev.cpu.7.%parent: cpulist0 > dev.cpu.7.%pnpinfo: name=3Dcpu@103 compat=3Darm,cortex-a7 > dev.cpu.7.%location:=20 > dev.cpu.7.%driver: cpu > dev.cpu.7.%desc: Open Firmware CPU > dev.cpu.6.%parent: cpulist0 > dev.cpu.6.%pnpinfo: name=3Dcpu@102 compat=3Darm,cortex-a7 > dev.cpu.6.%location:=20 > dev.cpu.6.%driver: cpu > dev.cpu.6.%desc: Open Firmware CPU > dev.cpu.5.%parent: cpulist0 > dev.cpu.5.%pnpinfo: name=3Dcpu@101 compat=3Darm,cortex-a7 > dev.cpu.5.%location:=20 > dev.cpu.5.%dri.5.%desc: Open Firmware CPU > dev.cpu.4.%parent: cpulist0 > dev.cpu.4.%pnpinfo: name=3Dcpu@100 compat=3Darm,cortex-a7 > dev.cpu.4.%location:=20 > dev.cpu.4.%driver: cpu > dev.cpu.4.%desc: Open Firmware CPU > dev.cpu.3.%parent: cpulist0 > dev.cpu.3.%pnpinfo: name=3Dcpu@3 compat=3Darm,cortex-a7 > dev.cpu.3.%location:=20 > dev.cpu.3.%driver: cpu > dev.cpu.3.%desc: Open Firmware CPU > dev.cpu.2.%parent: cpulist0 > dev.cpu.2.%pnpinfo: name=3Dcpu@2 compat=3Darm,cortex-a7 > dev.cpu.2.%location:=20 > dev.cpu.2.%driver: cpu > dev.cpu.2.%desc: Open Firmware CPU > dev.cpu.1.%parent: cpulist0 > dev.cpu.1.%location:=20 > dev.cpu.1.%driver: cpu > dev.cpu.1.%desc: Open Firmware CPU > dev.cpu.0.%parent: cpulist0 > dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,cortex-a7 > dev.cpu.0.%location:=20 > dev.cpu.0.%driver: cpu > dev.cpu.0.%desc: Open Firmware CPU > dev.cpu.0.%parent: cpulist0 > dev.cpulist.0.%parent: ofwbus0 > dev.cpulist.0.%pnpinfo: name=3Dcpus > dev.cpulist.0.%location:=20 > dev.cpulist.0.%driver: cpulist > dev.cpulist.0.%desc: Open Firmware CPU Group > dev.cpulist.%parent:=20 > dev.aw_cpusclk.0.%parent: aw_ccu0 > dev.aw_cpusclk.0.%pnpinfo: name=3Dclk@01f0140inner,sun8i-a83t-cpus-clk > dev.aw_cpusclk.0.%location:=20 > dev.aw_cpusclk.0.%driver: aw_cpusclk > dev.aw_cpusclk.0.%desc: Allwinner CPUS Clock > dev.aw_cpusclk.%parent:=20 > security.jail.param.cpuset.id: 0 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Mon Oct 24 17:06:00 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A2A9C1FDC1 for ; Mon, 24 Oct 2016 17:06:00 +0000 (UTC) (envelope-from v.velox@vvelox.net) Received: from vulpes.vvelox.net (vulpes.vvelox.net [96.95.67.25]) by mx1.freebsd.org (Postfix) with ESMTP id ADA03F90 for ; Mon, 24 Oct 2016 17:05:59 +0000 (UTC) (envelope-from v.velox@vvelox.net) Received: from vixen42.vulpes.vvelox.net (vixen42.vulpes.vvelox.net [192.168.15.2]) (Authenticated sender: kitsune) by vulpes.vvelox.net (Postfix) with ESMTPA id 2653C3791110 for ; Mon, 24 Oct 2016 12:05:38 -0500 (CDT) Date: Mon, 24 Oct 2016 12:05:52 -0500 From: "Zane C. B-H." To: freebsd-stable@FreeBSD.org Subject: bsnmpd going crazy on 10-STABLE Message-ID: <20161024120552.718c369d@vixen42.vulpes.vvelox.net> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 17:06:00 -0000 Restarted a machine and post restart I began seeing the stuff below when watch it via truss. It just keeps looping over and over doing stuff like that while eating up lots of CPU time. I've checked the configs between both machines and they are both the same. I've tried updating usr.sbin/bsnmpd and lib/libbsnmp to the newest versions, but that seems to have zero affect on it. Any thoughts? openat(AT_FDCWD,"/dev/da2",O_NONBLOCK,00) = 16 (0x10) ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xffffb578) = 0 (0x0) __sysctl(0x7fffffffb480,0x2,0x7fffffffb4bc,0x7fffffffb4b0,0x8055b7eaa,0x11) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x0,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x8066c9000,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) gettimeofday({ 1477327808.091871 },0x0) = 0 (0x0) getpid() = 42507 (0xa60b) close(16) = 0 (0x0) openat(AT_FDCWD,"/dev/da1",O_NONBLOCK,00) = 16 (0x10) ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xffffb578) = 0 (0x0) __sysctl(0x7fffffffb480,0x2,0x7fffffffb4bc,0x7fffffffb4b0,0x8055b7eaa,0x11) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x0,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x8066c9000,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) gettimeofday({ 1477327808.096923 },0x0) = 0 (0x0) getpid() = 42507 (0xa60b) close(16) = 0 (0x0) openat(AT_FDCWD,"/dev/da0",O_NONBLOCK,00) = 16 (0x10) ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xffffb578) = 0 (0x0) __sysctl(0x7fffffffb480,0x2,0x7fffffffb4bc,0x7fffffffb4b0,0x8055b7eaa,0x11) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x0,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x8066c9000,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) gettimeofday({ 1477327808.102461 },0x0) = 0 (0x0) getpid() = 42507 (0xa60b) close(16) = 0 (0x0) openat(AT_FDCWD,"/dev/cd0",O_NONBLOCK,00) = 16 (0x10) ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xffffb578) ERR#2 'No such file or directory' close(16) = 0 (0x0) gettimeofday({ 1477327808.109391 },0x0) = 0 (0x0) gettimeofday({ 1477327808.109529 },0x0) = 0 (0x0) select(16,{ 6 12 14 15 },{ },{ },{ 0.155257 }) = 1 (0x1) read(12,"!system=CAM subsystem=periph typ"...,512) = 167 (0xa7) __sysctl(0x7fffffffb4f0,0x2,0x7fffffffb530,0x7fffffffb528,0x8053b3586,0xb) = 0 (0x0) __sysctl(0x7fffffffb530,0x3,0x7fffffffb618,0x7fffffffb610,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb6b8,0x2,0x7fffffffb620,0x7fffffffb850,0x8053b365e,0xe) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) From owner-freebsd-stable@freebsd.org Mon Oct 24 17:10:55 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C65F8C1FFEA for ; Mon, 24 Oct 2016 17:10:55 +0000 (UTC) (envelope-from vvelox@vvelox.net) Received: from vulpes.vvelox.net (vulpes.vvelox.net [96.95.67.25]) by mx1.freebsd.org (Postfix) with ESMTP id 370FE1609 for ; Mon, 24 Oct 2016 17:10:54 +0000 (UTC) (envelope-from vvelox@vvelox.net) Received: from vixen42.vulpes.vvelox.net (vixen42.vulpes.vvelox.net [192.168.15.2]) (Authenticated sender: kitsune) by vulpes.vvelox.net (Postfix) with ESMTPA id 0737D3791126 for ; Mon, 24 Oct 2016 12:00:31 -0500 (CDT) Date: Mon, 24 Oct 2016 12:00:45 -0500 From: "Zane C. B-H." To: freebsd-stable@FreeBSD.org Subject: bsnmpd going crazy on 10-STABLE Message-ID: <20161024120045.2fd49211@vixen42.vulpes.vvelox.net> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 17:10:55 -0000 Restarted a machine and post restart I began seeing the stuff below when watch it via truss. It just keeps looping over and over doing stuff like that while eating up lots of CPU time. I've checked the configs between both machines and they are both the same. I've tried updating usr.sbin/bsnmpd and lib/libbsnmp to the newest versions, but that seems to have zero affect on it. Any thoughts? openat(AT_FDCWD,"/dev/da2",O_NONBLOCK,00) = 16 (0x10) ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xffffb578) = 0 (0x0) __sysctl(0x7fffffffb480,0x2,0x7fffffffb4bc,0x7fffffffb4b0,0x8055b7eaa,0x11) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x0,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x8066c9000,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) gettimeofday({ 1477327808.091871 },0x0) = 0 (0x0) getpid() = 42507 (0xa60b) close(16) = 0 (0x0) openat(AT_FDCWD,"/dev/da1",O_NONBLOCK,00) = 16 (0x10) ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xffffb578) = 0 (0x0) __sysctl(0x7fffffffb480,0x2,0x7fffffffb4bc,0x7fffffffb4b0,0x8055b7eaa,0x11) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x0,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x8066c9000,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) gettimeofday({ 1477327808.096923 },0x0) = 0 (0x0) getpid() = 42507 (0xa60b) close(16) = 0 (0x0) openat(AT_FDCWD,"/dev/da0",O_NONBLOCK,00) = 16 (0x10) ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xffffb578) = 0 (0x0) __sysctl(0x7fffffffb480,0x2,0x7fffffffb4bc,0x7fffffffb4b0,0x8055b7eaa,0x11) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x0,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb4bc,0x3,0x8066c9000,0x7fffffffb4c8,0x0,0x0) = 0 (0x0) gettimeofday({ 1477327808.102461 },0x0) = 0 (0x0) getpid() = 42507 (0xa60b) close(16) = 0 (0x0) openat(AT_FDCWD,"/dev/cd0",O_NONBLOCK,00) = 16 (0x10) ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xffffb578) ERR#2 'No such file or directory' close(16) = 0 (0x0) gettimeofday({ 1477327808.109391 },0x0) = 0 (0x0) gettimeofday({ 1477327808.109529 },0x0) = 0 (0x0) select(16,{ 6 12 14 15 },{ },{ },{ 0.155257 }) = 1 (0x1) read(12,"!system=CAM subsystem=periph typ"...,512) = 167 (0xa7) __sysctl(0x7fffffffb4f0,0x2,0x7fffffffb530,0x7fffffffb528,0x8053b3586,0xb) = 0 (0x0) __sysctl(0x7fffffffb530,0x3,0x7fffffffb618,0x7fffffffb610,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb6b8,0x2,0x7fffffffb620,0x7fffffffb850,0x8053b365e,0xe) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffb620,0x5,0x7fffffffb6c0,0x7fffffffb848,0x0,0x0) = 0 (0x0) From owner-freebsd-stable@freebsd.org Mon Oct 24 17:16:03 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 963AFC1E45C for ; Mon, 24 Oct 2016 17:16:03 +0000 (UTC) (envelope-from v.velox@vvelox.net) Received: from vulpes.vvelox.net (vulpes.vvelox.net [96.95.67.25]) by mx1.freebsd.org (Postfix) with ESMTP id 536CF1C16 for ; Mon, 24 Oct 2016 17:16:02 +0000 (UTC) (envelope-from v.velox@vvelox.net) Received: from vixen42.vulpes.vvelox.net (vixen42.vulpes.vvelox.net [192.168.15.2]) (Authenticated sender: kitsune) by vulpes.vvelox.net (Postfix) with ESMTPA id 73155379112D for ; Mon, 24 Oct 2016 12:15:41 -0500 (CDT) Date: Mon, 24 Oct 2016 12:15:55 -0500 From: "Zane C. B-H." To: freebsd-stable@FreeBSD.org Subject: Re: bsnmpd going crazy on 10-STABLE Message-ID: <20161024121555.4062c845@vixen42.vulpes.vvelox.net> In-Reply-To: <20161024120552.718c369d@vixen42.vulpes.vvelox.net> References: <20161024120552.718c369d@vixen42.vulpes.vvelox.net> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 17:16:03 -0000 On Mon, 24 Oct 2016 12:05:52 -0500 "Zane C. B-H." wrote: > Commenting out the line below seems to have fixed it on the system in question... begemotSnmpdModulePath."hostres" = "/usr/lib/snmp_hostres.so" Not sure why it is not behaving on only one 10-STABLE system. From owner-freebsd-stable@freebsd.org Mon Oct 24 17:34:13 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D8B2C1ECDD for ; Mon, 24 Oct 2016 17:34:13 +0000 (UTC) (envelope-from jamie@dyslexicfish.net) Received: from dyslexicfish.net (deadcat.mail.dyslexicfish.net [45.63.12.202]) (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 C7804CC9 for ; Mon, 24 Oct 2016 17:34:12 +0000 (UTC) (envelope-from jamie@dyslexicfish.net) Received: from dyslexicfish.net (deadcat.mail.dyslexicfish.net [45.63.12.202]) by dyslexicfish.net (8.14.5/8.14.5) with ESMTP id u9OHGHqG069235; Mon, 24 Oct 2016 18:16:17 +0100 (BST) (envelope-from jamie@dyslexicfish.net) Received: (from jamie@localhost) by dyslexicfish.net (8.14.5/8.14.5/Submit) id u9OHGGUA069234; Mon, 24 Oct 2016 18:16:16 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201610241716.u9OHGGUA069234@dyslexicfish.net> Date: Mon, 24 Oct 2016 18:16:16 +0100 To: freebsd-stable@freebsd.org, bennett@sdf.org Cc: emz@norma.perm.ru Subject: Re: zfs, a directory that used to hold lot of files and listing pause References: <201610211340.u9LDer6D018453@sdf.org> In-Reply-To: <201610211340.u9LDer6D018453@sdf.org> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (dyslexicfish.net [45.63.12.202]); Mon, 24 Oct 2016 18:16:17 +0100 (BST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 17:34:13 -0000 Scott Bennett wrote: > thousand blocks allocated. Directories don't shrink. Directory entries do > not get moved around within directories when files are added or deleted. > Directories can remain the same length or they can grow in length. If a > directory once had many tens of thousands of filenames and links to their > primary inodes, then the directory is still that big, even if it now only > contains two [+ 20 to 30 directory], probably widely separated, entries. > IOW, if you want the performance to go back to what it was when the directory > was fresh (and still small), you have to create a new directory and then move > the remaining entries from the old directory into the new (small) directory. Not entirely true. FreeBSD on UFS *will* *truncate* directories where possible, each time a new directory entry is made, and there is contiguous unused space to the end of the directory-file. [ As an aside, tmpfs does 'defragment' and rezise directories in real time, when a file from *any* location is deleted. ] Back to UFS (I don't know about ZFS): So, whilst you are right about directory entries not being moved around, consider the following. Note the size of '.' in each directory listing: | 17:05 [2] (1) "~" jamie@lapcat% md dir | dir | | 17:05 [2] (2) "~" jamie@lapcat% cd dir | | 17:05 [2] (3) "~/dir" jamie@lapcat% l | total 8 | 4 drwxr-xr-x 2 jamie jamie - 512 24 Oct 17:05 ./ | 4 drwx------ 72 jamie jamie - 3072 24 Oct 17:05 ../ | | 17:05 [2] (4) "~/dir" jamie@lapcat% jot 999 1 999 | awk '{printf "touch %03d\n", $1}' | sh | | 17:05 [2] (5) "~/dir" jamie@lapcat% l | head | total 16 | 12 drwxr-xr-x 2 jamie jamie - 12288 24 Oct 17:05 ./ | 4 drwx------ 72 jamie jamie - 3072 24 Oct 17:05 ../ | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 001 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 002 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 003 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 004 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 005 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 006 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 007 | | *141* 17:05 [2] (6) "~/dir" jamie@lapcat% rm [678]* | remove 300 files? y | | 17:06 [2] (7) "~/dir" jamie@lapcat% l | head | total 16 | 12 drwxr-xr-x 2 jamie jamie - 12288 24 Oct 17:06 ./ | 4 drwx------ 72 jamie jamie - 3072 24 Oct 17:05 ../ | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 001 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 002 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 003 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 004 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 005 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 006 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 007 | | *141* 17:06 [2] (8) "~/dir" jamie@lapcat% touch x; rm x | | 17:06 [2] (9) "~/dir" jamie@lapcat% l | head | total 16 | 12 drwxr-xr-x 2 jamie jamie - 12288 24 Oct 17:06 ./ | 4 drwx------ 72 jamie jamie - 3072 24 Oct 17:05 ../ | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 001 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 002 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 003 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 004 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 005 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 006 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 007 | | *141* 17:06 [2] (10) "~/dir" jamie@lapcat% rm 9* | remove 100 files? y | | 17:06 [2] (11) "~/dir" jamie@lapcat% l | head | total 16 | 12 drwxr-xr-x 2 jamie jamie - 12288 24 Oct 17:06 ./ | 4 drwx------ 72 jamie jamie - 3072 24 Oct 17:05 ../ | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 001 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 002 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 003 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 004 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 005 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 006 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 007 | | *141* 17:06 [2] (12) "~/dir" jamie@lapcat% touch x ; rm x | | 17:06 [2] (13) "~/dir" jamie@lapcat% l | head | total 12 | 8 drwxr-xr-x 2 jamie jamie - 7680 24 Oct 17:06 ./ | 4 drwx------ 72 jamie jamie - 3072 24 Oct 17:05 ../ | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 001 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 002 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 003 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 004 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 005 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 006 | 0 -rw-r--r-- 1 jamie jamie - 0 24 Oct 17:05 007 | | *141* 17:06 [2] (14) "~/dir" jamie@lapcat% rm * | remove 599 files? y | | 17:06 [2] (15) "~/dir" jamie@lapcat% l | total 12 | 8 drwxr-xr-x 2 jamie jamie - 7680 24 Oct 17:06 ./ | 4 drwx------ 72 jamie jamie - 3072 24 Oct 17:05 ../ | | 17:06 [2] (16) "~/dir" jamie@lapcat% touch x ; rm x | | 17:06 [2] (17) "~/dir" jamie@lapcat% l | total 8 | 4 drwxr-xr-x 2 jamie jamie - 512 24 Oct 17:06 ./ | 4 drwx------ 72 jamie jamie - 3072 24 Oct 17:05 ../ | | 17:07 [2] (18) "~/dir" jamie@lapcat% exit From owner-freebsd-stable@freebsd.org Mon Oct 24 17:57:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 603C6C1F574 for ; Mon, 24 Oct 2016 17:57:36 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail-out.smeets.xyz (mail-out.smeets.xyz [IPv6:2a01:4f8:160:918a::25:11]) (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 ED297F64 for ; Mon, 24 Oct 2016 17:57:35 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail.smeets.xyz (mail.smeets.xyz [IPv6:2a01:4f8:160:918a::25:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-out.smeets.xyz (Postfix) with ESMTPS id DCB92896D2; Mon, 24 Oct 2016 19:57:32 +0200 (CEST) Received: from amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:160:918a::aa:4]) by mail.smeets.xyz (Postfix) with ESMTP id 80D569CC34; Mon, 24 Oct 2016 19:57:32 +0200 (CEST) Authentication-Results: mail.smeets.xyz; dkim=pass (1024-bit key; unprotected) header.d=smeets.xyz header.i=@smeets.xyz header.b=E+7WTile X-Virus-Scanned: amavisd-new at smeets.xyz Received: from mail.smeets.xyz ([IPv6:2a01:4f8:160:918a::25:3]) by amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:160:918a::aa:4]) (amavisd-new, port 10025) with ESMTP id WQ-H7gTs2EQu; Mon, 24 Oct 2016 19:57:27 +0200 (CEST) Received: from nibbler-osx.fritz.box (unknown [IPv6:2001:4dd0:fd65:0:a4f7:8396:d518:22fb]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.smeets.xyz (Postfix) with ESMTPSA id DF5DF9CC0D; Mon, 24 Oct 2016 19:57:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=smeets.xyz; s=default; t=1477331847; bh=DkGL07Sf+9LsE0zkahSDSCQGXGuEP+V1VXbg6DNvULY=; h=Subject:To:References:From:Date:In-Reply-To; b=E+7WTileOmziQfYWxP4c8H8buJlgN1DwhcXNasUW2W0aKH4nfhZkukoEJTrsj240M tQImNzovpz73jP6672B5P/0/jcAJnv6FL6qQv04fwlb3AlKwwvEvo7bwFpxVPIsmHq jAogLtZ5vO85byshdTqFPtQ4HN1ymzADtEVuL3zI= Subject: Re: bsnmpd going crazy on 10-STABLE To: "Zane C. B-H." , freebsd-stable@FreeBSD.org References: <20161024120552.718c369d@vixen42.vulpes.vvelox.net> <20161024121555.4062c845@vixen42.vulpes.vvelox.net> From: Florian Smeets Message-ID: Date: Mon, 24 Oct 2016 19:57:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: <20161024121555.4062c845@vixen42.vulpes.vvelox.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OTQKOTMEdKetDOq4iD5UTD7otaLv5h4U7" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 17:57:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OTQKOTMEdKetDOq4iD5UTD7otaLv5h4U7 Content-Type: multipart/mixed; boundary="dj1J5grUuTrWIaox77wWWJFni4uAtatKJ"; protected-headers="v1" From: Florian Smeets To: "Zane C. B-H." , freebsd-stable@FreeBSD.org Message-ID: Subject: Re: bsnmpd going crazy on 10-STABLE References: <20161024120552.718c369d@vixen42.vulpes.vvelox.net> <20161024121555.4062c845@vixen42.vulpes.vvelox.net> In-Reply-To: <20161024121555.4062c845@vixen42.vulpes.vvelox.net> --dj1J5grUuTrWIaox77wWWJFni4uAtatKJ Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 24/10/2016 19:15, Zane C. B-H. wrote: > On Mon, 24 Oct 2016 12:05:52 -0500 > "Zane C. B-H." wrote: >=20 >> >=20 > Commenting out the line below seems to have fixed it on the system in > question... >=20 > begemotSnmpdModulePath."hostres" =3D "/usr/lib/snmp_hostres.so" >=20 > Not sure why it is not behaving on only one 10-STABLE system. You need the patch from [1] unfortunately nobody committed it, yet. According the the PR it seems to be somewhat of a workaround. I have been running with it for 3 months now on stable/11. HTH, Florian [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209368 --dj1J5grUuTrWIaox77wWWJFni4uAtatKJ-- --OTQKOTMEdKetDOq4iD5UTD7otaLv5h4U7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJYDkuEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNzAxMDMyMDNCQ0FCNDRBOThGRUM4NDRF NzA1M0RGOUZGODZGMDc2AAoJEOcFPfn/hvB2QQMP/1QT9K9yHnBfRRAHV0XBfmot ZOPMfiA13aNQwC/PZ7OKFu95QkVV656OLac9gOPjmvyb6RvnW33DhfzKF+B59rnV YlWZcfQ7a1qK6J4fuH3ptofyx4g+Mh3Wg12S3kzWlEQpl/ASgxtajZ1rmrdkWHWb ZkMeM5sXb326WKKj7EVDSaWqFWhCBRzyZ+36bvLQbaYOkFL4SyJyPwJ30nMjvNFu zok0lc+MZ/Ty7RqVEzqzwpd1RnKyxtK6LINJQ0UAds2AiMVMYicCGXvQIFxWHgbJ m/Lup1fnfjsJjFEi3hC204QqF9xWakX0oWbDN3bFtuo/vWD1u4glpJoAEjxI+A8Y f590Y1JxscgWg5H1QdJmb0eOXpbjc3Wo9ndw0rYnHNLP5fbA3dkEFzpmY+KYiEmL Fg9azU712oG2PT+4qYJpQVpRgB9kZmHoymq6JEH6QPfZAWUp7qGzQ1DBmlueSuji ituXFwjtXy+vAohepnN2XMCHzt2cWrCuw4e/1eoq1+mvnSYU+aHRjID8YNkIKyaZ Ve7bl5qJTcq0jeLE0iAcjcJy7Yo0vMv3sHroqMyIw/cY5oY5EhHLoHb1tv/irEri PXjXGj4SqH6+AIVGvp10qhGYrlidegShl6X3E6CMrMjpW+CDsPxq2P8a3DbDXe09 /rdPXxy+2qCCGLtZujkd =cxoj -----END PGP SIGNATURE----- --OTQKOTMEdKetDOq4iD5UTD7otaLv5h4U7-- From owner-freebsd-stable@freebsd.org Mon Oct 24 19:18:05 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45FD0C1F535 for ; Mon, 24 Oct 2016 19:18:05 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1.freebsd.org (Postfix) with ESMTP id 368162B2 for ; Mon, 24 Oct 2016 19:18:04 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from static.162.255.23.37.macminivault.com (unknown [162.255.23.37]) by mbob.nabble.com (Postfix) with ESMTP id D66E03467353 for ; Mon, 24 Oct 2016 12:10:48 -0700 (PDT) Date: Mon, 24 Oct 2016 12:18:03 -0700 (MST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1477336683660-6139235.post@n6.nabble.com> In-Reply-To: <1477116241463-6138664.post@n6.nabble.com> References: <1477115469564-6138663.post@n6.nabble.com> <1477116241463-6138664.post@n6.nabble.com> Subject: Re: moused(?) touchpad issue after updating to FreeBSD 11.0-STABLE #0 r307755 amd64 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 19:18:05 -0000 It looks to me, that something in this commit- https://svnweb.freebsd.org/base?view=revision&revision=307576 forced me to explicitly set extended synaptics support- hw.psm.synaptics_support: 1 to use normal tapping. It works now, albeit with all additional synaptics extensions. -- View this message in context: http://freebsd.1045724.x6.nabble.com/moused-touchpad-issue-after-updating-to-FreeBSD-11-0-STABLE-0-r307755-amd64-tp6138663p6139235.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@freebsd.org Mon Oct 24 20:33:06 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E53FC20F05 for ; Mon, 24 Oct 2016 20:33:06 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1.freebsd.org (Postfix) with ESMTP id 6EEA7896 for ; Mon, 24 Oct 2016 20:33:05 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from static.162.255.23.37.macminivault.com (unknown [162.255.23.37]) by mbob.nabble.com (Postfix) with ESMTP id C454A346854D for ; Mon, 24 Oct 2016 13:25:49 -0700 (PDT) Date: Mon, 24 Oct 2016 13:33:05 -0700 (MST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1477341184996-6139267.post@n6.nabble.com> In-Reply-To: <1477336683660-6139235.post@n6.nabble.com> References: <1477115469564-6138663.post@n6.nabble.com> <1477116241463-6138664.post@n6.nabble.com> <1477336683660-6139235.post@n6.nabble.com> Subject: Re: moused(?) touchpad issue after updating to FreeBSD 11.0-STABLE #0 r307755 amd64 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 20:33:06 -0000 $ moused -d -i all -p /dev/psm0 moused: proto params: f8 80 00 00 8 00 ff /dev/psm0 ps/2 sysmouse Synaptics Touchpad -- View this message in context: http://freebsd.1045724.x6.nabble.com/moused-touchpad-issue-after-updating-to-FreeBSD-11-0-STABLE-0-r307755-amd64-tp6138663p6139267.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@freebsd.org Mon Oct 24 21:07:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E283C200A5; Mon, 24 Oct 2016 21:07:36 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 68189C0F; Mon, 24 Oct 2016 21:07:34 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id f761b16e; Mon, 24 Oct 2016 23:00:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=NObBiWnkSHXzhJsYeMbtThvgX8o=; b=WdpggdEuUXTgBIMFVjQeSfyBncwB nBmemladcsVbuCrb/KrtGMwPYIBBFAji5b1hisQ7+E5tFnuZw45DjnsE1YIFcJtz SqL8zeNNndYvTN4RnyMSQSv6ztIgPq7hKlahfOfR04vYRIMemgTZWITfXrPH6Sa8 a3B02rHOIOddkV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=rJow6momRQs4gw4a2RhJRalhEWSI7lSiV3kndT2jLehJs9rvgDPR8tM8 Dn3jE44h+MEgNVwX2JJEP3JEsXE5biwjAddgbAJJ8A3pr8VZtrSYEC+LDa+i6UXB dlcJ7zBJ+5LdudIxIT7B5kHNv46HlE291XL+Ok9oCCUXQju0m4w= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id be95f39f TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 24 Oct 2016 23:00:52 +0200 (CEST) Date: Mon, 24 Oct 2016 23:00:48 +0200 From: Emmanuel Vadot To: Mark Millard Cc: freebsd-arm , FreeBSD-STABLE Mailing List Subject: Re: BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . . Message-Id: <20161024230048.a440664797abd796eac08243@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 21:07:36 -0000 Hello Mark, The A83T is BIG/Little IIRC and we don't support that. That's why you only see 4 cores on the 8. cpulist0 shows 8 core because every core in is the dtb. On Mon, 24 Oct 2016 09:04:35 -0700 Mark Millard wrote: > The is for a Banana Pi M3 V1.2 board with the barrel power connector. The 5V 2A supply that I had to fit the barrel hole can not power the board sufficiently to boot --even when no fan is being powered. In order to boot with a fan I have both that and an official rpi3 power supply plugged in. The rpi3 power supply will not power the GPIO fan connections but can boot the board by itself (V5.1v and 2.5A but cell phone charger cabling/connections). I've got a heat sink on the CPU as well. > > > root@bananapi-m3:~ # uname -apKU > > FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24 00:41:16 PDT 2016 markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER arm armv6 1100505 1 > > 100505 > > > root@bananapi-m3:~ # freebsd-version -ku > > 11.0-STABLE > > 11.0-STABLE > > In the below note that "FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs" but cpulist0 shows cpu0 through cpu7. For now: So much for seeing how buildworld/buildkernel would go using all 8 cores. > > (Note: the serial connection tends to drop some text sometimes. That may have happened some for the below.) > > > root@bananapi-m3:~ # dmesg | more > > 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-STABLE #0 r307797M: Mon Oct 24 00:41:16 PDT 2016 > > markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER arm > > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) > > VT: init without driver. > > CPU: Cortex A7 rev 5 (Cortex-A core) > > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > > WB enabled LABT branch prediction disabled > > LoUU:2 LoC:3 LoUIS:2 > > Cache level 1: > > 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc > > 32KB/32B 2-way instruction cache Read-Alloc > > Cache level 2: > > 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc > > real memory = 2147483648 (2048 MB) > > avail memory = 2090852352 (1993 MB) > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > random: entropy device external interface > > kbd0 at kbdmux0 > > ofwbus0: > > aw_ccu0: on ofwbus0 > > clk_fixed0: on aw_ccu0 > > clk_fixed1: mem 0x1c20028-0x1c2002b on aw_ccu0 > > clk_fixed3: on aw_ccu0 > > aw_ahbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 > > aw_apbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 > > aw_apbclk1: mem 0x1c20058-0x1c2005b on aw_ccu0 > > aw_ahbclk1: mem 0x1c2005c-0x1c2005f on aw_ccu0 > > aw_gate0: mem 0x1c20060-0x1c2006f on aw_ccu0 > > aw_mmcclk0: mem 0x1c20088-0x1c2clk1: mem 0x1c2008c-0x1c2008f on aw_ccu0 > > aw_mmcclk2: mem 0x1c20090-0x1c20093 on aw_ccu0 > > aw_cpusclk0: mem 0x1f01400-0x1f01403 on aw_ccu0 > > clk_fixed4: on aw_ccu0 > > aw_apbclk2: mem 0x1f0140c-0x1f0140f on aw_ccu0 > > aw_gate1: mem 0x1f01428-0x1f0142b on aw_ccu0 > > aw_pll1: mem 0x1c20044-0x1c20047 on aw_ccu0 > > aw_usbclk0: mem 0x1c200cc-0x1c200cf on aw_ccu0 > > clk_fixed5: mem 0x1c00030-0x1c00033 on aw_ccu0 > > simplebus0: on ofwbus0 > > aw_reset0: mem 0x1c202c0-0x1c202cb on simplebus0 > > aw_reset1: mem 0x1c202d0-0x1c202d3 on simplebus0 > > aw_reset2: mem 0x1c202d8-0x1c202db on simplebus0 > > aw_reset3: mem 0x1f014b0-0x1f014b3 on simplebus0 > > iichb0: mem 0x1c2ac00-0x1c2afff on simplebus0 > > iicbus0: hb0 > > iichb1: mem 0x1c2b000-0x1c2b3ff on simplebus0 > > iicbus1: on iichb1 > > iichb2: mem 0x1c2b400-0x1c2b7ff on simplebus0 > > iicbus2: on iichb2 > > regfix0: on ofwbus0 > > regfix1: on ofwbus0 > > regfix2: on ofwbus0 > > regfix3: on ofwbus0 > > regfix4: on ofwbus0 > > aw_sid0: mem 0x1c14000-0x1c143ff on simplebus0 > > awusbphy0: on simplebu,0x1c86000-0x1c87fff on simplebus0 > > gic0: pn 0x20, arch 0x2, rev 0x1, implementer 0x43b irqs 224 > > gpio0: mem 0x1c20800-0x1c20bff on simplebus0 > > gpiobus0: on gpio0 > > gpio1: mem 0x1f02c00-0x1f02fff on simplebus0 > > gpiobus1: on gpio1 > > aw_nmi0: mem 0x1f00c0c-0x1f00c43 on simplebus0 > > generic_timer0: on ofwbus0 > > Timecounter "cy 24000000 Hz quality 1000 > > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > > cpulist0: on ofwbus0 > > cpu0: on cpulist0 > > cpu1: on cpulist0 > > cpu2: on cpulist0 > > cpu3: on cpulist0 > > cpu4: on cpulist0 > > cpu5: on cpulist0 > > cpu6: on cpulist0 > > cpu7: on cpulist0 > > a10_mmc0: mem 0x1c0f000-0x1c0ffff on simplebus0 > > mmc0: on a10_mmc0 > > a10_mmc1: mem 0x1c11000-0x1c11fff on simplebus0 > > mmc1: on a10_mmc1 > > gpioc0: on gpio0 > > aw_wdog0: mem 0x1c20ca0-0x1c20cbf on simplebus0 > > uart0: mem 0x1c28000-0x1c283ff on simplebus0 > > uart0: console (480769,n,8,1) > > gpioc1: on gpio1 > > iichb3: mem 0x1f03400-0x1f037ff on simplebus0 > > iicbus3: on iichb3 > > iic0: on iicbus3 > > axp81x_pmu0: at addr 0x746 on iicbus3 > > gpiobus2: on axp81x_pmu0 > > gpioled0: at pin 0 on gpiobus2 > > gpioled1: at pin 1 on gpiobus2 > > gpioc2: on axp81x_pmu0 > > iic1: on iicbus0 > > iic2: on iicbus1 > > iic3: on iicbus2 > > ehci0: mem 0x1c1a000-0x1c1a0ff on simplebus0 > > usbus0: EHCI version 1.0 > > usbus0 on ehci0 > > ehci1: mem 0x1c1b000-0x1c1b0ff on simplebus0 > > usbus1: EHCI version 1.0 > > usbus1 on ehci1 > > awg0: mem 0x1c30000-0x1c300ff on simplebus0 > > miibus0: on awg0 > > rgephy0: PHY 0 on miibus0 > > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FD > > X-flow-master, auto, auto-flow > > rgephy1: PHY 1 on miibus0 > > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FD > > X-flow-master, auto, auto-flow > > awg0: Ethernet address: f2:00:52:68:6d:d8 > > aw_thermal0: mem 0x1f04000-0x1f043ff on simplebus0 > > cryptosoft0: > > Timecounters tick every 10.000 msec > > usbus0: 480Mbps High Speed USB v2.0 > > usbus1: 480Mbps High Speed USB v2.0 > > ugen1.1: at usbus1 > > ugen0.1: at usbus0 > > uhub0: on usbus0 > > uhub1: on usbus1 > > mmcsd0: 32GB at mmc0 50.0MHz/4bit/65535-block > > a10_mmc1: error rint: 0x00000100 > > a10_mmc1: error rint: 0x00000100 > > a10_mmc1: error rint: 0x00000100 > > a10_mmc1: error rint: 0x00000100 > > a10_mmc1: error rint: 0x00000100 > > a10_mmc1: error rint: 0x00000100 > > a10_mmc1: error rint: 0x00000100 > > a10_mmc1: error rint: 0x00000100 > > a10_mmc1: error rint: 0x00008018 > > a10_mmc1: error rint: 0x00000100 > > a10_mmc1: error rint: 0x00000100 > > a10_mmc1: error rint: 0x00000100 > > a10_mmc1: error rint: 0x00000100 > > mmcsd1: 8GB at mmc1 50.0MHz/8bit/65535-block > > Release APs > > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > > warning: no time-of-day clock registered, system time will not be set accurately > > uhub0: 1 port with 1 removable, self powered > > uhub1: 1 port with 1 removable, self powered > > ugen0.2: at usbus0 > > uhub2 on uhub0 > > uhub2: on usbus0 > > uhub2: 4 ports with 4 removable, self powered > > ugen0.3: at usbus0 > > umass0 on uhub2 > > umass0: on usbus0 > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (probe0:umass-sim0:0:0:0): Retrying command > > random: unblocking device. > > awg0: link state changed to DOWN > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (probe0:umass-sim0:0:0:0): Retrying command > > awg0: link state changed to UP > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (probe0:umass-sim0:0:0:0): Retrying command > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (probe0:umass-sim0:0:0:0): Retrying command > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted > > So far the probe0 messages stop after just a few like the above. > > Also it looks like the 8GB eMMC (mmc1 / mmcsd1) is likely not supported yet. > > I have not yet tried connecting an external usb drive. > > Some structure of what was done with the cores shows in the sysctl -a output: cpu names 0-3 and 100-103. > > (Note: the serial connection tends to drop some text sometimes. That may have happened some for the below.) > > > root@bananapi-m3:~ # sysctl -a | grep cpu > > kern.smp.cpus: 4 > > kern.smp.maxcpus: 4 > > kern.ccpu: 0 > > 0, 1, 2, 3 > > 0, 1, 2, 3 > > kern.sched.cpusetsize: 4 > > kern.pin_pcpu_swi: 0 > > kern.vt.splash_cpu_duration: 10 > > kern.vt.splash_cpu_style: 2 > > kern.vt.splash_ncpu: 0 > > kern.vt.splash_cpu: 0 > > net.inet.tcp.per_cpu_timers: 0 > > debug.PMAP1changedcpu: 106 > > debug.cpufreq.verbose: 0 > > debug.cpufreq.lowest: 0 > > hw.ncpu: 4 > > dev.cpu.7.%parent: cpulist0 > > dev.cpu.7.%pnpinfo: name=cpu@103 compat=arm,cortex-a7 > > dev.cpu.7.%location: > > dev.cpu.7.%driver: cpu > > dev.cpu.7.%desc: Open Firmware CPU > > dev.cpu.6.%parent: cpulist0 > > dev.cpu.6.%pnpinfo: name=cpu@102 compat=arm,cortex-a7 > > dev.cpu.6.%location: > > dev.cpu.6.%driver: cpu > > dev.cpu.6.%desc: Open Firmware CPU > > dev.cpu.5.%parent: cpulist0 > > dev.cpu.5.%pnpinfo: name=cpu@101 compat=arm,cortex-a7 > > dev.cpu.5.%location: > > dev.cpu.5.%dri.5.%desc: Open Firmware CPU > > dev.cpu.4.%parent: cpulist0 > > dev.cpu.4.%pnpinfo: name=cpu@100 compat=arm,cortex-a7 > > dev.cpu.4.%location: > > dev.cpu.4.%driver: cpu > > dev.cpu.4.%desc: Open Firmware CPU > > dev.cpu.3.%parent: cpulist0 > > dev.cpu.3.%pnpinfo: name=cpu@3 compat=arm,cortex-a7 > > dev.cpu.3.%location: > > dev.cpu.3.%driver: cpu > > dev.cpu.3.%desc: Open Firmware CPU > > dev.cpu.2.%parent: cpulist0 > > dev.cpu.2.%pnpinfo: name=cpu@2 compat=arm,cortex-a7 > > dev.cpu.2.%location: > > dev.cpu.2.%driver: cpu > > dev.cpu.2.%desc: Open Firmware CPU > > dev.cpu.1.%parent: cpulist0 > > dev.cpu.1.%location: > > dev.cpu.1.%driver: cpu > > dev.cpu.1.%desc: Open Firmware CPU > > dev.cpu.0.%parent: cpulist0 > > dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a7 > > dev.cpu.0.%location: > > dev.cpu.0.%driver: cpu > > dev.cpu.0.%desc: Open Firmware CPU > > dev.cpu.0.%parent: cpulist0 > > dev.cpulist.0.%parent: ofwbus0 > > dev.cpulist.0.%pnpinfo: name=cpus > > dev.cpulist.0.%location: > > dev.cpulist.0.%driver: cpulist > > dev.cpulist.0.%desc: Open Firmware CPU Group > > dev.cpulist.%parent: > > dev.aw_cpusclk.0.%parent: aw_ccu0 > > dev.aw_cpusclk.0.%pnpinfo: name=clk@01f0140inner,sun8i-a83t-cpus-clk > > dev.aw_cpusclk.0.%location: > > dev.aw_cpusclk.0.%driver: aw_cpusclk > > dev.aw_cpusclk.0.%desc: Allwinner CPUS Clock > > dev.aw_cpusclk.%parent: > > security.jail.param.cpuset.id: 0 > > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-stable@freebsd.org Mon Oct 24 22:47:19 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF519C1FB60; Mon, 24 Oct 2016 22:47:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 43B0F909; Mon, 24 Oct 2016 22:47:18 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 1402652f; Tue, 25 Oct 2016 00:47:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=/yIS40hcodtiXTyle4ZdaDOACxk=; b=AdQpuUsWJk/uW/5nLtsMYuFDJnK1 VOhjadOY0YIv2mTde5gA9L4gMNTYAraJsr+Q2eHld9Vw/Ru7RXTDMsHPm2e+NFzC HyaRJFPhWGIQAleX+7nZYIJkOOtPbNcxwO7vLSV8zgwyBCJcfJn9HGmOIcH6ASQf 7cYTtAre33Fa+po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=H9iLyu2DkDyCZO6WEyDn2EwkxWh7Saj0FFs9fkSt3w/ecrrXI0t/q+tj zW6qpoy3xqLbktQ1xURlsrHxyQbqr1RQfAUWswhbea0DBRQ1zri/BLTFss0jFG9F WFjeszVxmZNaVv5faqjEnd+yn56tpGyUzGUEFEH49Qy/CZqvGQc= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 1576cdbb TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 25 Oct 2016 00:47:16 +0200 (CEST) Date: Tue, 25 Oct 2016 00:47:16 +0200 From: Emmanuel Vadot To: Mark Millard Cc: freebsd-arm , FreeBSD-STABLE Mailing List Subject: Re: BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . . Message-Id: <20161025004716.b162f20383228707c610dbf1@bidouilliste.com> In-Reply-To: <71D914B0-6D3E-424D-B173-7EDBF883B3FE@dsl-only.net> References: <20161024230048.a440664797abd796eac08243@bidouilliste.com> <71D914B0-6D3E-424D-B173-7EDBF883B3FE@dsl-only.net> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 22:47:20 -0000 Ah yes, well same thing, we don't support cluster :) On Mon, 24 Oct 2016 15:42:40 -0700 Mark Millard wrote: > On 2016-Oct-24, at 2:00 PM, Emmanuel Vadot wro= te: >=20 >=20 > > Hello Mark, > >=20 > > The A83T is BIG/Little IIRC and we don't support that. That's why you > > only see 4 cores on the 8. >=20 > That is not what I get from reading the A83T documentation. All the CPU r= eferences are to the same type of CPU for each of the 8. But there is a NUM= A-ish pair of "clusters" of "CPU"s without a common L2-cache or other cache= across the clusters. >=20 > http://linux-sunxi.org/A83T says . . . >=20 > > This SoC does NOT comply with the ARM big.LITTLE architecture, therefor= e it is in no way energy efficent and gets very hot. >=20 >=20 > > CPU: > > ? ARM Cortex-A7 Octa-Core >=20 >=20 > A83T_Datasheet_v1.3_20150510.pdf says: >=20 > > Main features of A83T include: > > ? CPU architecture: Based on an octa-core CortexTM-A7 CPU architecture,= . . .. >=20 >=20 > > 2.1. CPU Architecture > >=20 > > ? ARMv7 ISA standard instruction set plus Thumb-2 and Jazeller RCT > >=20 > > ? NEON with SIMD and VFPv4 > >=20 > > ? Support LPAE > >=20 > > ? 32KB I-cache and 32KB D-cache per CPU > >=20 > > ? 1MB L2-cache >=20 > The "A883T Block Diagram (Figure 3-1 page labeled 12) simply says "A7 x 8= ". >=20 > A83T_User_Manual_v1.5.1_20150513.pdf has some more detailed diagrams and = more information. . . >=20 > There are two CPU Clusters (0 and 1). It is more of a NUMA context due t= o caching within each cluster that is not across the clusters. This documen= t's wording is more explicit, mentioning clusters for the L2-cache level (p= age labeled 51) in even its basic description of caches in the A83T archtie= cture: >=20 > > 2.1.1. CPU Architecture > >=20 > > The A83T platform is based on octa-core CortexTM-A7 CPU architecture. > >=20 > > ? ? ARMv7 ISA standard instruction set plus Thumb-2 and Jazeller RCT > >=20 > > ? ? NEON with SIMD and VFPv4 support > >=20 > > ? ? Support LPAE > >=20 > > ? ? 32KB I-cache and 32KB D-cache per CPU > >=20 > > ? ? 1MB L2-cache(512KB per Cluster) >=20 >=20 > See this document's Figure 3-1 "System Bus Tree" (on the page labeled 66). >=20 > From what I read one can control clock frequencies per cluster but it is = allowed to have them both the same all the time that frequencies are stable= for a while. >=20 > And I'll stop with the details that I see with that. >=20 > There may be some folks around with knowledge of more detail that might w= ell be able to say "but it is not NUMA like for these details . . .". By no= mean have I analyzed all the consequences of all the details. >=20 > But I find no evidence of BIG/Little use of different classes of cores at= necessarily different cock rates and the like. As much as I've looked at l= ooks more symmetric than that. >=20 >=20 >=20 > > cpulist0 shows 8 core because every core in is the dtb. > >=20 > > On Mon, 24 Oct 2016 09:04:35 -0700 > > Mark Millard wrote: > >=20 > >> The is for a Banana Pi M3 V1.2 board with the barrel power connector. = The 5V 2A supply that I had to fit the barrel hole can not power the board = sufficiently to boot --even when no fan is being powered. In order to boot = with a fan I have both that and an official rpi3 power supply plugged in. T= he rpi3 power supply will not power the GPIO fan connections but can boot t= he board by itself (V5.1v and 2.5A but cell phone charger cabling/connectio= ns). I've got a heat sink on the CPU as well. > >>=20 > >>> root@bananapi-m3:~ # uname -apKU > >>> FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon = Oct 24 00:41:16 PDT 2016 markmi@FreeBSDx64:/usr/local/src/crochet/work/= obj/arm.armv6/usr/src/sys/ALLWINNER arm armv6 1100505 1 > >>> 100505 > >>=20 > >>> root@bananapi-m3:~ # freebsd-version -ku > >>> 11.0-STABLE > >>> 11.0-STABLE > >>=20 > >> In the below note that "FreeBSD/SMP: Multiprocessor System Detected: 4= CPUs" but cpulist0 shows cpu0 through cpu7. For now: So much for seeing ho= w buildworld/buildkernel would go using all 8 cores. > >>=20 > >> (Note: the serial connection tends to drop some text sometimes. That m= ay have happened some for the below.) > >>=20 > >>> root@bananapi-m3:~ # dmesg | more > >>> Copyright (c) 1992-2016 The FreeBSD Project. > >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1= 994 > >>> The Regents of the University of California. All rights reserve= d. > >>> FreeBSD is a registered trademark of The FreeBSD Foundation. > >>> FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24 00:41:16 PDT 2016 > >>> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src= /sys/ALLWINNER arm > >>> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on= LLVM 3.8.0) > >>> VT: init without driver. > >>> CPU: Cortex A7 rev 5 (Cortex-A core) > >>> Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > >>> WB enabled LABT branch prediction disabled > >>> LoUU:2 LoC:3 LoUIS:2=20 > >>> Cache level 1:=20 > >>> 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc > >>> 32KB/32B 2-way instruction cache Read-Alloc > >>> Cache level 2:=20 > >>> 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc > >>> real memory =3D 2147483648 (2048 MB) > >>> avail memory =3D 2090852352 (1993 MB) > >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > >>> random: entropy device external interface > >>> kbd0 at kbdmux0 > >>> ofwbus0: > >>> aw_ccu0: on ofwbus0 > >>> clk_fixed0: on aw_ccu0 > >>> clk_fixed1: mem 0x1c20028-0x1c2002b on aw_ccu0 > >>> clk_fixed3: on aw_ccu0 > >>> aw_ahbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 > >>> aw_apbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 > >>> aw_apbclk1: mem 0x1c20058-0x1c2005b on aw_ccu0 > >>> aw_ahbclk1: mem 0x1c2005c-0x1c2005f on aw_ccu0 > >>> aw_gate0: mem 0x1c20060-0x1c2006f on aw_c= cu0 > >>> aw_mmcclk0: mem 0x1c20088-0x1c2clk1: mem 0x1c2008c-0x1c2008f on aw_ccu0 > >>> aw_mmcclk2: mem 0x1c20090-0x1c20093 on aw_ccu0 > >>> aw_cpusclk0: mem 0x1f01400-0x1f01403 on aw_ccu0 > >>> clk_fixed4: on aw_ccu0 > >>> aw_apbclk2: mem 0x1f0140c-0x1f0140f on aw_ccu0 > >>> aw_gate1: mem 0x1f01428-0x1f0142b on aw_= ccu0 > >>> aw_pll1: mem 0x1c20044-0x1c20047 on aw_ccu0 > >>> aw_usbclk0: mem 0x1c200cc-0x1c200cf on aw_ccu0 > >>> clk_fixed5: mem 0x1c00030-0x1c00033 on aw_ccu0 > >>> simplebus0: on ofwbus0 > >>> aw_reset0: mem 0x1c202c0-0x1c202cb on simpl= ebus0 > >>> aw_reset1: mem 0x1c202d0-0x1c202d3 on simpl= ebus0 > >>> aw_reset2: mem 0x1c202d8-0x1c202db on simpl= ebus0 > >>> aw_reset3: mem 0x1f014b0-0x1f014b3 on simpl= ebus0 > >>> iichb0: mem 0x1c2ac00-0x1c2= afff on simplebus0 > >>> iicbus0: hb0 > >>> iichb1: mem 0x1c2b000-0x1c2= b3ff on simplebus0 > >>> iicbus1: on iichb1 > >>> iichb2: mem 0x1c2b400-0x1c2= b7ff on simplebus0 > >>> iicbus2: on iichb2 > >>> regfix0: on ofwbus0 > >>> regfix1: on ofwbus0 > >>> regfix2: on ofwbus0 > >>> regfix3: on ofwbus0 > >>> regfix4: on ofwbus0 > >>> aw_sid0: mem 0x1c14000-0x1c143ff on = simplebus0 > >>> awusbphy0: on simplebu,0x1c86000-0x1c87fff on sim= plebus0 > >>> gic0: pn 0x20, arch 0x2, rev 0x1, implementer 0x43b irqs 224 > >>> gpio0: mem 0x1c20800-0x1c20bff on = simplebus0 > >>> gpiobus0: on gpio0 > >>> gpio1: mem 0x1f02c00-0x1f02fff on = simplebus0 > >>> gpiobus1: on gpio1 > >>> aw_nmi0: mem 0x1f00c0c-0x1f00c43 on simple= bus0 > >>> generic_timer0: on ofwbus0 > >>> Timecounter "cy 24000000 Hz quality 1000 > >>> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > >>> cpulist0: on ofwbus0 > >>> cpu0: on cpulist0 > >>> cpu1: on cpulist0 > >>> cpu2: on cpulist0 > >>> cpu3: on cpulist0 > >>> cpu4: on cpulist0 > >>> cpu5: on cpulist0 > >>> cpu6: on cpulist0 > >>> cpu7: on cpulist0 > >>> a10_mmc0: mem 0x1c0f000-0x1c= 0ffff on simplebus0 > >>> mmc0: on a10_mmc0 > >>> a10_mmc1: mem 0x1c11000-0x1c= 11fff on simplebus0 > >>> mmc1: on a10_mmc1 > >>> gpioc0: on gpio0 > >>> aw_wdog0: mem 0x1c20ca0-0x1c20cbf on simpleb= us0 > >>> uart0: mem 0x1c28000-0x1c= 283ff on simplebus0 > >>> uart0: console (480769,n,8,1) > >>> gpioc1: on gpio1 > >>> iichb3: mem 0x1f03400-0x1f037ff on simplebus0 > >>> iicbus3: on iichb3 > >>> iic0: on iicbus3 > >>> axp81x_pmu0: at addr 0x746 on= iicbus3 > >>> gpiobus2: on axp81x_pmu0 > >>> gpioled0: at pin 0 on gpiobus2 > >>> gpioled1: at pin 1 on gpiobus2 > >>> gpioc2: on axp81x_pmu0 > >>> iic1: on iicbus0 > >>> iic2: on iicbus1 > >>> iic3: on iicbus2 > >>> ehci0: mem 0x1c1a000-0x1c1a= 0ff on simplebus0 > >>> usbus0: EHCI version 1.0 > >>> usbus0 on ehci0 > >>> ehci1: mem 0x1c1b000-0x1c1b= 0ff on simplebus0 > >>> usbus1: EHCI version 1.0 > >>> usbus1 on ehci1 > >>> awg0: mem 0x1c30000-0x1c300ff on simpleb= us0 > >>> miibus0: on awg0 > >>> rgephy0: PHY 0 on mi= ibus0 > >>> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 10= 0baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX= , 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FD > >>> X-flow-master, auto, auto-flow > >>> rgephy1: PHY 1 on mi= ibus0 > >>> rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 10= 0baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX= , 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FD > >>> X-flow-master, auto, auto-flow > >>> awg0: Ethernet address: f2:00:52:68:6d:d8 > >>> aw_thermal0: mem 0x1f04000-0x1f= 043ff on simplebus0 > >>> cryptosoft0: > >>> Timecounters tick every 10.000 msec > >>> usbus0: 480Mbps High Speed USB v2.0 > >>> usbus1: 480Mbps High Speed USB v2.0 > >>> ugen1.1: at usbus1 > >>> ugen0.1: at usbus0 > >>> uhub0: on= usbus0 > >>> uhub1: on= usbus1 > >>> mmcsd0: 32GB at mmc= 0 50.0MHz/4bit/65535-block > >>> a10_mmc1: error rint: 0x00000100 > >>> a10_mmc1: error rint: 0x00000100 > >>> a10_mmc1: error rint: 0x00000100 > >>> a10_mmc1: error rint: 0x00000100 > >>> a10_mmc1: error rint: 0x00000100 > >>> a10_mmc1: error rint: 0x00000100 > >>> a10_mmc1: error rint: 0x00000100 > >>> a10_mmc1: error rint: 0x00000100 > >>> a10_mmc1: error rint: 0x00008018 > >>> a10_mmc1: error rint: 0x00000100 > >>> a10_mmc1: error rint: 0x00000100 > >>> a10_mmc1: error rint: 0x00000100 > >>> a10_mmc1: error rint: 0x00000100 > >>> mmcsd1: 8GB a= t mmc1 50.0MHz/8bit/65535-block > >>> Release APs > >>> Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > >>> warning: no time-of-day clock registered, system time will not be set= accurately > >>> uhub0: 1 port with 1 removable, self powered > >>> uhub1: 1 port with 1 removable, self powered > >>> ugen0.2: at usbus0 > >>> uhub2 on uhub0 > >>> uhub2: = on usbus0 > >>> uhub2: 4 ports with 4 removable, self powered > >>> ugen0.3: at usbus0 > >>> umass0 on uhub2 > >>> umass0: = on usbus0 > >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > >>> (probe0:umass-sim0:0:0:0): Retrying command > >>> random: unblocking device. > >>> awg0: link state changed to DOWN > >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > >>> (probe0:umass-sim0:0:0:0): Retrying command > >>> awg0: link state changed to UP > >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > >>> (probe0:umass-sim0:0:0:0): Retrying command > >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > >>> (probe0:umass-sim0:0:0:0): Retrying command > >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > >>> (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted > >>=20 > >> So far the probe0 messages stop after just a few like the above. > >>=20 > >> Also it looks like the 8GB eMMC (mmc1 / mmcsd1) is likely not supporte= d yet. > >>=20 > >> I have not yet tried connecting an external usb drive. > >>=20 > >> Some structure of what was done with the cores shows in the sysctl -a = output: cpu names 0-3 and 100-103. > >>=20 > >> (Note: the serial connection tends to drop some text sometimes. That m= ay have happened some for the below.) > >>=20 > >>> root@bananapi-m3:~ # sysctl -a | grep cpu > >>> kern.smp.cpus: 4 > >>> kern.smp.maxcpus: 4 > >>> kern.ccpu: 0 > >>> 0, 1, 2, 3 > >>> 0, 1, 2, 3 > >>> kern.sched.cpusetsize: 4 > >>> kern.pin_pcpu_swi: 0 > >>> kern.vt.splash_cpu_duration: 10 > >>> kern.vt.splash_cpu_style: 2 > >>> kern.vt.splash_ncpu: 0 > >>> kern.vt.splash_cpu: 0 > >>> net.inet.tcp.per_cpu_timers: 0 > >>> debug.PMAP1changedcpu: 106 > >>> debug.cpufreq.verbose: 0 > >>> debug.cpufreq.lowest: 0 > >>> hw.ncpu: 4 > >>> dev.cpu.7.%parent: cpulist0 > >>> dev.cpu.7.%pnpinfo: name=3Dcpu@103 compat=3Darm,cortex-a7 > >>> dev.cpu.7.%location:=20 > >>> dev.cpu.7.%driver: cpu > >>> dev.cpu.7.%desc: Open Firmware CPU > >>> dev.cpu.6.%parent: cpulist0 > >>> dev.cpu.6.%pnpinfo: name=3Dcpu@102 compat=3Darm,cortex-a7 > >>> dev.cpu.6.%location:=20 > >>> dev.cpu.6.%driver: cpu > >>> dev.cpu.6.%desc: Open Firmware CPU > >>> dev.cpu.5.%parent: cpulist0 > >>> dev.cpu.5.%pnpinfo: name=3Dcpu@101 compat=3Darm,cortex-a7 > >>> dev.cpu.5.%location:=20 > >>> dev.cpu.5.%dri.5.%desc: Open Firmware CPU > >>> dev.cpu.4.%parent: cpulist0 > >>> dev.cpu.4.%pnpinfo: name=3Dcpu@100 compat=3Darm,cortex-a7 > >>> dev.cpu.4.%location:=20 > >>> dev.cpu.4.%driver: cpu > >>> dev.cpu.4.%desc: Open Firmware CPU > >>> dev.cpu.3.%parent: cpulist0 > >>> dev.cpu.3.%pnpinfo: name=3Dcpu@3 compat=3Darm,cortex-a7 > >>> dev.cpu.3.%location:=20 > >>> dev.cpu.3.%driver: cpu > >>> dev.cpu.3.%desc: Open Firmware CPU > >>> dev.cpu.2.%parent: cpulist0 > >>> dev.cpu.2.%pnpinfo: name=3Dcpu@2 compat=3Darm,cortex-a7 > >>> dev.cpu.2.%location:=20 > >>> dev.cpu.2.%driver: cpu > >>> dev.cpu.2.%desc: Open Firmware CPU > >>> dev.cpu.1.%parent: cpulist0 > >>> dev.cpu.1.%location:=20 > >>> dev.cpu.1.%driver: cpu > >>> dev.cpu.1.%desc: Open Firmware CPU > >>> dev.cpu.0.%parent: cpulist0 > >>> dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,cortex-a7 > >>> dev.cpu.0.%location:=20 > >>> dev.cpu.0.%driver: cpu > >>> dev.cpu.0.%desc: Open Firmware CPU > >>> dev.cpu.0.%parent: cpulist0 > >>> dev.cpulist.0.%parent: ofwbus0 > >>> dev.cpulist.0.%pnpinfo: name=3Dcpus > >>> dev.cpulist.0.%location:=20 > >>> dev.cpulist.0.%driver: cpulist > >>> dev.cpulist.0.%desc: Open Firmware CPU Group > >>> dev.cpulist.%parent:=20 > >>> dev.aw_cpusclk.0.%parent: aw_ccu0 > >>> dev.aw_cpusclk.0.%pnpinfo: name=3Dclk@01f0140inner,sun8i-a83t-cpus-clk > >>> dev.aw_cpusclk.0.%location:=20 > >>> dev.aw_cpusclk.0.%driver: aw_cpusclk > >>> dev.aw_cpusclk.0.%desc: Allwinner CPUS Clock > >>> dev.aw_cpusclk.%parent:=20 > >>> security.jail.param.cpuset.id: 0 > >>=20 > >>=20 > >>=20 > >> =3D=3D=3D > >> Mark Millard > >> markmi at dsl-only.net > >>=20 >=20 > >=20 > > --=20 > > Emmanuel Vadot >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net --=20 Emmanuel Vadot From owner-freebsd-stable@freebsd.org Mon Oct 24 23:15:51 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2856FC203E6 for ; Mon, 24 Oct 2016 23:15:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-29.reflexion.net [208.70.210.29]) (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 DD604A0C for ; Mon, 24 Oct 2016 23:15:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15307 invoked from network); 24 Oct 2016 23:08:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Oct 2016 23:08:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Mon, 24 Oct 2016 19:09:14 -0400 (EDT) Received: (qmail 16765 invoked from network); 24 Oct 2016 23:09:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Oct 2016 23:09:13 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D0094EC7B30; Mon, 24 Oct 2016 16:09:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Subject: Re: BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . . From: Mark Millard In-Reply-To: <20161025004716.b162f20383228707c610dbf1@bidouilliste.com> Date: Mon, 24 Oct 2016 16:09:08 -0700 Cc: freebsd-arm , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161024230048.a440664797abd796eac08243@bidouilliste.com> <71D914B0-6D3E-424D-B173-7EDBF883B3FE@dsl-only.net> <20161025004716.b162f20383228707c610dbf1@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3226) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 23:15:51 -0000 > On 2016-Oct-24, at 3:47 PM, Emmanuel Vadot = wrote: >=20 >=20 > Ah yes, well same thing, we don't support cluster :) I wonder if the second cluster is well powered down (as best it can be = as early as it can be). I could not even boot without special power = connections (beyond 2A supply for the 5V/5.1V used). 2.5A worked (no fan = to power). It took two supplies to also provide fan power over a couple = of the GPIO pins and still be able to boot. And, yes, reading about the A83T does suggest that FreeBSD will never = put that kind of NUMA handling effort into it, like it does for some = bigger iron that is far more in use. It would probably be a good idea if wiki pages and such referencing the = A83T and its status be explicit about the "at most 4 cores in use" = status. Using more than 4 cores is the primary reason to get/use a A83T = (and to put up with handling power and heat issues). > On Mon, 24 Oct 2016 15:42:40 -0700 > Mark Millard wrote: >=20 >> On 2016-Oct-24, at 2:00 PM, Emmanuel Vadot = wrote: >>=20 >>=20 >>> Hello Mark, >>>=20 >>> The A83T is BIG/Little IIRC and we don't support that. That's why = you >>> only see 4 cores on the 8. >>=20 >> That is not what I get from reading the A83T documentation. All the = CPU references are to the same type of CPU for each of the 8. But there = is a NUMA-ish pair of "clusters" of "CPU"s without a common L2-cache or = other cache across the clusters. >>=20 >> http://linux-sunxi.org/A83T says . . . >>=20 >>> This SoC does NOT comply with the ARM big.LITTLE architecture, = therefore it is in no way energy efficent and gets very hot. >>=20 >>=20 >>> CPU: >>> ? ARM Cortex-A7 Octa-Core >>=20 >>=20 >> A83T_Datasheet_v1.3_20150510.pdf says: >>=20 >>> Main features of A83T include: >>> ? CPU architecture: Based on an octa-core CortexTM-A7 CPU = architecture, . . .. >>=20 >>=20 >>> 2.1. CPU Architecture >>>=20 >>> ? ARMv7 ISA standard instruction set plus Thumb-2 and Jazeller = RCT >>>=20 >>> ? NEON with SIMD and VFPv4 >>>=20 >>> ? Support LPAE >>>=20 >>> ? 32KB I-cache and 32KB D-cache per CPU >>>=20 >>> ? 1MB L2-cache >>=20 >> The "A883T Block Diagram (Figure 3-1 page labeled 12) simply says "A7 = x 8". >>=20 >> A83T_User_Manual_v1.5.1_20150513.pdf has some more detailed diagrams = and more information. . . >>=20 >> There are two CPU Clusters (0 and 1). It is more of a NUMA context = due to caching within each cluster that is not across the clusters. This = document's wording is more explicit, mentioning clusters for the = L2-cache level (page labeled 51) in even its basic description of caches = in the A83T archtiecture: >>=20 >>> 2.1.1. CPU Architecture >>>=20 >>> The A83T platform is based on octa-core CortexTM-A7 CPU = architecture. >>>=20 >>> ? ? ARMv7 ISA standard instruction set plus Thumb-2 and = Jazeller RCT >>>=20 >>> ? ? NEON with SIMD and VFPv4 support >>>=20 >>> ? ? Support LPAE >>>=20 >>> ? ? 32KB I-cache and 32KB D-cache per CPU >>>=20 >>> ? ? 1MB L2-cache(512KB per Cluster) >>=20 >>=20 >> See this document's Figure 3-1 "System Bus Tree" (on the page labeled = 66). >>=20 >> =46rom what I read one can control clock frequencies per cluster but = it is allowed to have them both the same all the time that frequencies = are stable for a while. >>=20 >> And I'll stop with the details that I see with that. >>=20 >> There may be some folks around with knowledge of more detail that = might well be able to say "but it is not NUMA like for these details . . = .". By no mean have I analyzed all the consequences of all the details. >>=20 >> But I find no evidence of BIG/Little use of different classes of = cores at necessarily different cock rates and the like. As much as I've = looked at looks more symmetric than that. >>=20 >>=20 >>=20 >>> cpulist0 shows 8 core because every core in is the dtb. >>>=20 >>> On Mon, 24 Oct 2016 09:04:35 -0700 >>> Mark Millard wrote: >>>=20 >>>> The is for a Banana Pi M3 V1.2 board with the barrel power = connector. The 5V 2A supply that I had to fit the barrel hole can not = power the board sufficiently to boot --even when no fan is being = powered. In order to boot with a fan I have both that and an official = rpi3 power supply plugged in. The rpi3 power supply will not power the = GPIO fan connections but can boot the board by itself (V5.1v and 2.5A = but cell phone charger cabling/connections). I've got a heat sink on the = CPU as well. >>>>=20 >>>>> root@bananapi-m3:~ # uname -apKU >>>>> FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: = Mon Oct 24 00:41:16 PDT 2016 = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm armv6 1100505 1 >>>>> 100505 >>>>=20 >>>>> root@bananapi-m3:~ # freebsd-version -ku >>>>> 11.0-STABLE >>>>> 11.0-STABLE >>>>=20 >>>> In the below note that "FreeBSD/SMP: Multiprocessor System = Detected: 4 CPUs" but cpulist0 shows cpu0 through cpu7. For now: So much = for seeing how buildworld/buildkernel would go using all 8 cores. >>>>=20 >>>> (Note: the serial connection tends to drop some text sometimes. = That may have happened some for the below.) >>>>=20 >>>>> root@bananapi-m3:~ # dmesg | more >>>>> 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-STABLE #0 r307797M: Mon Oct 24 00:41:16 PDT 2016 >>>>> = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm >>>>> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based = on LLVM 3.8.0) >>>>> VT: init without driver. >>>>> CPU: Cortex A7 rev 5 (Cortex-A core) >>>>> Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 = Security_Ext >>>>> WB enabled LABT branch prediction disabled >>>>> LoUU:2 LoC:3 LoUIS:2=20 >>>>> Cache level 1:=20 >>>>> 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc >>>>> 32KB/32B 2-way instruction cache Read-Alloc >>>>> Cache level 2:=20 >>>>> 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc >>>>> real memory =3D 2147483648 (2048 MB) >>>>> avail memory =3D 2090852352 (1993 MB) >>>>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>>>> random: entropy device external interface >>>>> kbd0 at kbdmux0 >>>>> ofwbus0: >>>>> aw_ccu0: on ofwbus0 >>>>> clk_fixed0: on aw_ccu0 >>>>> clk_fixed1: mem 0x1c20028-0x1c2002b on aw_ccu0 >>>>> clk_fixed3: on aw_ccu0 >>>>> aw_ahbclk0: mem 0x1c20054-0x1c20057 on = aw_ccu0 >>>>> aw_apbclk0: mem 0x1c20054-0x1c20057 on = aw_ccu0 >>>>> aw_apbclk1: mem 0x1c20058-0x1c2005b on = aw_ccu0 >>>>> aw_ahbclk1: mem 0x1c2005c-0x1c2005f on = aw_ccu0 >>>>> aw_gate0: mem 0x1c20060-0x1c2006f on = aw_ccu0 >>>>> aw_mmcclk0: mem 0x1c20088-0x1c2clk1: = mem 0x1c2008c-0x1c2008f on aw_ccu0 >>>>> aw_mmcclk2: mem 0x1c20090-0x1c20093 on = aw_ccu0 >>>>> aw_cpusclk0: mem 0x1f01400-0x1f01403 on = aw_ccu0 >>>>> clk_fixed4: on aw_ccu0 >>>>> aw_apbclk2: mem 0x1f0140c-0x1f0140f on = aw_ccu0 >>>>> aw_gate1: mem 0x1f01428-0x1f0142b on = aw_ccu0 >>>>> aw_pll1: mem 0x1c20044-0x1c20047 on aw_ccu0 >>>>> aw_usbclk0: mem 0x1c200cc-0x1c200cf on = aw_ccu0 >>>>> clk_fixed5: mem 0x1c00030-0x1c00033 on = aw_ccu0 >>>>> simplebus0: on ofwbus0 >>>>> aw_reset0: mem 0x1c202c0-0x1c202cb on = simplebus0 >>>>> aw_reset1: mem 0x1c202d0-0x1c202d3 on = simplebus0 >>>>> aw_reset2: mem 0x1c202d8-0x1c202db on = simplebus0 >>>>> aw_reset3: mem 0x1f014b0-0x1f014b3 on = simplebus0 >>>>> iichb0: mem = 0x1c2ac00-0x1c2afff on simplebus0 >>>>> iicbus0: hb0 >>>>> iichb1: mem = 0x1c2b000-0x1c2b3ff on simplebus0 >>>>> iicbus1: on iichb1 >>>>> iichb2: mem = 0x1c2b400-0x1c2b7ff on simplebus0 >>>>> iicbus2: on iichb2 >>>>> regfix0: on ofwbus0 >>>>> regfix1: on ofwbus0 >>>>> regfix2: on ofwbus0 >>>>> regfix3: on ofwbus0 >>>>> regfix4: on ofwbus0 >>>>> aw_sid0: mem 0x1c14000-0x1c143ff = on simplebus0 >>>>> awusbphy0: on simplebu,0x1c86000-0x1c87fff on = simplebus0 >>>>> gic0: pn 0x20, arch 0x2, rev 0x1, implementer 0x43b irqs 224 >>>>> gpio0: mem 0x1c20800-0x1c20bff = on simplebus0 >>>>> gpiobus0: on gpio0 >>>>> gpio1: mem 0x1f02c00-0x1f02fff = on simplebus0 >>>>> gpiobus1: on gpio1 >>>>> aw_nmi0: mem 0x1f00c0c-0x1f00c43 on = simplebus0 >>>>> generic_timer0: on ofwbus0 >>>>> Timecounter "cy 24000000 Hz quality 1000 >>>>> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality = 1000 >>>>> cpulist0: on ofwbus0 >>>>> cpu0: on cpulist0 >>>>> cpu1: on cpulist0 >>>>> cpu2: on cpulist0 >>>>> cpu3: on cpulist0 >>>>> cpu4: on cpulist0 >>>>> cpu5: on cpulist0 >>>>> cpu6: on cpulist0 >>>>> cpu7: on cpulist0 >>>>> a10_mmc0: mem = 0x1c0f000-0x1c0ffff on simplebus0 >>>>> mmc0: on a10_mmc0 >>>>> a10_mmc1: mem = 0x1c11000-0x1c11fff on simplebus0 >>>>> mmc1: on a10_mmc1 >>>>> gpioc0: on gpio0 >>>>> aw_wdog0: mem 0x1c20ca0-0x1c20cbf on = simplebus0 >>>>> uart0: mem = 0x1c28000-0x1c283ff on simplebus0 >>>>> uart0: console (480769,n,8,1) >>>>> gpioc1: on gpio1 >>>>> iichb3: mem 0x1f03400-0x1f037ff on simplebus0 >>>>> iicbus3: on iichb3 >>>>> iic0: on iicbus3 >>>>> axp81x_pmu0: at addr 0x746 = on iicbus3 >>>>> gpiobus2: on axp81x_pmu0 >>>>> gpioled0: at pin 0 on gpiobus2 >>>>> gpioled1: at pin 1 on gpiobus2 >>>>> gpioc2: on axp81x_pmu0 >>>>> iic1: on iicbus0 >>>>> iic2: on iicbus1 >>>>> iic3: on iicbus2 >>>>> ehci0: mem = 0x1c1a000-0x1c1a0ff on simplebus0 >>>>> usbus0: EHCI version 1.0 >>>>> usbus0 on ehci0 >>>>> ehci1: mem = 0x1c1b000-0x1c1b0ff on simplebus0 >>>>> usbus1: EHCI version 1.0 >>>>> usbus1 on ehci1 >>>>> awg0: mem 0x1c30000-0x1c300ff on = simplebus0 >>>>> miibus0: on awg0 >>>>> rgephy0: PHY 0 on = miibus0 >>>>> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FD >>>>> X-flow-master, auto, auto-flow >>>>> rgephy1: PHY 1 on = miibus0 >>>>> rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FD >>>>> X-flow-master, auto, auto-flow >>>>> awg0: Ethernet address: f2:00:52:68:6d:d8 >>>>> aw_thermal0: mem = 0x1f04000-0x1f043ff on simplebus0 >>>>> cryptosoft0: >>>>> Timecounters tick every 10.000 msec >>>>> usbus0: 480Mbps High Speed USB v2.0 >>>>> usbus1: 480Mbps High Speed USB v2.0 >>>>> ugen1.1: at usbus1 >>>>> ugen0.1: at usbus0 >>>>> uhub0: = on usbus0 >>>>> uhub1: = on usbus1 >>>>> mmcsd0: 32GB at = mmc0 50.0MHz/4bit/65535-block >>>>> a10_mmc1: error rint: 0x00000100 >>>>> a10_mmc1: error rint: 0x00000100 >>>>> a10_mmc1: error rint: 0x00000100 >>>>> a10_mmc1: error rint: 0x00000100 >>>>> a10_mmc1: error rint: 0x00000100 >>>>> a10_mmc1: error rint: 0x00000100 >>>>> a10_mmc1: error rint: 0x00000100 >>>>> a10_mmc1: error rint: 0x00000100 >>>>> a10_mmc1: error rint: 0x00008018 >>>>> a10_mmc1: error rint: 0x00000100 >>>>> a10_mmc1: error rint: 0x00000100 >>>>> a10_mmc1: error rint: 0x00000100 >>>>> a10_mmc1: error rint: 0x00000100 >>>>> mmcsd1: 8GB at mmc1 50.0MHz/8bit/65535-block >>>>> Release APs >>>>> Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... >>>>> warning: no time-of-day clock registered, system time will not be = set accurately >>>>> uhub0: 1 port with 1 removable, self powered >>>>> uhub1: 1 port with 1 removable, self powered >>>>> ugen0.2: at usbus0 >>>>> uhub2 on uhub0 >>>>> uhub2: on usbus0 >>>>> uhub2: 4 ports with 4 removable, self powered >>>>> ugen0.3: at usbus0 >>>>> umass0 on uhub2 >>>>> umass0: on usbus0 >>>>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 >>>>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with = an error >>>>> (probe0:umass-sim0:0:0:0): Retrying command >>>>> random: unblocking device. >>>>> awg0: link state changed to DOWN >>>>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 >>>>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with = an error >>>>> (probe0:umass-sim0:0:0:0): Retrying command >>>>> awg0: link state changed to UP >>>>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 >>>>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with = an error >>>>> (probe0:umass-sim0:0:0:0): Retrying command >>>>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 >>>>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with = an error >>>>> (probe0:umass-sim0:0:0:0): Retrying command >>>>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 >>>>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with = an error >>>>> (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted >>>>=20 >>>> So far the probe0 messages stop after just a few like the above. >>>>=20 >>>> Also it looks like the 8GB eMMC (mmc1 / mmcsd1) is likely not = supported yet. >>>>=20 >>>> I have not yet tried connecting an external usb drive. >>>>=20 >>>> Some structure of what was done with the cores shows in the sysctl = -a output: cpu names 0-3 and 100-103. >>>>=20 >>>> (Note: the serial connection tends to drop some text sometimes. = That may have happened some for the below.) >>>>=20 >>>>> root@bananapi-m3:~ # sysctl -a | grep cpu >>>>> kern.smp.cpus: 4 >>>>> kern.smp.maxcpus: 4 >>>>> kern.ccpu: 0 >>>>> 0, 1, 2, 3 >>>>> 0, 1, 2, 3 >>>>> kern.sched.cpusetsize: 4 >>>>> kern.pin_pcpu_swi: 0 >>>>> kern.vt.splash_cpu_duration: 10 >>>>> kern.vt.splash_cpu_style: 2 >>>>> kern.vt.splash_ncpu: 0 >>>>> kern.vt.splash_cpu: 0 >>>>> net.inet.tcp.per_cpu_timers: 0 >>>>> debug.PMAP1changedcpu: 106 >>>>> debug.cpufreq.verbose: 0 >>>>> debug.cpufreq.lowest: 0 >>>>> hw.ncpu: 4 >>>>> dev.cpu.7.%parent: cpulist0 >>>>> dev.cpu.7.%pnpinfo: name=3Dcpu@103 compat=3Darm,cortex-a7 >>>>> dev.cpu.7.%location:=20 >>>>> dev.cpu.7.%driver: cpu >>>>> dev.cpu.7.%desc: Open Firmware CPU >>>>> dev.cpu.6.%parent: cpulist0 >>>>> dev.cpu.6.%pnpinfo: name=3Dcpu@102 compat=3Darm,cortex-a7 >>>>> dev.cpu.6.%location:=20 >>>>> dev.cpu.6.%driver: cpu >>>>> dev.cpu.6.%desc: Open Firmware CPU >>>>> dev.cpu.5.%parent: cpulist0 >>>>> dev.cpu.5.%pnpinfo: name=3Dcpu@101 compat=3Darm,cortex-a7 >>>>> dev.cpu.5.%location:=20 >>>>> dev.cpu.5.%dri.5.%desc: Open Firmware CPU >>>>> dev.cpu.4.%parent: cpulist0 >>>>> dev.cpu.4.%pnpinfo: name=3Dcpu@100 compat=3Darm,cortex-a7 >>>>> dev.cpu.4.%location:=20 >>>>> dev.cpu.4.%driver: cpu >>>>> dev.cpu.4.%desc: Open Firmware CPU >>>>> dev.cpu.3.%parent: cpulist0 >>>>> dev.cpu.3.%pnpinfo: name=3Dcpu@3 compat=3Darm,cortex-a7 >>>>> dev.cpu.3.%location:=20 >>>>> dev.cpu.3.%driver: cpu >>>>> dev.cpu.3.%desc: Open Firmware CPU >>>>> dev.cpu.2.%parent: cpulist0 >>>>> dev.cpu.2.%pnpinfo: name=3Dcpu@2 compat=3Darm,cortex-a7 >>>>> dev.cpu.2.%location:=20 >>>>> dev.cpu.2.%driver: cpu >>>>> dev.cpu.2.%desc: Open Firmware CPU >>>>> dev.cpu.1.%parent: cpulist0 >>>>> dev.cpu.1.%location:=20 >>>>> dev.cpu.1.%driver: cpu >>>>> dev.cpu.1.%desc: Open Firmware CPU >>>>> dev.cpu.0.%parent: cpulist0 >>>>> dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,cortex-a7 >>>>> dev.cpu.0.%location:=20 >>>>> dev.cpu.0.%driver: cpu >>>>> dev.cpu.0.%desc: Open Firmware CPU >>>>> dev.cpu.0.%parent: cpulist0 >>>>> dev.cpulist.0.%parent: ofwbus0 >>>>> dev.cpulist.0.%pnpinfo: name=3Dcpus >>>>> dev.cpulist.0.%location:=20 >>>>> dev.cpulist.0.%driver: cpulist >>>>> dev.cpulist.0.%desc: Open Firmware CPU Group >>>>> dev.cpulist.%parent:=20 >>>>> dev.aw_cpusclk.0.%parent: aw_ccu0 >>>>> dev.aw_cpusclk.0.%pnpinfo: = name=3Dclk@01f0140inner,sun8i-a83t-cpus-clk >>>>> dev.aw_cpusclk.0.%location:=20 >>>>> dev.aw_cpusclk.0.%driver: aw_cpusclk >>>>> dev.aw_cpusclk.0.%desc: Allwinner CPUS Clock >>>>> dev.aw_cpusclk.%parent:=20 >>>>> security.jail.param.cpuset.id: 0 >>>>=20 >>>>=20 >>>>=20 >>>> =3D=3D=3D >>>> Mark Millard >>>> markmi at dsl-only.net >>>>=20 >>=20 >>>=20 >>> --=20 >>> Emmanuel Vadot >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 >=20 > --=20 > Emmanuel Vadot =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Tue Oct 25 00:29:24 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D899BC1E4F6 for ; Tue, 25 Oct 2016 00:29:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-34.reflexion.net [208.70.210.34]) (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 98E2AAEE for ; Tue, 25 Oct 2016 00:29:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4535 invoked from network); 24 Oct 2016 22:42:41 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Oct 2016 22:42:41 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Mon, 24 Oct 2016 18:42:46 -0400 (EDT) Received: (qmail 8072 invoked from network); 24 Oct 2016 22:42:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Oct 2016 22:42:46 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 74456EC7B30; Mon, 24 Oct 2016 15:42:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Subject: Re: BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . . From: Mark Millard In-Reply-To: <20161024230048.a440664797abd796eac08243@bidouilliste.com> Date: Mon, 24 Oct 2016 15:42:40 -0700 Cc: freebsd-arm , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <71D914B0-6D3E-424D-B173-7EDBF883B3FE@dsl-only.net> References: <20161024230048.a440664797abd796eac08243@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3226) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 00:29:24 -0000 On 2016-Oct-24, at 2:00 PM, Emmanuel Vadot = wrote: > Hello Mark, >=20 > The A83T is BIG/Little IIRC and we don't support that. That's why you > only see 4 cores on the 8. That is not what I get from reading the A83T documentation. All the CPU = references are to the same type of CPU for each of the 8. But there is a = NUMA-ish pair of "clusters" of "CPU"s without a common L2-cache or other = cache across the clusters. http://linux-sunxi.org/A83T says . . . > This SoC does NOT comply with the ARM big.LITTLE architecture, = therefore it is in no way energy efficent and gets very hot. > CPU: > =E2=80=A2 ARM Cortex-A7 Octa-Core A83T_Datasheet_v1.3_20150510.pdf says: > Main features of A83T include: > =E2=80=A2 CPU architecture: Based on an octa-core CortexTM-A7 CPU = architecture, . . .. > 2.1. CPU Architecture >=20 > =E2=80=A2 ARMv7 ISA standard instruction set plus Thumb-2 and = Jazeller RCT >=20 > =E2=80=A2 NEON with SIMD and VFPv4 >=20 > =E2=80=A2 Support LPAE >=20 > =E2=80=A2 32KB I-cache and 32KB D-cache per CPU >=20 > =E2=80=A2 1MB L2-cache The "A883T Block Diagram (Figure 3-1 page labeled 12) simply says "A7 x = 8". A83T_User_Manual_v1.5.1_20150513.pdf has some more detailed diagrams and = more information. . . There are two CPU Clusters (0 and 1). It is more of a NUMA context due = to caching within each cluster that is not across the clusters. This = document's wording is more explicit, mentioning clusters for the = L2-cache level (page labeled 51) in even its basic description of caches = in the A83T archtiecture: > 2.1.1. CPU Architecture >=20 > The A83T platform is based on octa-core CortexTM-A7 CPU architecture. >=20 > =E2=80=A2 =EF=82=9F ARMv7 ISA standard instruction set plus = Thumb-2 and Jazeller RCT >=20 > =E2=80=A2 =EF=82=9F NEON with SIMD and VFPv4 support >=20 > =E2=80=A2 =EF=82=9F Support LPAE >=20 > =E2=80=A2 =EF=82=9F 32KB I-cache and 32KB D-cache per CPU >=20 > =E2=80=A2 =EF=82=9F 1MB L2-cache(512KB per Cluster) See this document's Figure 3-1 "System Bus Tree" (on the page labeled = 66). =46rom what I read one can control clock frequencies per cluster but it = is allowed to have them both the same all the time that frequencies are = stable for a while. And I'll stop with the details that I see with that. There may be some folks around with knowledge of more detail that might = well be able to say "but it is not NUMA like for these details . . .". = By no mean have I analyzed all the consequences of all the details. But I find no evidence of BIG/Little use of different classes of cores = at necessarily different cock rates and the like. As much as I've looked = at looks more symmetric than that. > cpulist0 shows 8 core because every core in is the dtb. >=20 > On Mon, 24 Oct 2016 09:04:35 -0700 > Mark Millard wrote: >=20 >> The is for a Banana Pi M3 V1.2 board with the barrel power connector. = The 5V 2A supply that I had to fit the barrel hole can not power the = board sufficiently to boot --even when no fan is being powered. In order = to boot with a fan I have both that and an official rpi3 power supply = plugged in. The rpi3 power supply will not power the GPIO fan = connections but can boot the board by itself (V5.1v and 2.5A but cell = phone charger cabling/connections). I've got a heat sink on the CPU as = well. >>=20 >>> root@bananapi-m3:~ # uname -apKU >>> FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon = Oct 24 00:41:16 PDT 2016 = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm armv6 1100505 1 >>> 100505 >>=20 >>> root@bananapi-m3:~ # freebsd-version -ku >>> 11.0-STABLE >>> 11.0-STABLE >>=20 >> In the below note that "FreeBSD/SMP: Multiprocessor System Detected: = 4 CPUs" but cpulist0 shows cpu0 through cpu7. For now: So much for = seeing how buildworld/buildkernel would go using all 8 cores. >>=20 >> (Note: the serial connection tends to drop some text sometimes. That = may have happened some for the below.) >>=20 >>> root@bananapi-m3:~ # dmesg | more >>> 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-STABLE #0 r307797M: Mon Oct 24 00:41:16 PDT 2016 >>> = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm >>> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based = on LLVM 3.8.0) >>> VT: init without driver. >>> CPU: Cortex A7 rev 5 (Cortex-A core) >>> Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 = Security_Ext >>> WB enabled LABT branch prediction disabled >>> LoUU:2 LoC:3 LoUIS:2=20 >>> Cache level 1:=20 >>> 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc >>> 32KB/32B 2-way instruction cache Read-Alloc >>> Cache level 2:=20 >>> 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc >>> real memory =3D 2147483648 (2048 MB) >>> avail memory =3D 2090852352 (1993 MB) >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>> random: entropy device external interface >>> kbd0 at kbdmux0 >>> ofwbus0: >>> aw_ccu0: on ofwbus0 >>> clk_fixed0: on aw_ccu0 >>> clk_fixed1: mem 0x1c20028-0x1c2002b on aw_ccu0 >>> clk_fixed3: on aw_ccu0 >>> aw_ahbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 >>> aw_apbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 >>> aw_apbclk1: mem 0x1c20058-0x1c2005b on aw_ccu0 >>> aw_ahbclk1: mem 0x1c2005c-0x1c2005f on aw_ccu0 >>> aw_gate0: mem 0x1c20060-0x1c2006f on = aw_ccu0 >>> aw_mmcclk0: mem 0x1c20088-0x1c2clk1: = mem 0x1c2008c-0x1c2008f on aw_ccu0 >>> aw_mmcclk2: mem 0x1c20090-0x1c20093 on aw_ccu0 >>> aw_cpusclk0: mem 0x1f01400-0x1f01403 on = aw_ccu0 >>> clk_fixed4: on aw_ccu0 >>> aw_apbclk2: mem 0x1f0140c-0x1f0140f on aw_ccu0 >>> aw_gate1: mem 0x1f01428-0x1f0142b on = aw_ccu0 >>> aw_pll1: mem 0x1c20044-0x1c20047 on aw_ccu0 >>> aw_usbclk0: mem 0x1c200cc-0x1c200cf on = aw_ccu0 >>> clk_fixed5: mem 0x1c00030-0x1c00033 on = aw_ccu0 >>> simplebus0: on ofwbus0 >>> aw_reset0: mem 0x1c202c0-0x1c202cb on = simplebus0 >>> aw_reset1: mem 0x1c202d0-0x1c202d3 on = simplebus0 >>> aw_reset2: mem 0x1c202d8-0x1c202db on = simplebus0 >>> aw_reset3: mem 0x1f014b0-0x1f014b3 on = simplebus0 >>> iichb0: mem = 0x1c2ac00-0x1c2afff on simplebus0 >>> iicbus0: hb0 >>> iichb1: mem = 0x1c2b000-0x1c2b3ff on simplebus0 >>> iicbus1: on iichb1 >>> iichb2: mem = 0x1c2b400-0x1c2b7ff on simplebus0 >>> iicbus2: on iichb2 >>> regfix0: on ofwbus0 >>> regfix1: on ofwbus0 >>> regfix2: on ofwbus0 >>> regfix3: on ofwbus0 >>> regfix4: on ofwbus0 >>> aw_sid0: mem 0x1c14000-0x1c143ff on = simplebus0 >>> awusbphy0: on simplebu,0x1c86000-0x1c87fff on = simplebus0 >>> gic0: pn 0x20, arch 0x2, rev 0x1, implementer 0x43b irqs 224 >>> gpio0: mem 0x1c20800-0x1c20bff on = simplebus0 >>> gpiobus0: on gpio0 >>> gpio1: mem 0x1f02c00-0x1f02fff on = simplebus0 >>> gpiobus1: on gpio1 >>> aw_nmi0: mem 0x1f00c0c-0x1f00c43 on = simplebus0 >>> generic_timer0: on ofwbus0 >>> Timecounter "cy 24000000 Hz quality 1000 >>> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality = 1000 >>> cpulist0: on ofwbus0 >>> cpu0: on cpulist0 >>> cpu1: on cpulist0 >>> cpu2: on cpulist0 >>> cpu3: on cpulist0 >>> cpu4: on cpulist0 >>> cpu5: on cpulist0 >>> cpu6: on cpulist0 >>> cpu7: on cpulist0 >>> a10_mmc0: mem = 0x1c0f000-0x1c0ffff on simplebus0 >>> mmc0: on a10_mmc0 >>> a10_mmc1: mem = 0x1c11000-0x1c11fff on simplebus0 >>> mmc1: on a10_mmc1 >>> gpioc0: on gpio0 >>> aw_wdog0: mem 0x1c20ca0-0x1c20cbf on = simplebus0 >>> uart0: mem = 0x1c28000-0x1c283ff on simplebus0 >>> uart0: console (480769,n,8,1) >>> gpioc1: on gpio1 >>> iichb3: mem 0x1f03400-0x1f037ff on simplebus0 >>> iicbus3: on iichb3 >>> iic0: on iicbus3 >>> axp81x_pmu0: at addr 0x746 = on iicbus3 >>> gpiobus2: on axp81x_pmu0 >>> gpioled0: at pin 0 on gpiobus2 >>> gpioled1: at pin 1 on gpiobus2 >>> gpioc2: on axp81x_pmu0 >>> iic1: on iicbus0 >>> iic2: on iicbus1 >>> iic3: on iicbus2 >>> ehci0: mem = 0x1c1a000-0x1c1a0ff on simplebus0 >>> usbus0: EHCI version 1.0 >>> usbus0 on ehci0 >>> ehci1: mem = 0x1c1b000-0x1c1b0ff on simplebus0 >>> usbus1: EHCI version 1.0 >>> usbus1 on ehci1 >>> awg0: mem 0x1c30000-0x1c300ff on = simplebus0 >>> miibus0: on awg0 >>> rgephy0: PHY 0 on = miibus0 >>> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FD >>> X-flow-master, auto, auto-flow >>> rgephy1: PHY 1 on = miibus0 >>> rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FD >>> X-flow-master, auto, auto-flow >>> awg0: Ethernet address: f2:00:52:68:6d:d8 >>> aw_thermal0: mem = 0x1f04000-0x1f043ff on simplebus0 >>> cryptosoft0: >>> Timecounters tick every 10.000 msec >>> usbus0: 480Mbps High Speed USB v2.0 >>> usbus1: 480Mbps High Speed USB v2.0 >>> ugen1.1: at usbus1 >>> ugen0.1: at usbus0 >>> uhub0: = on usbus0 >>> uhub1: = on usbus1 >>> mmcsd0: 32GB at = mmc0 50.0MHz/4bit/65535-block >>> a10_mmc1: error rint: 0x00000100 >>> a10_mmc1: error rint: 0x00000100 >>> a10_mmc1: error rint: 0x00000100 >>> a10_mmc1: error rint: 0x00000100 >>> a10_mmc1: error rint: 0x00000100 >>> a10_mmc1: error rint: 0x00000100 >>> a10_mmc1: error rint: 0x00000100 >>> a10_mmc1: error rint: 0x00000100 >>> a10_mmc1: error rint: 0x00008018 >>> a10_mmc1: error rint: 0x00000100 >>> a10_mmc1: error rint: 0x00000100 >>> a10_mmc1: error rint: 0x00000100 >>> a10_mmc1: error rint: 0x00000100 >>> mmcsd1: 8GB = at mmc1 50.0MHz/8bit/65535-block >>> Release APs >>> Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... >>> warning: no time-of-day clock registered, system time will not be = set accurately >>> uhub0: 1 port with 1 removable, self powered >>> uhub1: 1 port with 1 removable, self powered >>> ugen0.2: at usbus0 >>> uhub2 on uhub0 >>> uhub2: = on usbus0 >>> uhub2: 4 ports with 4 removable, self powered >>> ugen0.3: at usbus0 >>> umass0 on uhub2 >>> umass0: on usbus0 >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error >>> (probe0:umass-sim0:0:0:0): Retrying command >>> random: unblocking device. >>> awg0: link state changed to DOWN >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error >>> (probe0:umass-sim0:0:0:0): Retrying command >>> awg0: link state changed to UP >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error >>> (probe0:umass-sim0:0:0:0): Retrying command >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error >>> (probe0:umass-sim0:0:0:0): Retrying command >>> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 >>> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error >>> (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted >>=20 >> So far the probe0 messages stop after just a few like the above. >>=20 >> Also it looks like the 8GB eMMC (mmc1 / mmcsd1) is likely not = supported yet. >>=20 >> I have not yet tried connecting an external usb drive. >>=20 >> Some structure of what was done with the cores shows in the sysctl -a = output: cpu names 0-3 and 100-103. >>=20 >> (Note: the serial connection tends to drop some text sometimes. That = may have happened some for the below.) >>=20 >>> root@bananapi-m3:~ # sysctl -a | grep cpu >>> kern.smp.cpus: 4 >>> kern.smp.maxcpus: 4 >>> kern.ccpu: 0 >>> 0, 1, 2, 3 >>> 0, 1, 2, 3 >>> kern.sched.cpusetsize: 4 >>> kern.pin_pcpu_swi: 0 >>> kern.vt.splash_cpu_duration: 10 >>> kern.vt.splash_cpu_style: 2 >>> kern.vt.splash_ncpu: 0 >>> kern.vt.splash_cpu: 0 >>> net.inet.tcp.per_cpu_timers: 0 >>> debug.PMAP1changedcpu: 106 >>> debug.cpufreq.verbose: 0 >>> debug.cpufreq.lowest: 0 >>> hw.ncpu: 4 >>> dev.cpu.7.%parent: cpulist0 >>> dev.cpu.7.%pnpinfo: name=3Dcpu@103 compat=3Darm,cortex-a7 >>> dev.cpu.7.%location:=20 >>> dev.cpu.7.%driver: cpu >>> dev.cpu.7.%desc: Open Firmware CPU >>> dev.cpu.6.%parent: cpulist0 >>> dev.cpu.6.%pnpinfo: name=3Dcpu@102 compat=3Darm,cortex-a7 >>> dev.cpu.6.%location:=20 >>> dev.cpu.6.%driver: cpu >>> dev.cpu.6.%desc: Open Firmware CPU >>> dev.cpu.5.%parent: cpulist0 >>> dev.cpu.5.%pnpinfo: name=3Dcpu@101 compat=3Darm,cortex-a7 >>> dev.cpu.5.%location:=20 >>> dev.cpu.5.%dri.5.%desc: Open Firmware CPU >>> dev.cpu.4.%parent: cpulist0 >>> dev.cpu.4.%pnpinfo: name=3Dcpu@100 compat=3Darm,cortex-a7 >>> dev.cpu.4.%location:=20 >>> dev.cpu.4.%driver: cpu >>> dev.cpu.4.%desc: Open Firmware CPU >>> dev.cpu.3.%parent: cpulist0 >>> dev.cpu.3.%pnpinfo: name=3Dcpu@3 compat=3Darm,cortex-a7 >>> dev.cpu.3.%location:=20 >>> dev.cpu.3.%driver: cpu >>> dev.cpu.3.%desc: Open Firmware CPU >>> dev.cpu.2.%parent: cpulist0 >>> dev.cpu.2.%pnpinfo: name=3Dcpu@2 compat=3Darm,cortex-a7 >>> dev.cpu.2.%location:=20 >>> dev.cpu.2.%driver: cpu >>> dev.cpu.2.%desc: Open Firmware CPU >>> dev.cpu.1.%parent: cpulist0 >>> dev.cpu.1.%location:=20 >>> dev.cpu.1.%driver: cpu >>> dev.cpu.1.%desc: Open Firmware CPU >>> dev.cpu.0.%parent: cpulist0 >>> dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,cortex-a7 >>> dev.cpu.0.%location:=20 >>> dev.cpu.0.%driver: cpu >>> dev.cpu.0.%desc: Open Firmware CPU >>> dev.cpu.0.%parent: cpulist0 >>> dev.cpulist.0.%parent: ofwbus0 >>> dev.cpulist.0.%pnpinfo: name=3Dcpus >>> dev.cpulist.0.%location:=20 >>> dev.cpulist.0.%driver: cpulist >>> dev.cpulist.0.%desc: Open Firmware CPU Group >>> dev.cpulist.%parent:=20 >>> dev.aw_cpusclk.0.%parent: aw_ccu0 >>> dev.aw_cpusclk.0.%pnpinfo: name=3Dclk@01f0140inner,sun8i-a83t-cpus-clk= >>> dev.aw_cpusclk.0.%location:=20 >>> dev.aw_cpusclk.0.%driver: aw_cpusclk >>> dev.aw_cpusclk.0.%desc: Allwinner CPUS Clock >>> dev.aw_cpusclk.%parent:=20 >>> security.jail.param.cpuset.id: 0 >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >=20 > --=20 > Emmanuel Vadot =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Tue Oct 25 17:16:46 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A41DEC21409 for ; Tue, 25 Oct 2016 17:16:46 +0000 (UTC) (envelope-from uspensky@x-art.ru) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9277B1C2A for ; Tue, 25 Oct 2016 17:16:46 +0000 (UTC) (envelope-from uspensky@x-art.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 91D69C21408; Tue, 25 Oct 2016 17:16:46 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91855C21406 for ; Tue, 25 Oct 2016 17:16:46 +0000 (UTC) (envelope-from uspensky@x-art.ru) Received: from x-art.ru (charibdis.x-art.ru [80.70.228.55]) by mx1.freebsd.org (Postfix) with ESMTP id 3D73B1C29 for ; Tue, 25 Oct 2016 17:16:45 +0000 (UTC) (envelope-from uspensky@x-art.ru) Received: from gw-old.x-art.ru (gw-old.x-art.ru [192.168.172.252]) by mta.x-art.ru (Postfix) with ESMTP id 6A3231BF37E; Tue, 25 Oct 2016 20:06:58 +0300 (MSK) Date: Tue, 25 Oct 2016 20:06:58 +0300 (MSK) From: Antony Uspensky X-X-Sender: aiu@gw-old.x-art.ru To: "Eugene M. Zheganin" cc: "stable@freebsd.org" Subject: Re: zfs/raidz: seems like I'm failing with math In-Reply-To: <75ef50fa-0e0a-c576-c558-145ddcb32f0b@norma.perm.ru> Message-ID: References: <75ef50fa-0e0a-c576-c558-145ddcb32f0b@norma.perm.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 17:16:46 -0000 On Mon, 17 Oct 2016, Eugene M. Zheganin wrote: > Thanks ! It does explain it. But then again, on a pool that has been just > created, I check the properties of the root dataset (I'm posting all the > properties, just to display there's no child datasets or data on the pool): > > ===Cut=== > # zfs get all gamestop > NAME PROPERTY VALUE SOURCE > gamestop checksum on default > ===Cut=== > > Only 4.03T is available. Looks like it's the actual size, since it's zfs and > not zpool. But 960197124096 bytes * 5 / 1024^4 gives me 4.366 Tb, and not the > 4.03 T. Where did about 300 gigs go ? I'm really trying to understand, not to > catch some questionable logic or find errors. Checksums and zfs data structures - less then 8% of total space. Not too expensive. And do not confuse checksums (zfs level) and parity (zpool). But this is estimated available space for empty pool. Real allocated space for filled up pool will be a bit less then 4.03T due to padding - read https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz A. From owner-freebsd-stable@freebsd.org Tue Oct 25 18:40:41 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E789C21837 for ; Tue, 25 Oct 2016 18:40:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-32.reflexion.net [208.70.210.32]) (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 E813EE3D for ; Tue, 25 Oct 2016 18:40:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26535 invoked from network); 25 Oct 2016 18:40:28 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Oct 2016 18:40:28 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Tue, 25 Oct 2016 14:40:47 -0400 (EDT) Received: (qmail 16205 invoked from network); 25 Oct 2016 18:40:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Oct 2016 18:40:47 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C49FDEC903A; Tue, 25 Oct 2016 11:40:38 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Subject: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call Message-Id: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> Date: Tue, 25 Oct 2016 11:40:38 -0700 Cc: FreeBSD Toolchain , FreeBSD Current To: freebsd-arm , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3226) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 18:40:41 -0000 [The following has been reported in: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213778 .] In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In = trying to track things down I ran into truss getting a SIGSEGV when it = tries to handle the situation. . . In truss's enter_syscall there is (from a live gdb on truss, after the = segmentation fault): 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); 381 if (t->cs.name =3D=3D NULL) (gdb)=20 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", 383 t->proc->abi->type, t->cs.number); 384=09 385 sc =3D get_syscall(t->cs.name, narg); 386 t->cs.nargs =3D sc->nargs; 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); 388=09 389 t->cs.sc =3D sc; (gdb) print *t $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D = 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name =3D= 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec =3D= 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D 492496630}} (gdb) print sc $3 =3D (struct syscall *) 0x0 So line 386 listed above gets a segmentation fault for sc->nargs when = t->cs.name is a NULL pointer: sc ends up NULL. Looking at the two things that the fprintf on lines 382 and 383 would = report: (gdb) print t->proc->abi->type $4 =3D 0x10166 "FreeBSD ELF32" (gdb) print t->cs.number $5 =3D 580828064 (gdb) print narg $6 =3D 0 (that last is for context for the get_syscall arguments). FYI: 580828064 =3D 0x229EBBA0 Context: root@bananapi-m3:/usr/ports # uname -apKU FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct = 24 00:41:16 PDT 2016 = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm armv6 1100505 1100505 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Tue Oct 25 18:40:41 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E644C21849 for ; Tue, 25 Oct 2016 18:40:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-31.reflexion.net [208.70.210.31]) (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 0E6F1E40 for ; Tue, 25 Oct 2016 18:40:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26511 invoked from network); 25 Oct 2016 18:40:28 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Oct 2016 18:40:28 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Tue, 25 Oct 2016 14:40:47 -0400 (EDT) Received: (qmail 16136 invoked from network); 25 Oct 2016 18:40:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Oct 2016 18:40:47 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8E626EC8814; Tue, 25 Oct 2016 11:40:38 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Subject: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call Message-Id: Date: Tue, 25 Oct 2016 11:40:38 -0700 Cc: FreeBSD Toolchain , FreeBSD Current To: freebsd-arm , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3226) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 18:40:41 -0000 [The following has been reported in: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213778 .] In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In = trying to track things down I ran into truss getting a SIGSEGV when it = tries to handle the situation. . . In truss's enter_syscall there is (from a live gdb on truss, after the = segmentation fault): 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); 381 if (t->cs.name =3D=3D NULL) (gdb)=20 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", 383 t->proc->abi->type, t->cs.number); 384=09 385 sc =3D get_syscall(t->cs.name, narg); 386 t->cs.nargs =3D sc->nargs; 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); 388=09 389 t->cs.sc =3D sc; (gdb) print *t $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D = 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name =3D= 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec =3D= 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D 492496630}} (gdb) print sc $3 =3D (struct syscall *) 0x0 So line 386 listed above gets a segmentation fault for sc->nargs when = t->cs.name is a NULL pointer: sc ends up NULL. Looking at the two things that the fprintf on lines 382 and 383 would = report: (gdb) print t->proc->abi->type $4 =3D 0x10166 "FreeBSD ELF32" (gdb) print t->cs.number $5 =3D 580828064 (gdb) print narg $6 =3D 0 (that last is for context for the get_syscall arguments). FYI: 580828064 =3D 0x229EBBA0 Context: root@bananapi-m3:/usr/ports # uname -apKU FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct = 24 00:41:16 PDT 2016 = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm armv6 1100505 1100505 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Tue Oct 25 21:32:12 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B7B7C21E92 for ; Tue, 25 Oct 2016 21:32:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-33.reflexion.net [208.70.210.33]) (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 DFD586C2 for ; Tue, 25 Oct 2016 21:32:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3949 invoked from network); 25 Oct 2016 21:32:18 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Oct 2016 21:32:18 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Tue, 25 Oct 2016 17:32:18 -0400 (EDT) Received: (qmail 22302 invoked from network); 25 Oct 2016 21:32:17 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Oct 2016 21:32:17 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 151B0EC903A; Tue, 25 Oct 2016 14:32:09 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Subject: stable/11 -r307797 on BPi-M3 (cortex-a7): xgcc's cc1 during lang/gcc6 build gets SIGSYS failures (/usr/ports -r424540) Message-Id: <5340B95D-9B61-4D97-A28E-EB463C28C949@dsl-only.net> Date: Tue, 25 Oct 2016 14:32:08 -0700 Cc: FreeBSD Toolchain , FreeBSD Current To: freebsd-arm , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3226) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 21:32:12 -0000 [I'll be submitting some of the below information to bugzilla.] While trying to build lang/gcc6 on a BPI-M3 (Cortex-A7, ALLWINNER) I got = "xgcc: internal compiler error: Bad system call (program cc1)", which = means a SIGSYS (signal 12) resulted. [I will note that I'v never seen this issue (so far) on the rpi2: This = may be KERNCONF=3DALLWINNER specific. But I've not yet updated to = -r307797 on the rpi2. The BPI-M3 context is new for me; the rpi2 I've = been using for a long time.] This was under/on: root@bananapi-m3:/usr/ports # uname -apKU FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct = 24 00:41:16 PDT 2016 = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm armv6 1100505 1100505 [Note this was cross-built and then a matching svnlite co was done on = the BPi-M3. So the source timestamps on the BPi-M3 are newer than the = times from the cross build.] root@bananapi-m3:/usr/ports # svnlite info /usr/ports/ | grep "Re[lv]" Relative URL: ^/head Revision: 424540 Last Changed Rev: 424540 dmesg | tail shows: pid 29581 (cc1), uid 0: exited on signal 12 (core dumped) pid 29613 (cc1), uid 0: exited on signal 12 (core dumped) pid 29622 (cc1), uid 0: exited on signal 12 (core dumped) pid 29651 (cc1), uid 0: exited on signal 12 (core dumped) pid 29660 (cc1), uid 0: exited on signal 12 (core dumped) pid 29798 (cc1), uid 0: exited on signal 12 (core dumped) pid 30422 (cc1), uid 0: exited on signal 12 (core dumped) pid 30426 (cc1), uid 0: exited on signal 12 (core dumped) pid 30428 (cc1), uid 0: exited on signal 12 (core dumped) pid 30431 (cc1), uid 0: exited on signal 12 (core dumped) (All the lang/gcc6 prerequisites built okay on the BPi-M3.) Unfortunately direct execution of the cc1 command on the libgcc2.i from = a use of -save-temps does not fail. For some reason the failure is only = when xgcc causes the cc1 command execution. Also unfortunately truss gets a segmentation fault of its own trying the = handle watching the SIGSYS related activity. (A truss bugzilla report = has been made.) Thus the following tail of the truss output for leading = up to the SIGSYS does not cover the SIGSYS related activity itself: = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # tail truss.log 31183 100086: close(3) =3D 0 (0x0) 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' 31183 100086: openat(AT_FDCWD,"./longlong.h",O_NOCTTY,00) ERR#2 'No such = file or directory' 31183 100086: openat(AT_FDCWD,"../.././gcc/longlong.h",O_NOCTTY,00) = ERR#2 'No such file or directory' 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/../gcc/longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/../include/longlong.h",O_NOCTTY,00) =3D 3 (0x3) 31183 100086: fstat(3,{ mode=3D-rw-r--r-- = ,inode=3D573594,size=3D61185,blksize=3D32768 }) =3D 0 (0x0) 31183 100086: read(3,"/* longlong.h -- definitions for"...,61185) =3D = 61185 (0xef01) 31183 100086: close(3) =3D 0 (0x0) 31183 100086: = mmap(0x0,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,16384,0x100000000= ) Via using gdb on truss [with truss running xgcc and xgcc in turn running = its cc1 instance]: = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # gdb truss . . . [the below is in enter_syscall] . . . 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); 381 if (t->cs.name =3D=3D NULL) (gdb)=20 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", 383 t->proc->abi->type, t->cs.number); 384=09 385 sc =3D get_syscall(t->cs.name, narg); 386 t->cs.nargs =3D sc->nargs; 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); 388=09 389 t->cs.sc =3D sc; (t->cs.name =3D=3D NULL after line 380). . . Looking at the two things that the fprintf on lines 382 and 383 would = report: (gdb) print t->proc->abi->type $4 =3D 0x10166 "FreeBSD ELF32" (gdb) print t->cs.number $5 =3D 580828064 FYI: 580828064 =3D 0x229EBBA0 (sc =3D=3D NULL results from line 385 so sc->nargs on line 386 gets a = SIGSEGV.) Just for completness: (gdb) print *t $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D = 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name =3D= 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec =3D = 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D 492496630}} (gdb) print sc $3 =3D (struct syscall *) 0x0 Supporting details follow. . . The specific error reports are: xgcc: internal compiler error: Bad system call (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[5]: *** [Makefile:467: _muldi3.o] Error 4 gmake[5]: *** Waiting for unfinished jobs.... xgcc: internal compiler error: Bad system call (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[5]: *** [Makefile:467: _negdi2.o] Error 4 xgcc: internal compiler error: Bad system call (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[5]: *** [Makefile:467: _cmpdi2.o] Error 4 xgcc: internal compiler error: Bad system call (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[5]: *** [Makefile:467: _ucmpdi2.o] Error 4 gmake[5]: Leaving directory = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd1= 1.0/libgcc' gmake[4]: *** [Makefile:14874: all-stage1-target-libgcc] Error 2 The specific xgcc commands were: /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _negdi2.o -MT _negdi2.o -MD -MP -MF _negdi2.dep = -DL_negdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _cmpdi2.o -MT _cmpdi2.o -MD -MP -MF _cmpdi2.dep = -DL_cmpdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _ucmpdi2.o -MT _ucmpdi2.o -MD -MP -MF _ucmpdi2.dep = -DL_ucmpdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS Unfortunately gdb does not report much directly. . . root@bananapi-m3:/usr/ports # gdb = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/cc1 = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11= .0/libgcc/cc1.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 "armv6-marcel-freebsd"... Core was generated by = `/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 -quiet -I = . -I . -I'. Program terminated with signal 12, Bad system call. Reading symbols from /usr/local/lib/libmpc.so.3...done. Loaded symbols for /usr/local/lib/libmpc.so.3 Reading symbols from /usr/local/lib/libmpfr.so.4...done. Loaded symbols for /usr/local/lib/libmpfr.so.4 Reading symbols from /usr/local/lib/libgmp.so.10...done. Loaded symbols for /usr/local/lib/libgmp.so.10 Reading symbols from /lib/libz.so.6...Reading symbols from = /usr/lib/debug//lib/libz.so.6.debug...done. done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/lib/libc++.so.1...Reading symbols from = /usr/lib/debug//usr/lib/libc++.so.1.debug...done. done. Loaded symbols for /usr/lib/libc++.so.1 Reading symbols from /lib/libcxxrt.so.1...Reading symbols from = /usr/lib/debug//lib/libcxxrt.so.1.debug...done. done. Loaded symbols for /lib/libcxxrt.so.1 Reading symbols from /lib/libm.so.5...Reading symbols from = /usr/lib/debug//lib/libm.so.5.debug...done. done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...Reading symbols from = /usr/lib/debug//lib/libgcc_s.so.1.debug...done. done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. Loaded symbols for /libexec/ld-elf.so.1 #0 0xbfbf732c in ?? () (gdb) bt #0 0xbfbf732c in ?? () Cannot access memory at address 0x0 (gdb) info reg r0 0x4e 78 r1 0x0 0 r2 0x17c8506 24937734 r3 0x65 101 r4 0xbfbf7488 -1077971832 r5 0xbfbf7484 -1077971836 r6 0xbfbf7488 -1077971832 r7 0x229eab40 580823872 r8 0x0 0 r9 0xbfbfa23c -1077960132 r10 0xbfbf7484 -1077971836 r11 0x0 0 r12 0x17ef3b1 25097137 sp 0xbfbf7180 -1077972608 lr 0x65 101 pc 0xbfbf732c -1077972180 fps 0x0 0 cpsr 0xa0000010 -1610612720 Using -v -save-temps on one of the failing xgcc command lines gives: = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS -v -save-temps xgcc: warning: -pipe ignored because -save-temps specified Reading specs from = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/specs = COLLECT_GCC=3D/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgc= c Target: armv6-portbld-freebsd11.0 Configured with: = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/configure = --disable-multilib --with-build-config=3Dbootstrap-debug --disable-nls = --enable-gnu-indirect-function --libdir=3D/usr/local/lib/gcc6 = --libexecdir=3D/usr/local/libexec/gcc6 --program-suffix=3D6 = --with-as=3D/usr/local/bin/as --with-gmp=3D/usr/local = --with-gxx-include-dir=3D/usr/local/lib/gcc6/include/c++/ = --with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports = Collection' --with-system-zlib --disable-libgcj = --enable-languages=3Dc,c++,objc,fortran --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/gcc6 --build=3Darmv6-portbld-freebsd11.0 Thread model: posix gcc version 6.2.0 (FreeBSD Ports Collection)=20 COLLECT_GCC_OPTIONS=3D'-B' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/bin/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/lib/' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/include' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/sys-include' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-O2' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-D' 'IN_GCC' '-Wextra' '-Wall' '-Wno-narrowing' '-Wwrite-strings' = '-Wcast-qual' '-Wformat=3D0' '-Wstrict-prototypes' = '-Wmissing-prototypes' '-Wold-style-definition' '-isystem' './include' = '-pthread' '-g' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc' = '-fno-stack-protector' '-fPIC' '-pthread' '-fno-inline' = '-fomit-frame-pointer' '-I' '.' '-I' '.' '-I' '../.././gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/.' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc' = '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include' = '-D' 'HAVE_CC_TLS' '-o' '_muldi3.o' '-MT' '_muldi3.o' '-MD' '-MP' '-MF' = '_muldi3.dep' '-D' 'L_muldi3' '-c' '-fvisibility=3Dhidden' '-D' = 'HIDE_EXPORTS' '-v' '-save-temps' '-mtls-dialect=3Dgnu' /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 -E -quiet = -v -I . -I . -I ../.././gcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -iprefix = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/arm= v6-portbld-freebsd11.0/6.2.0/ -isystem = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include = -isystem = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include-fixed = -MD _muldi3.d -MF _muldi3.dep -MP -MT _muldi3.o -D LIBICONV_PLUG -D = LIBICONV_PLUG -D IN_GCC -D IN_LIBGCC2 -D HAVE_CC_TLS -D L_muldi3 -D = HIDE_EXPORTS -isystem /usr/local/armv6-portbld-freebsd11.0/include = -isystem /usr/local/armv6-portbld-freebsd11.0/sys-include -isystem = ./include = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -mcpu=3Dcortex-a7 -mcpu=3Dcortex-a7 -mtls-dialect=3Dgnu -Wextra -Wall = -Wno-narrowing -Wwrite-strings -Wcast-qual -Wformat=3D0 = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -fno-strict-aliasing -fbuilding-libgcc -fno-stack-protector -fPIC = -fno-inline -fomit-frame-pointer -fvisibility=3Dhidden -g -g -g = -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o libgcc2.i ignoring nonexistent directory = "/usr/local/armv6-portbld-freebsd11.0/include" ignoring nonexistent directory = "/usr/local/armv6-portbld-freebsd11.0/sys-include" ignoring nonexistent directory "./include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/include-fixed" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/../../../../../armv6-portbld-freebsd11.0/inc= lude" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/include-fixed" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/../../../../../armv6-p= ortbld-freebsd11.0/include" ignoring duplicate directory "." ignoring duplicate directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/." #include "..." search starts here: #include <...> search starts here: . ../.././gcc /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include-fixed /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS=3D'-B' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/bin/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/lib/' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/include' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/sys-include' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-O2' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-D' 'IN_GCC' '-Wextra' '-Wall' '-Wno-narrowing' '-Wwrite-strings' = '-Wcast-qual' '-Wformat=3D0' '-Wstrict-prototypes' = '-Wmissing-prototypes' '-Wold-style-definition' '-isystem' './include' = '-pthread' '-g' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc' = '-fno-stack-protector' '-fPIC' '-pthread' '-fno-inline' = '-fomit-frame-pointer' '-I' '.' '-I' '.' '-I' '../.././gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/.' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc' = '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include' = '-D' 'HAVE_CC_TLS' '-o' '_muldi3.o' '-MT' '_muldi3.o' '-MD' '-MP' '-MF' = '_muldi3.dep' '-D' 'L_muldi3' '-c' '-fvisibility=3Dhidden' '-D' = 'HIDE_EXPORTS' '-v' '-save-temps' '-mtls-dialect=3Dgnu' /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 = -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mcpu=3Dcortex-a7 = -mcpu=3Dcortex-a7 -mtls-dialect=3Dgnu -auxbase-strip _muldi3.o -g -g -g = -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual = -Wformat=3D0 -Wstrict-prototypes -Wmissing-prototypes = -Wold-style-definition -version -fno-strict-aliasing -fbuilding-libgcc = -fno-stack-protector -fPIC -fno-inline -fomit-frame-pointer = -fvisibility=3Dhidden -o libgcc2.s GNU C11 (FreeBSD Ports Collection) version 6.2.0 = (armv6-portbld-freebsd11.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 GNU C11 (FreeBSD Ports Collection) version 6.2.0 = (armv6-portbld-freebsd11.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 Compiler executable checksum: 8858bcab14af90339532fc36ec745f79 xgcc: internal compiler error: Bad system call (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # ls -lt | head total 12712 -rw------- 1 root wheel 12181504 Oct 25 16:57 cc1.core -rw-r--r-- 1 root wheel 0 Oct 25 16:57 libgcc2.s -rw-r--r-- 1 root wheel 108880 Oct 25 16:57 libgcc2.i -rw-r--r-- 1 root wheel 7636 Oct 25 16:57 _muldi3.dep -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _ucmpdi2.o -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _cmpdi2.o -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _negdi2.o -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _muldi3.o -rw-r--r-- 1 root wheel 1784 Oct 25 10:16 _dvmd_lnx_s.o Unfortunately direct execution of the reported cc1 command on the = libgcc2.i in question does not fail. Attempting to run the xgcc command under truss got a segmentation fault = in truss itself: = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # truss -faeH -o truss.log = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC -W = -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem = ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS Segmentation fault (core dumped) [There is a separate buzilla report about this truss failure.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Wed Oct 26 08:36:10 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FC0EC21CCB for ; Wed, 26 Oct 2016 08:36:10 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BB7D3F62 for ; Wed, 26 Oct 2016 08:36:08 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id u9Q89dwP010814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Oct 2016 10:09:40 +0200 (CEST) (envelope-from egrosbein@rdtc.ru) X-Envelope-From: egrosbein@rdtc.ru X-Envelope-To: Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id u9Q89V2h049237 for ; Wed, 26 Oct 2016 15:09:31 +0700 (KRAT) (envelope-from egrosbein@rdtc.ru) To: FreeBSD Stable From: Eugene Grosbein Subject: Dying jail X-Enigmail-Draft-Status: N1110 Message-ID: <581064BB.1030500@rdtc.ru> Date: Wed, 26 Oct 2016 15:09:31 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-Report: * 2.7 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * 0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 08:36:10 -0000 Hi! Recently I've upgraded one of my server running 9.3-STABLE with jail containing 4.11-STABLE system. The host was source-upgraded upto 10.3-STABLE first and next to 11.0-STABLE and jail configuration migrated to /etc/jail.conf. The jail kept intact. "service jail start" started the jail successfully but "service jail restart" fails due to jail being stuck in "dying" state for long time: "jls" shows no running jails and "jls -d" shows the dying jail. How do I know why is it stuck and how to forcebly kill it without reboot of the host? Eugene Grosbein From owner-freebsd-stable@freebsd.org Wed Oct 26 08:46:06 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21C32C22452 for ; Wed, 26 Oct 2016 08:46:06 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A8E1DAA9 for ; Wed, 26 Oct 2016 08:46:05 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from ox-dell39.ox.adestra.com (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id E7F91E833 for ; Wed, 26 Oct 2016 08:46:00 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/E7F91E833; dkim=none; dkim-atps=neutral Subject: Re: Dying jail To: freebsd-stable@freebsd.org References: <581064BB.1030500@rdtc.ru> From: Matthew Seaman Message-ID: <591438f4-7ae3-252a-c604-8491787ad9f0@freebsd.org> Date: Wed, 26 Oct 2016 09:45:50 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <581064BB.1030500@rdtc.ru> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7WhCgLKjuec0H16LvX9Ooi8obLxNwavln" X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 08:46:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7WhCgLKjuec0H16LvX9Ooi8obLxNwavln Content-Type: multipart/mixed; boundary="SjNsFvx2GHm0XXrEH7wiClAxaKXVUVe82"; protected-headers="v1" From: Matthew Seaman To: freebsd-stable@freebsd.org Message-ID: <591438f4-7ae3-252a-c604-8491787ad9f0@freebsd.org> Subject: Re: Dying jail References: <581064BB.1030500@rdtc.ru> In-Reply-To: <581064BB.1030500@rdtc.ru> --SjNsFvx2GHm0XXrEH7wiClAxaKXVUVe82 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/26/16 09:09, Eugene Grosbein wrote: > Recently I've upgraded one of my server running 9.3-STABLE with jail co= ntaining 4.11-STABLE system. > The host was source-upgraded upto 10.3-STABLE first and next to 11.0-ST= ABLE > and jail configuration migrated to /etc/jail.conf. The jail kept intact= =2E >=20 > "service jail start" started the jail successfully > but "service jail restart" fails due to jail being stuck in "dying" sta= te for long time: > "jls" shows no running jails and "jls -d" shows the dying jail. >=20 > How do I know why is it stuck and how to forcebly kill it without reboo= t of the host? I've seen this fairly frequently. I think it may have something to do with old network connections waiting to be cleaned up -- if you run sockstat it's all the stuff that gets listed at the end with lots of question marks. BICBW. One tip I've found is *not* to specify the JID number in jail.conf, and just let the system allocate a new one as it feels necessary. If you've scripting that uses the JID to operate on a specific jail, it's easy to substitute the jail name instead. Cheers, Matthew --SjNsFvx2GHm0XXrEH7wiClAxaKXVUVe82-- --7WhCgLKjuec0H16LvX9Ooi8obLxNwavln Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYEG1DAAoJEABRPxDgqeTnfMEQALad8X+gi1bB4ZNEaEkkV6Tb beIIlQYKiPFe6uvTZuDVxYAJRWlf0OmwCq/ZSh0KxWfueqzQh7faeQuAE5ihtVuR K2SUOQfQFihJ4lpT/3sxAeclEIiTIkILG5DVIEwJux0Lbaa1Vd8/IRkqnyErrO3u 9WRsqDPNe94xUdHFx2zqz2fJfOfAV2S1Nqu0PKJ06iSvphQanNfkqXfuwg5mF+z0 X6ptiR8faOkHBUlicN754MEuJQ0871JsxshIbP2+322DAyd4NYd8T5jp8CNFxqOe RWQN2iATU2DC6lDQ1kA0hNpCv4LokVUjtqGct7VRg9VbDNGlBq6euEzN9K8CBqkN YjjigWnSQuFfC1XbwZrJVaBYAdK9eZauSE2xiiJUaANjQbJ2W97McX9v1v/SWJv+ Y/LVi2oOtdmiNlX4VzEb91et345PSTl2THoSAMXb0ZhhZGzzeOPIT7bb/wmeaCEO DWwvFtIhc/WY2FlZCi3kzZDsx+MfeQN5IweAMzll6dXMFUX6O11ldiKpD5yGU4Lj uwwIy73Rpg5/aQy0DOV2ZEuQPsiWfOCsVWXxrMfFGufv/rI3rYxkTiSbkU6PK12K FM0uKqYiKV6Y4271YDYPBJY8nqFte7kIOMWuBpfNjzAOikYX1M0uw5TPHN7dkons bPTCzBt/XbbUypS2z3Pm =3vhu -----END PGP SIGNATURE----- --7WhCgLKjuec0H16LvX9Ooi8obLxNwavln-- From owner-freebsd-stable@freebsd.org Wed Oct 26 08:56:38 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F17AC22B2E for ; Wed, 26 Oct 2016 08:56:38 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EAC58630; Wed, 26 Oct 2016 08:56:37 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id u9Q8uX5G011047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Oct 2016 10:56:34 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: matthew@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id u9Q8uP7j065526; Wed, 26 Oct 2016 15:56:25 +0700 (KRAT) (envelope-from eugen@grosbein.net) Subject: Re: Dying jail To: Matthew Seaman , freebsd-stable@freebsd.org References: <581064BB.1030500@rdtc.ru> <591438f4-7ae3-252a-c604-8491787ad9f0@freebsd.org> From: Eugene Grosbein Message-ID: <58106FB9.6050307@grosbein.net> Date: Wed, 26 Oct 2016 15:56:25 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <591438f4-7ae3-252a-c604-8491787ad9f0@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * 2.7 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-Spam-Level: ** X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 08:56:38 -0000 On 26.10.2016 15:45, Matthew Seaman wrote: > On 10/26/16 09:09, Eugene Grosbein wrote: >> Recently I've upgraded one of my server running 9.3-STABLE with jail containing 4.11-STABLE system. >> The host was source-upgraded upto 10.3-STABLE first and next to 11.0-STABLE >> and jail configuration migrated to /etc/jail.conf. The jail kept intact. >> >> "service jail start" started the jail successfully >> but "service jail restart" fails due to jail being stuck in "dying" state for long time: >> "jls" shows no running jails and "jls -d" shows the dying jail. >> >> How do I know why is it stuck and how to forcebly kill it without reboot of the host? > > I've seen this fairly frequently. I think it may have something to do > with old network connections waiting to be cleaned up -- if you run > sockstat it's all the stuff that gets listed at the end with lots of > question marks. BICBW. My jails has public IPv4 distinct from host's one and sockstat shows no lines for jail's IP. > One tip I've found is *not* to specify the JID number in jail.conf, and > just let the system allocate a new one as it feels necessary. If you've > scripting that uses the JID to operate on a specific jail, it's easy to > substitute the jail name instead. I do not specify JID number in jail.conf. OTOH, its jail configuration section in jail.conf is numeric-named and the same number automatically assigned as its jid for unknown reason. From owner-freebsd-stable@freebsd.org Wed Oct 26 09:00:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39205C22F20 for ; Wed, 26 Oct 2016 09:00:36 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C465B8AD; Wed, 26 Oct 2016 09:00:35 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id u9Q90Vd2011083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Oct 2016 11:00:32 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: matthew@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id u9Q90SJo066770; Wed, 26 Oct 2016 16:00:28 +0700 (KRAT) (envelope-from eugen@grosbein.net) Subject: Re: Dying jail To: Matthew Seaman , freebsd-stable@freebsd.org References: <581064BB.1030500@rdtc.ru> <591438f4-7ae3-252a-c604-8491787ad9f0@freebsd.org> From: Eugene Grosbein Message-ID: <581070AC.4020100@grosbein.net> Date: Wed, 26 Oct 2016 16:00:28 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <591438f4-7ae3-252a-c604-8491787ad9f0@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * 2.7 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-Spam-Level: ** X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 09:00:36 -0000 On 26.10.2016 15:45, Matthew Seaman wrote: > One tip I've found is *not* to specify the JID number in jail.conf, and > just let the system allocate a new one as it feels necessary. If you've > scripting that uses the JID to operate on a specific jail, it's easy to > substitute the jail name instead. Thank you for the tip. I've renamed the section in /etc/jail.conf to start with non-numeric symbol and "service jail start" successfully started my jail assigning it JID 1 this time. Now "jls -d" shows me two jails having same IP address and path but distinct JIDs. From owner-freebsd-stable@freebsd.org Wed Oct 26 16:25:46 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2DCEC22395 for ; Wed, 26 Oct 2016 16:25:46 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 576DE61D for ; Wed, 26 Oct 2016 16:25:45 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id u9QGPdUl013227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Oct 2016 18:25:40 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: kraduk@gmail.com Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id u9QGPZ0p004870 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Oct 2016 23:25:35 +0700 (KRAT) (envelope-from eugen@grosbein.net) Subject: Re: Dying jail To: krad , FreeBSD stable References: <581064BB.1030500@rdtc.ru> From: Eugene Grosbein Message-ID: <5810D8FA.1080305@grosbein.net> Date: Wed, 26 Oct 2016 23:25:30 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 16:25:46 -0000 26.10.2016 20:40, krad пишет: > on a side note there is no such thing as 9.3-STABLE, but there are 9-STABLE and 9.3-RELENG. The difference being stable is a constantly moving thing where as releng is just security errata and bugfixes. 9-STABLE currently call itself 9.3-STABLE: # uname -r 9.3-STABLE See also https://svnweb.freebsd.org/base/stable/9/sys/conf/newvers.sh?revision=268592&view=markup#l34 From owner-freebsd-stable@freebsd.org Wed Oct 26 16:33:22 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B06B1C2262D for ; Wed, 26 Oct 2016 16:33:22 +0000 (UTC) (envelope-from uspensky@x-art.ru) Received: from x-art.ru (charibdis.x-art.ru [80.70.228.55]) by mx1.freebsd.org (Postfix) with ESMTP id 5E4BEB1D for ; Wed, 26 Oct 2016 16:33:21 +0000 (UTC) (envelope-from uspensky@x-art.ru) Received: from gw-old.x-art.ru (gw-old.x-art.ru [192.168.172.252]) by mta.x-art.ru (Postfix) with ESMTP id BD7DB1BF54D; Wed, 26 Oct 2016 19:33:18 +0300 (MSK) Date: Wed, 26 Oct 2016 19:33:18 +0300 (MSK) From: Antony Uspensky X-X-Sender: aiu@gw-old.x-art.ru To: adg@a-real.ru cc: freebsd-stable@freebsd.org Subject: Re: VT not showing cyrillic characters in text mode In-Reply-To: <382398c982b00cdf34eccb4f56950871@a-real.ru> Message-ID: References: <382398c982b00cdf34eccb4f56950871@a-real.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 16:33:22 -0000 On Wed, 19 Oct 2016, adg@a-real.ru wrote: > Hello everyone. > > Cannot figure out if vt console driver supports non-ansi characters when > started in textmode. The font in sys/dev/vt/vt_font_default.c seems to > include cyrillic glyphs, but either it is not being used in textmode or > something else is broken since only '?' are displayed instead of proper > symbols. The LANG/LC_ALL doesn't affect anything. The problem occurs on > 11.0-RELEASE and 10.3-RELEASE. > Textmode is required for me since vt performance in graphical mode is very > poor on HyperV and textmode looks like the only option. VT cannot load fonts in text mode - man vt. If you need loadable fonts in text mode console - use sc. From owner-freebsd-stable@freebsd.org Wed Oct 26 22:31:23 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F9EFC2383A for ; Wed, 26 Oct 2016 22:31:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-43.reflexion.net [208.70.210.43]) (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 E467F95B for ; Wed, 26 Oct 2016 22:31:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20193 invoked from network); 26 Oct 2016 22:24:25 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Oct 2016 22:24:25 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Wed, 26 Oct 2016 18:24:39 -0400 (EDT) Received: (qmail 32764 invoked from network); 26 Oct 2016 22:24:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Oct 2016 22:24:39 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 913A7EC9105; Wed, 26 Oct 2016 15:24:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: stable/11 -r307797 on BPi-M3 (cortex-a7): xgcc's cc1 during lang/gcc6 build gets SIGSYS failures (/usr/ports -r424540) From: Mark Millard In-Reply-To: <5340B95D-9B61-4D97-A28E-EB463C28C949@dsl-only.net> Date: Wed, 26 Oct 2016 15:24:34 -0700 Cc: FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <2DC2BFC1-613E-4491-84A4-3EC505B10B9D@dsl-only.net> References: <5340B95D-9B61-4D97-A28E-EB463C28C949@dsl-only.net> To: freebsd-arm , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 22:31:23 -0000 [A top post noting that user "ast" CSW's are involved and other details = in the sequence leading up to the failure.] Using "ktrace -i -t +fw" it looks like every repeat of the problem ends = up with the following sort of sequence (a variation is shown later): 34629 cc1 CALL = mmap(0,0x4000,0x3,0x1002,0xfff= fffff,0x1c,0,0) 34629 cc1 RET mmap 568225792/0x21de7000 34629 cc1 PFLT 0x21de7000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x21de8000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x21de9000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x21dea000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229e8000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229e9000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229ea000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 CSW stop user "ast" 34629 cc1 CSW resume user "ast" 34629 cc1 PFLT 0x229eb000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229ec000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 CALL [-17504] 34629 cc1 RET [-17504] -1 errno 78 Function not implemented 34629 cc1 PSIG SIGSYS SIG_DFL code=3DSI_KERNEL 34629 cc1 NAMI "cc1.core" 34630 as CSW stop kernel "piperd" 34630 as Events dropped. 34630 as RET read 0 34630 as CALL close(0) 34630 as RET close 0 . . . I'll note that for the source this was compiling I used gdb truss with = run -feH -o truss.log and it reported: (gdb) print t->cs.number $5 =3D 580828064 FYI: 580828064 =3D 0x229EBBA0 where the truss segmentation fault was at line 385 of the following = (sc=3D=3DNULL in the context): > 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); > 381 if (t->cs.name =3D=3D NULL) > (gdb)=20 > 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", > 383 t->proc->abi->type, t->cs.number); > 384=09 > 385 sc =3D get_syscall(t->cs.name, narg); > 386 t->cs.nargs =3D sc->nargs; > 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); > 388=09 > 389 t->cs.sc =3D sc; The 229E matched the upper part of local PFLT activity around the user = "ast" CSW's, including just before the bad call. But the details do vary some based on the source file being compiled. = For example here the user "ast" CSW's are just before the mmap but are = still just after the 0x229ea000 PFLT: 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0xbfbf2000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229e7000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229e8000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229e9000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229ea000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 CSW stop user "ast" 34698 cc1 CSW resume user "ast" 34698 cc1 CALL = mmap(0,0x4000,0x3,0x1002,0xfff= fffff,0,0,0) 34698 cc1 RET mmap 568225792/0x21de7000 34698 cc1 PFLT 0x21de7000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x21de8000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x21de9000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x21dea000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229eb000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 CALL [-25840] 34698 cc1 RET [-25840] -1 errno 78 Function not implemented 34698 cc1 PSIG SIGSYS SIG_DFL code=3DSI_KERNEL 34698 cc1 NAMI "cc1.core" 34699 as CSW stop kernel "piperd" 34699 as Events dropped. 34699 as RET read 0 34699 as CALL close(0) 34699 as RET close 0 -25840 in 2's complement is: 0xF...F9B10 Here doing the gdb truss instead reports: (gdb) print t->cs.number $1 =3D 580819728 and 580819728 =3D 0x229E9B10 and the 229E part matches several PFLT's in the area, including just = before the bad call as well as just before the user "ast"s. Between them = are some PFLT's that do not match. I would guess that the 229E in t->cs.number in truss is from the PFLT = just before the failing syscall in each case. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Oct-25, at 2:32 PM, Mark Millard wrote: > [I'll be submitting some of the below information to bugzilla.] >=20 > While trying to build lang/gcc6 on a BPI-M3 (Cortex-A7, ALLWINNER) I = got "xgcc: internal compiler error: Bad system call (program cc1)", = which means a SIGSYS (signal 12) resulted. >=20 > [I will note that I'v never seen this issue (so far) on the rpi2: This = may be KERNCONF=3DALLWINNER specific. But I've not yet updated to = -r307797 on the rpi2. The BPI-M3 context is new for me; the rpi2 I've = been using for a long time.] >=20 > This was under/on: >=20 > root@bananapi-m3:/usr/ports # uname -apKU > FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon = Oct 24 00:41:16 PDT 2016 = markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/AL= LWINNER arm armv6 1100505 1100505 >=20 > [Note this was cross-built and then a matching svnlite co was done on = the BPi-M3. So the source timestamps on the BPi-M3 are newer than the = times from the cross build.] >=20 > root@bananapi-m3:/usr/ports # svnlite info /usr/ports/ | grep "Re[lv]" > Relative URL: ^/head > Revision: 424540 > Last Changed Rev: 424540 >=20 > dmesg | tail shows: >=20 > pid 29581 (cc1), uid 0: exited on signal 12 (core dumped) > pid 29613 (cc1), uid 0: exited on signal 12 (core dumped) > pid 29622 (cc1), uid 0: exited on signal 12 (core dumped) > pid 29651 (cc1), uid 0: exited on signal 12 (core dumped) > pid 29660 (cc1), uid 0: exited on signal 12 (core dumped) > pid 29798 (cc1), uid 0: exited on signal 12 (core dumped) > pid 30422 (cc1), uid 0: exited on signal 12 (core dumped) > pid 30426 (cc1), uid 0: exited on signal 12 (core dumped) > pid 30428 (cc1), uid 0: exited on signal 12 (core dumped) > pid 30431 (cc1), uid 0: exited on signal 12 (core dumped) >=20 > (All the lang/gcc6 prerequisites built okay on the BPi-M3.) >=20 > Unfortunately direct execution of the cc1 command on the libgcc2.i = from a use of -save-temps does not fail. For some reason the failure is = only when xgcc causes the cc1 command execution. >=20 > Also unfortunately truss gets a segmentation fault of its own trying = the handle watching the SIGSYS related activity. (A truss bugzilla = report has been made.) Thus the following tail of the truss output for = leading up to the SIGSYS does not cover the SIGSYS related activity = itself: >=20 > = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # tail truss.log > 31183 100086: close(3) =3D 0 (0x0) > 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' > 31183 100086: openat(AT_FDCWD,"./longlong.h",O_NOCTTY,00) ERR#2 'No = such file or directory' > 31183 100086: openat(AT_FDCWD,"../.././gcc/longlong.h",O_NOCTTY,00) = ERR#2 'No such file or directory' > 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/../gcc/longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' > 31183 100086: = openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/lib= gcc/../include/longlong.h",O_NOCTTY,00) =3D 3 (0x3) > 31183 100086: fstat(3,{ mode=3D-rw-r--r-- = ,inode=3D573594,size=3D61185,blksize=3D32768 }) =3D 0 (0x0) > 31183 100086: read(3,"/* longlong.h -- definitions for"...,61185) =3D = 61185 (0xef01) > 31183 100086: close(3) =3D 0 (0x0) > 31183 100086: = mmap(0x0,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,16384,0x100000000= ) >=20 > Via using gdb on truss [with truss running xgcc and xgcc in turn = running its cc1 instance]: >=20 > = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # gdb truss > . . . [the below is in enter_syscall] . . . > 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); > 381 if (t->cs.name =3D=3D NULL) > (gdb)=20 > 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", > 383 t->proc->abi->type, t->cs.number); > 384=09 > 385 sc =3D get_syscall(t->cs.name, narg); > 386 t->cs.nargs =3D sc->nargs; > 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); > 388=09 > 389 t->cs.sc =3D sc; >=20 > (t->cs.name =3D=3D NULL after line 380). . . >=20 > Looking at the two things that the fprintf on lines 382 and 383 would = report: >=20 > (gdb) print t->proc->abi->type > $4 =3D 0x10166 "FreeBSD ELF32" >=20 > (gdb) print t->cs.number > $5 =3D 580828064 >=20 > FYI: 580828064 =3D 0x229EBBA0 >=20 > (sc =3D=3D NULL results from line 385 so sc->nargs on line 386 gets a = SIGSEGV.) >=20 > Just for completness: >=20 > (gdb) print *t > $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D = 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name =3D= 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 > s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec =3D= 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D 492496630}} >=20 > (gdb) print sc > $3 =3D (struct syscall *) 0x0 >=20 >=20 >=20 > Supporting details follow. . . >=20 > The specific error reports are: >=20 > xgcc: internal compiler error: Bad system call (program cc1) > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > gmake[5]: *** [Makefile:467: _muldi3.o] Error 4 > gmake[5]: *** Waiting for unfinished jobs.... >=20 > xgcc: internal compiler error: Bad system call (program cc1) > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > gmake[5]: *** [Makefile:467: _negdi2.o] Error 4 >=20 > xgcc: internal compiler error: Bad system call (program cc1) > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > gmake[5]: *** [Makefile:467: _cmpdi2.o] Error 4 >=20 > xgcc: internal compiler error: Bad system call (program cc1) > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > gmake[5]: *** [Makefile:467: _ucmpdi2.o] Error 4 >=20 > gmake[5]: Leaving directory = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd1= 1.0/libgcc' > gmake[4]: *** [Makefile:14874: all-stage1-target-libgcc] Error 2 >=20 > The specific xgcc commands were: >=20 > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc=20 > = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS >=20 > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc=20 > = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _negdi2.o -MT _negdi2.o -MD -MP -MF _negdi2.dep = -DL_negdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS >=20 > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc=20 > = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _cmpdi2.o -MT _cmpdi2.o -MD -MP -MF _cmpdi2.dep = -DL_cmpdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS >=20 > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc=20 > = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _ucmpdi2.o -MT _ucmpdi2.o -MD -MP -MF _ucmpdi2.dep = -DL_ucmpdi2 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS >=20 >=20 > Unfortunately gdb does not report much directly. . . >=20 > root@bananapi-m3:/usr/ports # gdb = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/cc1 = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11= .0/libgcc/cc1.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 "armv6-marcel-freebsd"... > Core was generated by = `/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 -quiet -I = . -I . -I'. > Program terminated with signal 12, Bad system call. > Reading symbols from /usr/local/lib/libmpc.so.3...done. > Loaded symbols for /usr/local/lib/libmpc.so.3 > Reading symbols from /usr/local/lib/libmpfr.so.4...done. > Loaded symbols for /usr/local/lib/libmpfr.so.4 > Reading symbols from /usr/local/lib/libgmp.so.10...done. > Loaded symbols for /usr/local/lib/libgmp.so.10 > Reading symbols from /lib/libz.so.6...Reading symbols from = /usr/lib/debug//lib/libz.so.6.debug...done. > done. > Loaded symbols for /lib/libz.so.6 > Reading symbols from /usr/lib/libc++.so.1...Reading symbols from = /usr/lib/debug//usr/lib/libc++.so.1.debug...done. > done. > Loaded symbols for /usr/lib/libc++.so.1 > Reading symbols from /lib/libcxxrt.so.1...Reading symbols from = /usr/lib/debug//lib/libcxxrt.so.1.debug...done. > done. > Loaded symbols for /lib/libcxxrt.so.1 > Reading symbols from /lib/libm.so.5...Reading symbols from = /usr/lib/debug//lib/libm.so.5.debug...done. > done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /lib/libgcc_s.so.1...Reading symbols from = /usr/lib/debug//lib/libgcc_s.so.1.debug...done. > done. > Loaded symbols for /lib/libgcc_s.so.1 > Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. > done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...Reading symbols from = /usr/lib/debug//libexec/ld-elf.so.1.debug...done. > done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0xbfbf732c in ?? () > (gdb) bt > #0 0xbfbf732c in ?? () > Cannot access memory at address 0x0 > (gdb) info reg > r0 0x4e 78 > r1 0x0 0 > r2 0x17c8506 24937734 > r3 0x65 101 > r4 0xbfbf7488 -1077971832 > r5 0xbfbf7484 -1077971836 > r6 0xbfbf7488 -1077971832 > r7 0x229eab40 580823872 > r8 0x0 0 > r9 0xbfbfa23c -1077960132 > r10 0xbfbf7484 -1077971836 > r11 0x0 0 > r12 0x17ef3b1 25097137 > sp 0xbfbf7180 -1077972608 > lr 0x65 101 > pc 0xbfbf732c -1077972180 > fps 0x0 0 > cpsr 0xa0000010 -1610612720 >=20 >=20 > Using -v -save-temps on one of the failing xgcc command lines gives: >=20 > = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC = -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/l > ang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS -v -save-temps > xgcc: warning: -pipe ignored because -save-temps specified > Reading specs from = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/specs > = COLLECT_GCC=3D/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgc= c > Target: armv6-portbld-freebsd11.0 > Configured with: = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/configure = --disable-multilib --with-build-config=3Dbootstrap-debug --disable-nls = --enable-gnu-indirect-function --libdir=3D/usr/local/lib/gcc6 = --libexecdir=3D/usr/local/libexec/gcc6 --program-suffix=3D6 = --with-as=3D/usr/local/bin/as --with-gmp=3D/usr/local = --with-gxx-include-dir=3D/usr/local/lib/gcc6/include/c++/ = --with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports = Collection' --with-system-zlib --disable-libgcj = --enable-languages=3Dc,c++,objc,fortran --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/gcc6 --build=3Darmv6-portbld-freebsd11.0 > Thread model: posix > gcc version 6.2.0 (FreeBSD Ports Collection)=20 > COLLECT_GCC_OPTIONS=3D'-B' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/bin/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/lib/' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/include' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/sys-include' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-O2' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-D' 'IN_GCC' '-Wextra' '-Wall' '-Wno-narrowing' '-Wwrite-strings' = '-Wcast-qual' '-Wformat=3D0' '-Wstrict-prototypes' = '-Wmissing-prototypes' '-Wold-style-definition' '-isystem' './include' = '-pthread' '-g' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc' = '-fno-stack-protector' '-fPIC' '-pthread' '-fno-inline' = '-fomit-frame-pointer' '-I' '.' '-I' '.' '-I' '../.././gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/.' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6 > .2.0/libgcc/../gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include' = '-D' 'HAVE_CC_TLS' '-o' '_muldi3.o' '-MT' '_muldi3.o' '-MD' '-MP' '-MF' = '_muldi3.dep' '-D' 'L_muldi3' '-c' '-fvisibility=3Dhidden' '-D' = 'HIDE_EXPORTS' '-v' '-save-temps' '-mtls-dialect=3Dgnu' > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 -E -quiet = -v -I . -I . -I ../.././gcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc -I = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -iprefix = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/arm= v6-portbld-freebsd11.0/6.2.0/ -isystem = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include = -isystem = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include-fixed = -MD _muldi3.d -MF _muldi3.dep -MP -MT _muldi3.o -D LIBICONV_PLUG -D = LIBICONV_PLUG -D IN_GCC -D IN_LIBGCC2 -D HAVE_CC_TLS -D L_muldi3 -D = HIDE_EXPORTS -isystem /usr/local/armv6-portbld-freebsd11.0/include = -isystem /usr/local/armv6-portbld-freebsd11.0/sys-include -isystem = ./include = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -mcp > u=3Dcortex-a7 -mcpu=3Dcortex-a7 -mtls-dialect=3Dgnu -Wextra -Wall = -Wno-narrowing -Wwrite-strings -Wcast-qual -Wformat=3D0 = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition = -fno-strict-aliasing -fbuilding-libgcc -fno-stack-protector -fPIC = -fno-inline -fomit-frame-pointer -fvisibility=3Dhidden -g -g -g = -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o libgcc2.i > ignoring nonexistent directory = "/usr/local/armv6-portbld-freebsd11.0/include" > ignoring nonexistent directory = "/usr/local/armv6-portbld-freebsd11.0/sys-include" > ignoring nonexistent directory "./include" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/include" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/include-fixed" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/ar= mv6-portbld-freebsd11.0/6.2.0/../../../../../armv6-portbld-freebsd11.0/inc= lude" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/include" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/include-fixed" > ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/gcc/../lib/gcc6/gcc/..= /../../lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/../../../../../armv6-p= ortbld-freebsd11.0/include" > ignoring duplicate directory "." > ignoring duplicate directory = "/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/." > #include "..." search starts here: > #include <...> search starts here: > . > ../.././gcc > /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc > /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc > = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/include-fixed > /usr/local/include > /usr/include > End of search list. > COLLECT_GCC_OPTIONS=3D'-B' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/bin/' '-B' = '/usr/local/armv6-portbld-freebsd11.0/lib/' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/include' '-isystem' = '/usr/local/armv6-portbld-freebsd11.0/sys-include' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-O2' '-O2' '-pipe' = '-mcpu=3Dcortex-a7' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-D' 'IN_GCC' '-Wextra' '-Wall' '-Wno-narrowing' '-Wwrite-strings' = '-Wcast-qual' '-Wformat=3D0' '-Wstrict-prototypes' = '-Wmissing-prototypes' '-Wold-style-definition' '-isystem' './include' = '-pthread' '-g' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc' = '-fno-stack-protector' '-fPIC' '-pthread' '-fno-inline' = '-fomit-frame-pointer' '-I' '.' '-I' '.' '-I' '../.././gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/.' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6 > .2.0/libgcc/../gcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include' = '-D' 'HAVE_CC_TLS' '-o' '_muldi3.o' '-MT' '_muldi3.o' '-MD' '-MP' '-MF' = '_muldi3.dep' '-D' 'L_muldi3' '-c' '-fvisibility=3Dhidden' '-D' = 'HIDE_EXPORTS' '-v' '-save-temps' '-mtls-dialect=3Dgnu' > /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 = -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mcpu=3Dcortex-a7 = -mcpu=3Dcortex-a7 -mtls-dialect=3Dgnu -auxbase-strip _muldi3.o -g -g -g = -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual = -Wformat=3D0 -Wstrict-prototypes -Wmissing-prototypes = -Wold-style-definition -version -fno-strict-aliasing -fbuilding-libgcc = -fno-stack-protector -fPIC -fno-inline -fomit-frame-pointer = -fvisibility=3Dhidden -o libgcc2.s > GNU C11 (FreeBSD Ports Collection) version 6.2.0 = (armv6-portbld-freebsd11.0) > compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3, isl version none > GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 > GNU C11 (FreeBSD Ports Collection) version 6.2.0 = (armv6-portbld-freebsd11.0) > compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3, isl version none > GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 > Compiler executable checksum: 8858bcab14af90339532fc36ec745f79 > xgcc: internal compiler error: Bad system call (program cc1) > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. >=20 > = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # ls -lt | head > total 12712 > -rw------- 1 root wheel 12181504 Oct 25 16:57 cc1.core > -rw-r--r-- 1 root wheel 0 Oct 25 16:57 libgcc2.s > -rw-r--r-- 1 root wheel 108880 Oct 25 16:57 libgcc2.i > -rw-r--r-- 1 root wheel 7636 Oct 25 16:57 _muldi3.dep > -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _ucmpdi2.o > -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _cmpdi2.o > -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _negdi2.o > -rw-r--r-- 1 root wheel 560 Oct 25 10:16 _muldi3.o > -rw-r--r-- 1 root wheel 1784 Oct 25 10:16 _dvmd_lnx_s.o >=20 > Unfortunately direct execution of the reported cc1 command on the = libgcc2.i in question does not fail. >=20 > Attempting to run the xgcc command under truss got a segmentation = fault in truss itself: >=20 > = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # truss -faeH -o truss.log = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC -W = -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem = ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork > /usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS > Segmentation fault (core dumped) >=20 > [There is a separate buzilla report about this truss failure.] >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Wed Oct 26 22:49:54 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61A5EC23DA2 for ; Wed, 26 Oct 2016 22:49:54 +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 5546E3F3; Wed, 26 Oct 2016 22:49:54 +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 412F7292; Wed, 26 Oct 2016 22:49:54 +0000 (UTC) Date: Wed, 26 Oct 2016 22:49:53 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1546703934.60.1477522193861.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_stable_10 #444 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_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 22:49:54 -0000 https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/444/ From owner-freebsd-stable@freebsd.org Thu Oct 27 10:01:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C520C23DB3 for ; Thu, 27 Oct 2016 10:01:36 +0000 (UTC) (envelope-from emz@norma.perm.ru) 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 46CAABF5 for ; Thu, 27 Oct 2016 10:01:36 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 4629AC23DB2; Thu, 27 Oct 2016 10:01:36 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45C4FC23DB1 for ; Thu, 27 Oct 2016 10:01:36 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A4DF8BF3 for ; Thu, 27 Oct 2016 10:01:35 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. ([IPv6:fd00::73d]) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id u9RA1ULR039587 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 27 Oct 2016 15:01:31 +0500 (YEKT) (envelope-from emz@norma.perm.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=norma.perm.ru; s=key; t=1477562491; bh=6t8YW41y1kXVVOyERt352rvISStzoXzyha6Gf1vuqXo=; h=To:From:Subject:Date; b=W0dmWyNlLF3sXdjr8X8FP0b5IuMqzSho06EsFfXHIAWcVUlz/EZLKJRU/bP11s4oX bJz6P/zNKl+sP4tcprllDaxGeoCrd3IvnJlGNgzzpRnnkNznt2oI62hKaxCwU/8KCf zfqlVLVCdLZiyIi8343Z/od7ywjYQQnsStaxV4ME= To: "stable@freebsd.org" From: "Eugene M. Zheganin" Subject: 11.0-RELEASE-p2: panic: vm_page_unwire: page 0x[...]'s wire count is zero Message-ID: <5811D07A.9050409@norma.perm.ru> Date: Thu, 27 Oct 2016 15:01:30 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 10:01:36 -0000 Hi, I've upgraded one of my old FreeBSD from 10-STABLE (which was leaking the wired memory and this was fixed in the spring; other than that it was pretty much stable) to the 11.0-RELEASE-p2, and almost immidiately got myself a panic: ===Cut=== # more core.txt.0 calypso.enaza.ru dumped core - see /var/crash/vmcore.0 Thu Oct 27 14:47:50 YEKT 2016 FreeBSD calypso.enaza.ru 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0 r307991: Thu Oct 27 13:41:31 YEKT 2016 emz@calypso.enaza.ru:/usr/obj/usr/src/sys/CALYPSO amd64 panic: vm_page_unwire: page 0xfffff8023ca8b2f8's wire count is zero GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: vm_page_unwire: page 0xfffff8023ca8b2f8's wire count is zero cpuid = 3 KDB: stack backtrace: #0 0xffffffff80b1b417 at kdb_backtrace+0x67 #1 0xffffffff80ad0782 at vpanic+0x182 #2 0xffffffff80ad05f3 at panic+0x43 #3 0xffffffff80e693b3 at vm_page_unwire+0x73 #4 0xffffffff80accb40 at sf_ext_free+0xb0 #5 0xffffffff80aa7ad0 at mb_free_ext+0xc0 #6 0xffffffff80aa81a8 at m_freem+0x38 #7 0xffffffff80cf7453 at tcp_do_segment+0x28a3 #8 0xffffffff80cf3edc at tcp_input+0xd1c #9 0xffffffff80c64c5f at ip_input+0x15f #10 0xffffffff80bfa135 at netisr_dispatch_src+0xa5 #11 0xffffffff80be2b9a at ether_demux+0x12a #12 0xffffffff80be37f2 at ether_nh_input+0x322 #13 0xffffffff80bfa135 at netisr_dispatch_src+0xa5 #14 0xffffffff80be2e16 at ether_input+0x26 #15 0xffffffff8055983c at igb_rxeof+0x81c #16 0xffffffff80558b92 at igb_msix_que+0x152 #17 0xffffffff80a8a7af at intr_event_execute_handlers+0x20f Uptime: 28m25s Dumping 3780 out of 8147 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/zfs.ko.debug...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. done. Loaded symbols for /boot/kernel/opensolaris.ko #0 doadump (textdump=) at pcpu.h:221 221 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:221 #1 0xffffffff80ad0209 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:366 #2 0xffffffff80ad07bb in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff80ad05f3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:690 #4 0xffffffff80e693b3 in vm_page_unwire (m=, queue=) at /usr/src/sys/vm/vm_page.c:3136 #5 0xffffffff80accb40 in sf_ext_free (arg1=0xfffff8023ca8b2f8, arg2=0x0) at /usr/src/sys/kern/kern_sendfile.c:140 #6 0xffffffff80aa7ad0 in mb_free_ext (m=0xfffff80022f27c00) at /usr/src/sys/kern/kern_mbuf.c:678 #7 0xffffffff80aa81a8 in m_freem (mb=) at mbuf.h:1180 #8 0xffffffff80cf7453 in tcp_do_segment (m=, th=, so=0xfffff80022ba6a20, tp=, drop_hdrlen=52, tlen=, iptos=, ti_locked=Cannot access memory at address 0x1 ) at /usr/src/sys/netinet/tcp_input.c:1764 #9 0xffffffff80cf3edc in tcp_input (mp=, offp=, proto=) at /usr/src/sys/netinet/tcp_input.c:1442 #10 0xffffffff80c64c5f in ip_input (m=Cannot access memory at address 0x0 ) at /usr/src/sys/netinet/ip_input.c:809 #11 0xffffffff80bfa135 in netisr_dispatch_src (proto=1, source=, m=0x0) at /usr/src/sys/net/netisr.c:1121 #12 0xffffffff80be2b9a in ether_demux (ifp=, m=0x0) at /usr/src/sys/net/if_ethersubr.c:850 #13 0xffffffff80be37f2 in ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:639 #14 0xffffffff80bfa135 in netisr_dispatch_src (proto=5, source=, m=0x0) at /usr/src/sys/net/netisr.c:1121 #15 0xffffffff80be2e16 in ether_input (ifp=, m=0x0) at /usr/src/sys/net/if_ethersubr.c:759 #16 0xffffffff8055983c in igb_rxeof (count=583080448) at /usr/src/sys/dev/e1000/if_igb.c:4957 #17 0xffffffff80558b92 in igb_msix_que (arg=0xfffff8000649b538) at /usr/src/sys/dev/e1000/if_igb.c:1612 #18 0xffffffff80a8a7af in intr_event_execute_handlers ( p=, ie=) at /usr/src/sys/kern/kern_intr.c:1262 #19 0xffffffff80a8aa16 in ithread_loop (arg=) at /usr/src/sys/kern/kern_intr.c:1275 #20 0xffffffff80a873f5 in fork_exit ( callout=0xffffffff80a8a950 , arg=0xfffff80006497900, frame=0xfffffe01f0b1cc00) at /usr/src/sys/kern/kern_fork.c:1038 #21 0xffffffff80fc112e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #22 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) ===Cut=== Has anyone seen this, and what are my actions ? I've google a bit, saw some references mentioning FreeBSD 9.x and ZERO_COPY_SOCKETS, but I don't have neither, so now I'm trying to understand what will my actions be.... do I report this ? Thanks. Eugene. From owner-freebsd-stable@freebsd.org Thu Oct 27 10:21:21 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11881C23472 for ; Thu, 27 Oct 2016 10:21:21 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id E74BB7EE for ; Thu, 27 Oct 2016 10:21:20 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: by mailman.ysv.freebsd.org (Postfix) id E6AB8C23471; Thu, 27 Oct 2016 10:21:20 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E64C9C23470 for ; Thu, 27 Oct 2016 10:21:20 +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 A1CD07ED for ; Thu, 27 Oct 2016 10:21:19 +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:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dztJ50H98YdgS9CdVJZkZtX1oPQnUgxs2PcYOncBQGI=; b=uUirZMFfFITcCo1U7PrWX84q1p Ahn6W8JKp7JM251tlaIST5ny1M5yl9QVXK5R1Ab+aBS6sSDKTxoy1rS1bppkoBIFX+C8zLm8kXeLs fmJfwa0rzBi8aDPIhwp5WCl58GGanYSh4k+jhhwvCngyPf7FvTCMKtHYNHUjFgtFB2JI=; Received: from [37.229.193.176] (helo=nonamehost) by frv157.fwdcdn.com with esmtpsa ID 1bzho4-000AOy-1P ; Thu, 27 Oct 2016 13:21:08 +0300 Date: Thu, 27 Oct 2016 13:21:07 +0300 From: Ivan Klymenko To: "Eugene M. Zheganin" Cc: "stable@freebsd.org" Subject: Re: 11.0-RELEASE-p2: panic: vm_page_unwire: page 0x[...]'s wire count is zero Message-ID: <20161027132107.16b363ed@nonamehost> In-Reply-To: <5811D07A.9050409@norma.perm.ru> References: <5811D07A.9050409@norma.perm.ru> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC 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-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 10:21:21 -0000 On Thu, 27 Oct 2016 15:01:30 +0500 "Eugene M. Zheganin" wrote: > Hi, > > I've upgraded one of my old FreeBSD from 10-STABLE (which was leaking > the wired memory and this was fixed in the spring; other than that it > was pretty much stable) to the 11.0-RELEASE-p2, and almost immidiately > got myself a panic: > > ===Cut=== > # more core.txt.0 > calypso.enaza.ru dumped core - see /var/crash/vmcore.0 > > Thu Oct 27 14:47:50 YEKT 2016 > > FreeBSD calypso.enaza.ru 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0 > r307991: Thu Oct 27 13:41:31 YEKT 2016 > emz@calypso.enaza.ru:/usr/obj/usr/src/sys/CALYPSO amd64 > > panic: vm_page_unwire: page 0xfffff8023ca8b2f8's wire count is zero > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are welcome to change it and/or distribute copies of it under > certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: vm_page_unwire: page 0xfffff8023ca8b2f8's wire count is zero > cpuid = 3 > KDB: stack backtrace: > #0 0xffffffff80b1b417 at kdb_backtrace+0x67 > #1 0xffffffff80ad0782 at vpanic+0x182 > #2 0xffffffff80ad05f3 at panic+0x43 > #3 0xffffffff80e693b3 at vm_page_unwire+0x73 > #4 0xffffffff80accb40 at sf_ext_free+0xb0 > #5 0xffffffff80aa7ad0 at mb_free_ext+0xc0 > #6 0xffffffff80aa81a8 at m_freem+0x38 > #7 0xffffffff80cf7453 at tcp_do_segment+0x28a3 > #8 0xffffffff80cf3edc at tcp_input+0xd1c > #9 0xffffffff80c64c5f at ip_input+0x15f > #10 0xffffffff80bfa135 at netisr_dispatch_src+0xa5 > #11 0xffffffff80be2b9a at ether_demux+0x12a > #12 0xffffffff80be37f2 at ether_nh_input+0x322 > #13 0xffffffff80bfa135 at netisr_dispatch_src+0xa5 > #14 0xffffffff80be2e16 at ether_input+0x26 > #15 0xffffffff8055983c at igb_rxeof+0x81c > #16 0xffffffff80558b92 at igb_msix_que+0x152 > #17 0xffffffff80a8a7af at intr_event_execute_handlers+0x20f > Uptime: 28m25s > Dumping 3780 out of 8147 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from > /usr/lib/debug//boot/kernel/zfs.ko.debug...done. > done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols > from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > #0 doadump (textdump=) at pcpu.h:221 > 221 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:221 > #1 0xffffffff80ad0209 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:366 > #2 0xffffffff80ad07bb in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:759 > #3 0xffffffff80ad05f3 in panic (fmt=0x0) > at /usr/src/sys/kern/kern_shutdown.c:690 > #4 0xffffffff80e693b3 in vm_page_unwire (m=, > queue=) at /usr/src/sys/vm/vm_page.c:3136 > #5 0xffffffff80accb40 in sf_ext_free (arg1=0xfffff8023ca8b2f8, > arg2=0x0) at /usr/src/sys/kern/kern_sendfile.c:140 > #6 0xffffffff80aa7ad0 in mb_free_ext (m=0xfffff80022f27c00) > at /usr/src/sys/kern/kern_mbuf.c:678 > #7 0xffffffff80aa81a8 in m_freem (mb=) at > mbuf.h:1180 #8 0xffffffff80cf7453 in tcp_do_segment (m= optimized out>, th=, so=0xfffff80022ba6a20, > tp=, drop_hdrlen=52, tlen= out>, iptos=, ti_locked=Cannot access memory at > address 0x1 > ) > at /usr/src/sys/netinet/tcp_input.c:1764 > #9 0xffffffff80cf3edc in tcp_input (mp=, > offp=, proto=) > at /usr/src/sys/netinet/tcp_input.c:1442 > #10 0xffffffff80c64c5f in ip_input (m=Cannot access memory at address > 0x0 ) at /usr/src/sys/netinet/ip_input.c:809 > #11 0xffffffff80bfa135 in netisr_dispatch_src (proto=1, > source=, m=0x0) > at /usr/src/sys/net/netisr.c:1121 #12 0xffffffff80be2b9a in > ether_demux (ifp=, m=0x0) > at /usr/src/sys/net/if_ethersubr.c:850 #13 0xffffffff80be37f2 in > ether_nh_input (m=) > at /usr/src/sys/net/if_ethersubr.c:639 #14 0xffffffff80bfa135 in > netisr_dispatch_src (proto=5, source=, m=0x0) > at /usr/src/sys/net/netisr.c:1121 #15 0xffffffff80be2e16 in > ether_input (ifp=, m=0x0) > at /usr/src/sys/net/if_ethersubr.c:759 #16 0xffffffff8055983c in > igb_rxeof (count=583080448) at /usr/src/sys/dev/e1000/if_igb.c:4957 > #17 0xffffffff80558b92 in igb_msix_que (arg=0xfffff8000649b538) > at /usr/src/sys/dev/e1000/if_igb.c:1612 > #18 0xffffffff80a8a7af in intr_event_execute_handlers ( > p=, ie=) > at /usr/src/sys/kern/kern_intr.c:1262 > #19 0xffffffff80a8aa16 in ithread_loop (arg=) > at /usr/src/sys/kern/kern_intr.c:1275 > #20 0xffffffff80a873f5 in fork_exit ( > callout=0xffffffff80a8a950 , arg=0xfffff80006497900, > frame=0xfffffe01f0b1cc00) at /usr/src/sys/kern/kern_fork.c:1038 > #21 0xffffffff80fc112e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:611 > #22 0x0000000000000000 in ?? () > Current language: auto; currently minimal > (kgdb) > ===Cut=== > > Has anyone seen this, and what are my actions ? I've google a bit, saw > some references mentioning FreeBSD 9.x and ZERO_COPY_SOCKETS, but I > don't have neither, so now I'm trying to understand what will my > actions be.... do I report this ? > > Thanks. > Eugene. > _______________________________________________ This is one of panic in my collection. http://docs.freebsd.org/cgi/mid.cgi?20161021220413.1d130f5c Thank you reported this problem to the community. From owner-freebsd-stable@freebsd.org Thu Oct 27 10:26:05 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 076EEC23740 for ; Thu, 27 Oct 2016 10:26:05 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F70BC10 for ; Thu, 27 Oct 2016 10:26:04 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. ([IPv6:fd00::73d]) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id u9RAQ0Ce041423 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 27 Oct 2016 15:26:00 +0500 (YEKT) (envelope-from emz@norma.perm.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=norma.perm.ru; s=key; t=1477563960; bh=OW89GfVs276emKD8PRFXzPZMbC/U8XFJBvJpNgKVBBk=; h=Subject:To:References:From:Date:In-Reply-To; b=hnHqDVZo/l01xy1lpryd4s5m0ONKpP9MLe8SEWAO7/sGpaqgPq8xaB9OqOnfO8Ha9 xGJv1ceZlEOr1NNVDXo+2q5zuuii8pn1+5Vx9q28veh2LcJtYfTl0j/+n84YVPuJeX xoEVRkIVnmQr5rCAPI9FcN8Yf0zzskapfWRvOwGA= Subject: Re: 11.0-RELEASE-p2: panic: vm_page_unwire: page 0x[...]'s wire count is zero To: freebsd-stable@freebsd.org References: <5811D07A.9050409@norma.perm.ru> From: "Eugene M. Zheganin" Message-ID: <5811D638.2060104@norma.perm.ru> Date: Thu, 27 Oct 2016 15:26:00 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <5811D07A.9050409@norma.perm.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 10:26:05 -0000 Hi. On 27.10.2016 15:01, Eugene M. Zheganin wrote: > Has anyone seen this, and what are my actions ? I've google a bit, saw > some references mentioning FreeBSD 9.x and ZERO_COPY_SOCKETS, but I > don't have neither, so now I'm trying to understand what will my actions > be.... do I report this ? > > And, unfortunately, it's repeatable: got another one just now. I guess I'll have to downgrade to 10-STABLE. Eugene. From owner-freebsd-stable@freebsd.org Thu Oct 27 10:49:48 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08185C2301B for ; Thu, 27 Oct 2016 10:49:48 +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 EB79668A; Thu, 27 Oct 2016 10:49:47 +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 0D3F62A5; Thu, 27 Oct 2016 10:49:47 +0000 (UTC) Date: Thu, 27 Oct 2016 10:49:45 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1726205264.61.1477565385889.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1546703934.60.1477522193861.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1546703934.60.1477522193861.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_stable_10 #445 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_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 10:49:48 -0000 https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/445/ From owner-freebsd-stable@freebsd.org Thu Oct 27 14:16:33 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2D58C23209; Thu, 27 Oct 2016 14:16:33 +0000 (UTC) (envelope-from tomek.cedro@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 7E2E48B0; Thu, 27 Oct 2016 14:16:33 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id b80so2919129wme.2; Thu, 27 Oct 2016 07:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=LXG2OZk7/Ia1L7p9+k3yTlw5bJGh+PucndZvzCp8LhE=; b=EkvlhgBMKNbcW78JE9kc9/C6dyVuVPXRRdRmMxA6rg40+6mejY+78iJLfV/Q+9U3Di WWFgbIS4bejba+Kq88FGnsrchxz5GgZm0fSsm0Lb5jm4IFwr48r9YEXMrN29gVnBO1HX vYPKq+yvlnSpbaK93YR0vRb5ZtkGL1IP2xmg78/npY6yjqfE4OodDxUKGv1qBdxCE9p5 tnBbKTRjbS1HFzcygZ1nHG2620zbydahIo/aiWJsA1kdk8q/9L2SUx4Z5oDXTqU5HkCa lpO9Ox2h1s6sk9T5kx7EG7gfViKLR2eKLZUOrMz0ihUPEg8WrzIQ9zEDizsQvrFrp/7w OkOQ== 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:from:date:message-id:subject :to; bh=LXG2OZk7/Ia1L7p9+k3yTlw5bJGh+PucndZvzCp8LhE=; b=IPkPdua6dpR2YO+0XZASPRDVoaYsmWFFJG+DbGEyErWlg5QkrW2vxDX/dmHePnFlhy yyw/6Ix9Hlx9yxxvaD3DoKAXbhIaQ4TEhztdtIQYrz4HSzUrqFqJuZi5GtTrnMvL5KjN nl0aen8i+RVeRLJbDhCqaShlMgMyzJVdeRQOHznbc+VkZ/IjZboIqiw6/Kfj9lHdXLDd KYAC8JMbDTZQCrjAaBJESIhE+pEE0ZaTs5pxIvjlwKXwuaX45joekgEJ6oZYR2r58QiX 36ylgNvCpFnKH6GseeckhUZaEwfZUM4tLHXZiPHBiA6qApGfTYW/DxR90NGwDCyR3ks+ jEjA== X-Gm-Message-State: ABUngvfCl6FbdxIMgI0xEuSX3BoVjn9/ePGAGz5E2+Ptw9/0CFFErpoHNzQSIHHhdjmNU7iTaAga40KwGf053w== X-Received: by 10.28.73.214 with SMTP id w205mr14430624wma.86.1477577791784; Thu, 27 Oct 2016 07:16:31 -0700 (PDT) MIME-Version: 1.0 Sender: tomek.cedro@gmail.com Received: by 10.28.178.132 with HTTP; Thu, 27 Oct 2016 07:16:11 -0700 (PDT) From: Tomasz CEDRO Date: Thu, 27 Oct 2016 16:16:11 +0200 X-Google-Sender-Auth: XJS2sdXeIjNw4LqPCYM3C6FUQbw Message-ID: Subject: PKG bootstrap problem on FreeBSD 11.0-RELEASE-p1 To: FreeBSD Questions Mailing List , FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 14:16:33 -0000 Hey, I have just installed 11.0-RELEASE-p1 r306420 and I cannot bootstrap the PKG :-( Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:11:amd64/quarterly, please wait... Error fetching. Both IP and DNS are working.. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@freebsd.org Thu Oct 27 14:34:02 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B1FDC2398B; Thu, 27 Oct 2016 14:34:02 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3235C850; Thu, 27 Oct 2016 14:34:02 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id e69so38794389wmg.0; Thu, 27 Oct 2016 07:34:02 -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=bb7tkpXlHBLytB1v3RzgOrDZkIk/0LDqydnPAiLB3XM=; b=nDU7LkTjS93yTi8FzRTKQ2PMmgf/r/kD7AZRMYVdhnyneBLAVwGOtxZqxd014+xD2T qJlMMkFFQnqwm8ypI16eOMbDbKwDP6gA9asOFBfGadBxf15h76jX8aPr3qjKXUekSdM7 zJjYBDw69rnnalfAv5ovmPFGL1NWSMswOH8NqMFtC8fALQ6cDSOdK4sg6Ob9AJIRsabf v/KC3YAZdmeSGGMYsbAklB9FNlCjPeVylR+Bq3DjC4frlqdzTQ1JURvkrybKGAdt6A8q cThAKiWfJybRvHN0xr3GYlNMcu/AKz1nWOEtOoifPJH/udJHkqrJ/tzXlxNW5tZZFT4f gCkQ== 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=bb7tkpXlHBLytB1v3RzgOrDZkIk/0LDqydnPAiLB3XM=; b=iNoZHNVQPO8j/y1onVUky5jrnfLbO9pw4g97PnZ/1+WdfMVrOpisQQeau3ZczD31Cx Zqzy1lRzHP7iZZlwIZLshaw3HXYZDxm/mMMRIvOME606Wh5Ybscbpx5vGoQX/KkU6/pN LtueS0F+HEYWgFvx8wsaq4z3JVaMeqVkC5GLeliA6bJnRX1+rckQqtyA17ffzb7FlGMZ k9qEe003/B/cz+wx/ScMH7mhDh2SaJHf+mqf9dLr3SjglpDyxDTDtpdpR+5OwfsqRWu+ TBCfa7ggGggRpyLSCImzIx484JWni40ayCoUnmVnB8zAoqzpXFM6T8jhnwnqx020Mzru 3PGA== X-Gm-Message-State: ABUngvdAqGB5MCX/nLRoCdF5lBJDuS5M965bbBkQfl8K+Ka33KujKUYHd8pbLN7szq5dO4sNRqgsu6GK9Ii2ig== X-Received: by 10.28.141.148 with SMTP id p142mr13244295wmd.107.1477578840235; Thu, 27 Oct 2016 07:34:00 -0700 (PDT) MIME-Version: 1.0 Sender: tomek.cedro@gmail.com Received: by 10.28.178.132 with HTTP; Thu, 27 Oct 2016 07:33:39 -0700 (PDT) In-Reply-To: References: From: Tomasz CEDRO Date: Thu, 27 Oct 2016 16:33:39 +0200 X-Google-Sender-Auth: dr_YGqtYIWGlygnfK16r3BecIeg Message-ID: Subject: Re: PKG bootstrap problem on FreeBSD 11.0-RELEASE-p1 To: FreeBSD Questions Mailing List , FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 14:34:02 -0000 After make install from ports-mgmt/pkg update and install works fine. Clearly problem with bootstrap only. Is this a bug or feature? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@freebsd.org Thu Oct 27 14:36:34 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E7CAC23C5C; Thu, 27 Oct 2016 14:36:34 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 C7596C27; Thu, 27 Oct 2016 14:36:33 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id b75so33244998lfg.3; Thu, 27 Oct 2016 07:36:33 -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=psVxDgevP8uEoRy67ug6ESZF8ZHjhevh/zB/vt7/Z5s=; b=AgBj0pqsbH3HJxwexatwcJjITlxMcY0pf81v+Z3U8aEm7U07t287r9hoQHwIm1BarH LIKrYvT6Pa+XN6tRNdcuAPLRtMvpgQUTRrJ4TwxsOl/3tTmcu0KuV2SiOVl7ObUVEZL+ KdD/cxfzl0RaC0jgyeOPYsPUf8jXVJ+kl5fZLhjBQn6HoX7yuKGqQ5nAE6Hi2wVtSvgY oNm5umvLm3E/56BVF2JV/tLlvMiMd2Ou+g2ukatO0oaFXxDVxUQJglLKxToDPpwh5baA s8H+SNeNkEqCobRwlJmt8nSZEH+MOhXzuEwo57Z0zfza0Ypnl+1nupc+aGnUNzhjWcLK pXDw== 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=psVxDgevP8uEoRy67ug6ESZF8ZHjhevh/zB/vt7/Z5s=; b=VAodBqp7NGl+wYgZM5cOe9rFh8AiT3RX2T3Ch5CT6mNJyMLmsB3s/DczjeGLSUgLMY mqTCDYcHSm0kQC27i+d3V2VXWyQz1kMRYL/OaIUXg4VC2tLT+gXDbx0/PHc2/7it+O1x JZlmyiTBRMClY5ra3nekgYkHgUJmOODP8OWxM28u346I/LIv0+ldSltpEn4TQFbZ99Da ED/zKF/2AycV3XO/PfqmLbNYRoi/K4lVTqGR6yahnxYrvIMAogjdRb5rtxaXgFXsDbl0 lYTWaYFk0CE1KExXzu9lDswTfzkU+J6fWGUnJS3+ziszab+waf2x9xIGPJU7VSIcu4UP F33A== X-Gm-Message-State: ABUngvfKHkEuJUhhezcc5wuTClBH9P22hmTLHAxMP5Wm4EO+pkBhF2pPPRzRBMfM5viMGDB5T2r49mQVVvDC2w== X-Received: by 10.194.24.34 with SMTP id r2mr7061771wjf.111.1477578991707; Thu, 27 Oct 2016 07:36:31 -0700 (PDT) MIME-Version: 1.0 Sender: tomek.cedro@gmail.com Received: by 10.28.178.132 with HTTP; Thu, 27 Oct 2016 07:36:10 -0700 (PDT) In-Reply-To: References: From: Tomasz CEDRO Date: Thu, 27 Oct 2016 16:36:10 +0200 X-Google-Sender-Auth: 7Vf0qXOaHUP3775M3qCWE7qoHgU Message-ID: Subject: Re: PKG bootstrap problem on FreeBSD 11.0-RELEASE-p1 To: FreeBSD Questions Mailing List , FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 14:36:34 -0000 On Thu, Oct 27, 2016 at 4:33 PM, Tomasz CEDRO wrote: > After make install from ports-mgmt/pkg update and install works fine. > Clearly problem with bootstrap only. Sorry! INSTALL DOES NOT WORK TOO. "Connection reset by peer". Server problem then..? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@freebsd.org Thu Oct 27 15:08:46 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64F3EC24595; Thu, 27 Oct 2016 15:08:46 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 0D91CE4A; Thu, 27 Oct 2016 15:08:46 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id n67so50194584wme.1; Thu, 27 Oct 2016 08:08:45 -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=G1k+BYvaidp4bP2MsXdCjMGWydKSwl3OD+rubF6aZdo=; b=f8bnvSYpje+aWv5WrjJDPWjo3UdpgdGIi8F2NYwStgCWrehhamoZ0khVpe7TgR8R3L 1iWP+y4x+IeyzI3gYKJ5D2LT8XK4yAoOHngBGE8CK3ZNcU6ARxiZ3r8+Zg9h+T1ADnSk vEt4MobEtRq7yNRZEW4JBfSDsUiQVPlj5LpBaNoA1CWX1+RNxzbHOdKlfTfaty0DURDc 7TGxwXnMvHsFzMSVJKo22IBqKzzpNJdNq1gZ/L9YjkqUeqPsppy5J7v3qA5SX9ze4fxs sfFEqeTTDi0jlVwRFXD7dqBT+OoaTbc0buRU1ujGNK6XbbUSeOwCRcsmcewqEFFCYyFX CBKQ== 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=G1k+BYvaidp4bP2MsXdCjMGWydKSwl3OD+rubF6aZdo=; b=j9BQ5jcq5AufAMapAxTzbsnYSpXN+UcqgP56Wuxu45+p4w2sJGprnuzZefCxNNYdPx iFmTNBk12z3sTZN44+hwoJI/AnI8gt592PEqasgcfbHHvJ32O9NN7KvacRhvyzDjuplC xhKtvW+MzFQ5gc+XUB2jblK7K6jzoLBpWdKU5Qtt61QKl0U/OsgTV/lJ4gMwtn5BXczs mVGqge1a6SjFrpNdLf2oJUjBlmU9flcdBuOI22Kci9BQknq+7C2NowQyNy89ierdwZ6M MNm8FmGLzlM3uJTHdr3int6jbLaAhrgoCKbmC91Zgumz4PK+4OAEWwjIV3nprGsljlJN azAQ== X-Gm-Message-State: ABUngvcD2rsdJ8de0zUMEwlYG/n7UJC6S3olerTxwMBpp4E2YPFpXzAK3VP95Me/r5H+ztSAG9MiiLfTFspWsQ== X-Received: by 10.194.24.34 with SMTP id r2mr7186471wjf.111.1477580924299; Thu, 27 Oct 2016 08:08:44 -0700 (PDT) MIME-Version: 1.0 Sender: tomek.cedro@gmail.com Received: by 10.28.178.132 with HTTP; Thu, 27 Oct 2016 08:08:23 -0700 (PDT) In-Reply-To: References: From: Tomasz CEDRO Date: Thu, 27 Oct 2016 17:08:23 +0200 X-Google-Sender-Auth: 1YNgk5Qj5uTtPZ4w9mqoRo_rEIU Message-ID: Subject: Re: PKG bootstrap problem on FreeBSD 11.0-RELEASE-p1 To: FreeBSD Questions Mailing List , FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 15:08:46 -0000 Ugh, I am in a new place, some filtering on the wire it looks, no problem after VPN to a different location. FALSE ALERT SORRY! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@freebsd.org Thu Oct 27 18:06:01 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66E14C24243 for ; Thu, 27 Oct 2016 18:06:01 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 08CBE6A2 for ; Thu, 27 Oct 2016 18:06:00 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id u9RI5vxf089111 for ; Thu, 27 Oct 2016 20:05:57 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 73D30810; Thu, 27 Oct 2016 20:05:57 +0200 (CEST) Message-ID: <58124200.5080306@omnilan.de> Date: Thu, 27 Oct 2016 20:05:52 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Unexpected ahci-hd bytes when running in bhyve(8) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 27 Oct 2016 20:05:57 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 18:06:01 -0000 Hello, I wanted to use a "roaming" ssd with byhve/vmm, which is the home of a GPT based FreeBSD setup. I've been using this for years with ESXi and bare-metal-hosts, and wanted to try out bhyve. Unfortunately this doesn't work the way I'm used to. Booting of ufs:/dev/gpt/myROOT fails with error 19, loader does only see a diskid/BHYVEDISK, not the GPT partitions. I guess ahci-hd isn't 1:1 mapping blocks, neither does virtio-blk, since it shows exactly the same result, which is a bit strange to me: When I boot a Live-CD in vmm with the physical SSD ahci-hd attached, the first 8kByte of /dev/ada0 is 0x0. The same test on the host ('dd if=/dev/ada4 count=16 | hd') shows me PMBR and GPT content, which I also expected to see in bhyve… What am I missing? Here's my switches: bhyve -u -A -H -P \ -S \ -s 0,hostbridge \ -s 6,passthru,6/0/0 \ -s 31,lpc \ -s 1,ahci-cd,releases/ISO-IMAGES/11.0/FreeBSD-11.0-RELEASE-amd64-disc1.iso \ -s 7,ahci-hd,/dev/ada4 \ -l com1,/dev/nmdm0A \ -m 3G -c 4 preed /dev/ada4 is the "roaming" (hotpuggable) SSD on the host. Thanks for any hint, -harry From owner-freebsd-stable@freebsd.org Fri Oct 28 06:13:43 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCCE7C2477E; Fri, 28 Oct 2016 06:13:43 +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 8A3C7AD2; Fri, 28 Oct 2016 06:13:43 +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:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=hd350epCUzOtc1vmnliJ4s+rPf9f4pSABLxIhTv9FdE=; b=F5nlg9UfURJKE2jlDOwMGWnQid GxwpD/xzE2UII2lzl5udO9S3dLchHDuBp6jUFUboIlB4QOFK5S84XuOoX01e3Y7y5z7ALg5XlOFED ZzkUqf5K4aqBdGb6sjtWbRTFg4OX306LTjqIEacM0+IBE90h4F2ygOttS8nCj4nBGRtc=; Received: from [37.229.193.176] (helo=nonamehost) by frv157.fwdcdn.com with esmtpsa ID 1c00Q7-000ES1-V3 ; Fri, 28 Oct 2016 09:13:40 +0300 Date: Fri, 28 Oct 2016 09:13:39 +0300 From: Ivan Klymenko To: freebsd-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE Message-ID: <20161028091339.0d4b8ffd@nonamehost> In-Reply-To: <20161021220413.1d130f5c@nonamehost> References: <20161021220413.1d130f5c@nonamehost> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC 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-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 06:13:43 -0000 Next panic Oct 28 09:06:50 ns kernel: panic: sbsndptr: sockbuf 0xfffff8008f186878 and mbuf 0xfffff8008f29d200 clashing Oct 28 09:06:50 ns kernel: cpuid = 7 Oct 28 09:06:50 ns kernel: KDB: stack backtrace: Oct 28 09:06:50 ns kernel: #0 0xffffffff80b5f0e7 at kdb_backtrace+0x67 Oct 28 09:06:50 ns kernel: #1 0xffffffff80b129c2 at vpanic+0x182 Oct 28 09:06:50 ns kernel: #2 0xffffffff80b12833 at panic+0x43 Oct 28 09:06:50 ns kernel: #3 0xffffffff80bafc4a at sbsndptr+0xda Oct 28 09:06:50 ns kernel: #4 0xffffffff80d57b88 at tcp_output+0x1168 Oct 28 09:06:50 ns kernel: #5 0xffffffff80d540f6 at tcp_do_segment+0x30d6 Oct 28 09:06:50 ns kernel: #6 0xffffffff80d508b6 at tcp_input+0x14a6 Oct 28 09:06:50 ns kernel: #7 0xffffffff80cb54be at ip_input+0x18e Oct 28 09:06:50 ns kernel: #8 0xffffffff80c49add at netisr_dispatch_src+0xad Oct 28 09:06:50 ns kernel: #9 0xffffffff80c3815e at tunwrite+0x2ee Oct 28 09:06:50 ns kernel: #10 0xffffffff809b54e7 at devfs_write_f+0xe7 Oct 28 09:06:50 ns kernel: #11 0xffffffff80b7e227 at dofilewrite+0x87 Oct 28 09:06:50 ns kernel: #12 0xffffffff80b7ddf9 at sys_write+0xd9 Oct 28 09:06:50 ns kernel: #13 0xffffffff8105ac2e at amd64_syscall+0x51e Oct 28 09:06:50 ns kernel: #14 0xffffffff8103bbcb at Xfast_syscall+0xfb Oct 28 09:06:50 ns kernel: Uptime: 21h57m23s Oct 28 09:06:50 ns kernel: Dumping 7609 out of 32688 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% uname -a FreeBSD ns 11.0-STABLE FreeBSD 11.0-STABLE #7 r307744: Fri Oct 21 21:07:37 EEST 2016 root@ns:/usr/obj/usr/src/sys/bzk11 amd64 All kernels Build with VIMAGE. From owner-freebsd-stable@freebsd.org Fri Oct 28 12:15:29 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACA42C21584; Fri, 28 Oct 2016 12:15:29 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 45E78B79; Fri, 28 Oct 2016 12:15:29 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id 68so404239wmz.2; Fri, 28 Oct 2016 05:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=sS3tTf2vBhY0TjTNpO7DtXKiCSo4Hn7KRdYS3GIOZTc=; b=TQbi5LOLnzAfdhLbLYGvd2VFiwiJfogcHyeNzd4WY63uYVJnb4YzPe2WdwwIbNMGae 3NNayAtlhZq7S+w0rvg5gaJ4oXkYrkM7kXDNwPi5Bv6HI3o/0Wcgil4LyxL+Ei7JPvCM XXwAKLx1UrY9HA6g+/l6d/YJLerOe3t8tZqc5AN6btUMRXsx/KWAgt6zu2MWg07C/GxO id/xVqJqpE/SmRvIciYn6DFjRKYFhc5owHvCIjz5r8DG2rsvd5NctpxNPcmXSeoXakRB SIOS8RH89hcBthak1fXwj9uG9un3lawl54NxapTgrx1zWKqgx8HR51OOSCD8/QIQfs0A DV2g== 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:from:date:message-id:subject :to; bh=sS3tTf2vBhY0TjTNpO7DtXKiCSo4Hn7KRdYS3GIOZTc=; b=DB+LpIkp9G5dGtnTM+Q5puQ8E/PT4uPoBsV51nnN2bJP2IzajCYNYxM76EiEmO3jz3 UWcqsOGu6bHfyGmNhC62IuBwa2ooNvHfBUYcKBGZ+VtZ6yFeKr/kEDN8c0cQYuh9fnkh zqjW/spvbpZkLCUrRUtTp71YpUSvwSDWiKnvRs9//N7U6k1NH31mOuCbzsV1NKx9An1+ l38KL4FqcBXlPEVMkqjsb9NRvVIZo91Up/9XvenqwLm044MyjDu0Mlnkvm2HZY/YPNbJ t3IIVSNYp+pZKPotlVsg6rvPCLwGdK2NeurUiGDxPbWtmPEQ3Rnt86T5u5XhKV3z/uka EqkA== X-Gm-Message-State: ABUngvcyfpJ63UcGItDOeNzGNcG+tJqdj/9Gr77sKccXaVZIUtor2mcwcs2Pb59/xrzylC82E/ia5OmA42GMvA== X-Received: by 10.194.19.130 with SMTP id f2mr12930340wje.107.1477656927108; Fri, 28 Oct 2016 05:15:27 -0700 (PDT) MIME-Version: 1.0 Sender: tomek.cedro@gmail.com Received: by 10.28.178.132 with HTTP; Fri, 28 Oct 2016 05:15:06 -0700 (PDT) From: Tomasz CEDRO Date: Fri, 28 Oct 2016 14:15:06 +0200 X-Google-Sender-Auth: xvyFl1O970YXLkJ250clwqatotM Message-ID: Subject: Re: PKG bootstrap FreeBSD 11.0 / VBox NAT problem To: FreeBSD Questions Mailing List , FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 12:15:29 -0000 Just for the curious. I am testing on VirtualBox (Version 5.1.8 r111374 (Qt5.5.1), macOS 10.12.1 host). Cannot bootstrap PKG on a host with NAT enabled.I have noticed this problem occurs only when NAT is enabled in VBox. When I use Bridged interface there is no problem. I have noticed that outgoing packet following RST response has invalid checksum. That may be VBox NAT problem..? Maybe someone noticed similar behavior.. https://www.virtualbox.org/ticket/16126 -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@freebsd.org Fri Oct 28 12:17:54 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3D5BC217C3 for ; Fri, 28 Oct 2016 12:17:54 +0000 (UTC) (envelope-from rjk@wintek.com) Received: from local.wintek.com (local.wintek.com [72.12.201.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.wintek.com", Issuer "RapidSSL SHA256 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C277EEE for ; Fri, 28 Oct 2016 12:17:54 +0000 (UTC) (envelope-from rjk@wintek.com) Received: from rjk.wintek.local (172.28.1.248) by EX-2012.wintek.local (172.28.1.134) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 28 Oct 2016 08:03:34 -0400 To: "freebsd-stable@freebsd.org" From: Richard Kuhns Subject: Problem installing 11-stable on a Dell 5510, UEFI boot Message-ID: <04760707-874e-e47f-0581-8b69b767f67e@wintek.com> Date: Fri, 28 Oct 2016 08:02:40 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: EX-2012.wintek.local (172.28.1.134) To EX-2012.wintek.local (172.28.1.134) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 12:17:54 -0000 Hello, I have a nice new Dell Precision 5510 laptop that I ordered preloaded with Ubuntu 14.10, and I'd *really* like to have FreeBSD on it instead. I've put the memstick image on a 2GB USB stick per the instructions on freebsd.org, but when I bring up the boot menu on the 5510 the USB drive isn't offered as a boot device. I've disabled Secure Boot & I made sure that the 5510 is allowed to boot from a USB device. I then decided to build my own image, following the instructions on the wiki: gpart create -s gpt da0 gpart add -t efi -s 800K da0 gpart add -t freebsd-ufs da0 dd if=/boot/boot1.efifat of=/dev/da0p1 newfs -U -L FreeBSD /dev/da0p2 Followed by: mount /dev/da0p2 /mnt make DESTDIR=/mnt installkernel installworld distribution echo "/dev/da0p2 / ufs rw 1 1" >> /mnt/etc/fstab umount /mnt It took a while to install and apparently worked fine, with no errors, but it still didn't show up in the boot menu. I had created an Ubuntu recovery image when I first fired up the 5510 and wrote it to a USB drive, and it shows up in the boot menu. Just for fun I downloaded a Linux Mint 18 XFCE installation ISO that I copied to the USB drive using the same method I used for the FreeBSD memstick image. It shows up on the boot menu & I verified that I can boot it. I'll run Mint with XFCE if I have to, but I'd really prefer FreeBSD. Can anyone offer suggestions as to what I should try next? Thanks! -- Richard Kuhns Wintek Corporation 427 N 6th Street Lafayette, IN 47901-2211 Main: 765-742-8428 Direct: 765-269-8541 From owner-freebsd-stable@freebsd.org Fri Oct 28 12:45:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06B6FC22217; Fri, 28 Oct 2016 12:45:36 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (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 BB9E5371; Fri, 28 Oct 2016 12:45:35 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3t53Q42gNqzbCv; Fri, 28 Oct 2016 14:45:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=mail; t= 1477658730; x=1479473131; bh=V198c3l287EwMI1oLSU3L4WUaMzkry8k52a gXu5Nbm0=; b=GjCnsG5mAkwkWFJYuJKtVVtPDY3oigi6nOw1weXBPPVyF7FVOQp fy+wsKHtASniPBAG1Ec1427PBatRchk7O/ndfFAGqcoaCGy2+V7ds1mwgCdUbwkK sSBVvtqyTmSZoPTZyWoWoGmN9IA13RoJJ/i5mbpxWMhAvSLDHxHiDM/M= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id DrOGq-wMZHPK; Fri, 28 Oct 2016 14:45:30 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Fri, 28 Oct 2016 14:45:30 +0200 (CEST) Subject: Re: PKG bootstrap FreeBSD 11.0 / VBox NAT problem To: Tomasz CEDRO , FreeBSD Questions Mailing List , FreeBSD Stable References: From: Guido Falsi Message-ID: <24bbacd2-09a0-7a0e-61e6-db7a670fc6ca@madpilot.net> Date: Fri, 28 Oct 2016 14:45:29 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 12:45:36 -0000 On 10/28/16 14:15, Tomasz CEDRO wrote: > Just for the curious. I am testing on VirtualBox (Version 5.1.8 > r111374 (Qt5.5.1), macOS 10.12.1 host). Cannot bootstrap PKG on a host > with NAT enabled.I have noticed this problem occurs only when NAT is > enabled in VBox. When I use Bridged interface there is no problem. I > have noticed that outgoing packet following RST response has invalid > checksum. That may be VBox NAT problem..? Maybe someone noticed > similar behavior.. > > https://www.virtualbox.org/ticket/16126 > It could be related or unrelated, but have you tested disabling checksum offloading on both the guest and the host NICs? BTW what NIC are you using in the guest machine? have you tried changing NIC type? (for example changing between the emulated one and the paravirtualized one) -- Guido Falsi From owner-freebsd-stable@freebsd.org Fri Oct 28 13:13:39 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D29E4C24277 for ; Fri, 28 Oct 2016 13:13:39 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFCC9D9 for ; Fri, 28 Oct 2016 13:13:38 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.14.9) with ESMTPS id u9SDD4ab076704 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 28 Oct 2016 15:13:05 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.14.9/Submit) with UUCP id u9SDD4pv076703 for freebsd-stable@FreeBSD.ORG; Fri, 28 Oct 2016 15:13:04 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id u9SCaIta033150 for ; Fri, 28 Oct 2016 14:36:18 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id u9SCY3Ka032880 for ; Fri, 28 Oct 2016 14:34:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id u9SCY3W4032878 for freebsd-stable@FreeBSD.ORG; Fri, 28 Oct 2016 14:34:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: Dying jail Date: Fri, 28 Oct 2016 14:28:27 +0200 Organization: even some more stinky socks Message-ID: References: <581064BB.1030500@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 28 Oct 2016 12:28:35 +0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="31114"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 In-Reply-To: <581064BB.1030500@rdtc.ru> Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (uucp.dinoex.sub.de [194.45.71.2]); Fri, 28 Oct 2016 15:13:05 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 13:13:39 -0000 Eugene Grosbein wrote: > Hi! > > Recently I've upgraded one of my server running 9.3-STABLE with jail containing 4.11-STABLE system. > The host was source-upgraded upto 10.3-STABLE first and next to 11.0-STABLE > and jail configuration migrated to /etc/jail.conf. The jail kept intact. > > "service jail start" started the jail successfully > but "service jail restart" fails due to jail being stuck in "dying" state for long time: > "jls" shows no running jails and "jls -d" shows the dying jail. Same issue here. During upgrade to 10 I wrote a proper jail.conf, and, as this is now a much more transparent handling, I also began to start+stop my jails individually w/o reboot. I found the same issue: often jails do not want to fully terminate, but stay in the "dying" state - sometimes for a minute or so, but sometimes very long (indefinite). It seems this is not related to remaining processes or open files (there are none) but to network connections/sockets which are still present. Probably these connections can be displayed with netstat, and probably netstat -x shows some decreasing counters associated with them - I have not yet found the opportunity to figure out what they exactly mean, but anyway it seems like there may be long times involved (hours? forever?), unless one finds the proper connection and terminates both ends. There seems to be no other way to deliberately "kill" such connections and thereby terminate the jail, so the proposal to let it have a new number might be the only feasible approach. (I dont like it, I got used to the numbers of my jails.) From owner-freebsd-stable@freebsd.org Fri Oct 28 13:14:03 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A2BEC242CC; Fri, 28 Oct 2016 13:14:03 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 6AC1CA8E; Fri, 28 Oct 2016 13:14:02 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ijs.si (Postfix) with ESMTPS id 3t542v1l7SzsM; Fri, 28 Oct 2016 15:13:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1477660435; x=1480252436; bh=CNs 3e2Lz88noqmLwIuVgjhMBB5dRRgUPhqorSS/PrNI=; b=gnxLkmaLEhaKnFAeM5Z NzQZUQZy2FxTUb2egZnZhgEA3DCkIUDUc/I2qQm4kGDacil14tnmCJeJpaOGvmzA sStxvJHnx8K+He3qv6iBLY6bvNiVVKRTA7HCuSsVkt76Dv1P3Ajs0IVIfDdW5Gxr WRA0aL6IUSMK2DqVhJ1wA5+M= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id Rvcu9cgQSJrf; Fri, 28 Oct 2016 15:13:55 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3t542q4DB9zsL; Fri, 28 Oct 2016 15:13:55 +0200 (CEST) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3t542q25G3z4X; Fri, 28 Oct 2016 15:13:55 +0200 (CEST) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by webmail.ijs.si with HTTP (HTTP/1.1 POST); Fri, 28 Oct 2016 15:13:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 28 Oct 2016 15:13:55 +0200 From: Mark Martinec To: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: PKG bootstrap FreeBSD 11.0 / VBox NAT problem Organization: Jozef Stefan Institute In-Reply-To: <24bbacd2-09a0-7a0e-61e6-db7a670fc6ca@madpilot.net> References: <24bbacd2-09a0-7a0e-61e6-db7a670fc6ca@madpilot.net> Message-ID: <4c9bc1ff028540f4c8c9122f786aef61@ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 13:14:03 -0000 On 10/28/16 14:15, Tomasz CEDRO wrote: > Just for the curious. I am testing on VirtualBox (Version 5.1.8 > r111374 (Qt5.5.1), macOS 10.12.1 host). Cannot bootstrap PKG on a host > with NAT enabled.I have noticed this problem occurs only when NAT is > enabled in VBox. When I use Bridged interface there is no problem. I > have noticed that outgoing packet following RST response has invalid > checksum. That may be VBox NAT problem..? Maybe someone noticed > similar behavior.. > > https://www.virtualbox.org/ticket/16126 Same thing here: after upgrading VirtualBox on Windows 10 to 5.0.28, the 'pkg upgrade' on a FreeBSD 11.0-RELEASE-p2 guest fails with a 'Connection reset by peer' - either right away, or after downloading a (random) couple of packages - when using NAT provided by VirtualBox. This worked well with a previous release of VirtualBox. Looks like the problem is not specific to FreeBSD: https://www.virtualbox.org/ticket/16084 Mark From owner-freebsd-stable@freebsd.org Fri Oct 28 13:19:05 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 521ABC2465F; Fri, 28 Oct 2016 13:19:05 +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 C004EECC; Fri, 28 Oct 2016 13:19:04 +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 u9SDIuXh078735 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Oct 2016 15:18:56 +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 u9SDItDt078732; Fri, 28 Oct 2016 15:18:56 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Fri, 28 Oct 2016 15:18:55 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Tomasz CEDRO cc: FreeBSD Questions Mailing List , FreeBSD Stable Subject: Re: PKG bootstrap FreeBSD 11.0 / VBox NAT problem In-Reply-To: Message-ID: References: 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=-2.0 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.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 13:19:05 -0000 On Fri, 28 Oct 2016 14:15+0200, Tomasz CEDRO wrote: > Just for the curious. I am testing on VirtualBox (Version 5.1.8 > r111374 (Qt5.5.1), macOS 10.12.1 host). Cannot bootstrap PKG on a host > with NAT enabled.I have noticed this problem occurs only when NAT is > enabled in VBox. When I use Bridged interface there is no problem. I > have noticed that outgoing packet following RST response has invalid > checksum. That may be VBox NAT problem..? Maybe someone noticed > similar behavior.. > > https://www.virtualbox.org/ticket/16126 Upgrading VBox (the hypervisor software) to 5.1.8 last week made "make -C /usr/ports fetchindex" next to impossible on my FreeBSD guests. I was running 5.1.6 of emulators/virtualbox-ose-additions{,-nox11} at that time. Luckily, I was able to upgrade the latter to 5.1.8 and all network/NAT problems went away. -- +-------------------------------+------------------------------------+ | 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-stable@freebsd.org Fri Oct 28 15:15:14 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7CE1C248C0; Fri, 28 Oct 2016 15:15:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (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 BE16930B; Fri, 28 Oct 2016 15:15:14 +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 mail.baldwin.cx (Postfix) with ESMTPSA id 9C1CD10AF8A; Fri, 28 Oct 2016 11:15:13 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Mark Millard , freebsd-arm , FreeBSD-STABLE Mailing List , FreeBSD Toolchain Subject: Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call Date: Fri, 28 Oct 2016 07:29:52 -0700 Message-ID: <2661167.K5IN9JAPmQ@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> References: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> 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.4.3 (mail.baldwin.cx); Fri, 28 Oct 2016 11:15:13 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 15:15:15 -0000 On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote: > [The following has been reported in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .] > > In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying to track things down I ran into truss getting a SIGSEGV when it tries to handle the situation. . . > > In truss's enter_syscall there is (from a live gdb on truss, after the segmentation fault): > > 380 t->cs.name = sysdecode_syscallname(t->proc->abi->abi, t->cs.number); > 381 if (t->cs.name == NULL) > (gdb) > 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --\n", > 383 t->proc->abi->type, t->cs.number); > 384 > 385 sc = get_syscall(t->cs.name, narg); > 386 t->cs.nargs = sc->nargs; > 387 assert(sc->nargs <= nitems(t->cs.s_args)); > 388 > 389 t->cs.sc = sc; > > (gdb) print *t > $2 = {entries = {le_next = 0x0, le_prev = 0x20617070}, proc = 0x20617060, tid = 100150, in_syscall = 1, cs = {sc = 0x0, name = 0x0, number = 580828064, args = 0x2061b0c0, nargs = 0, > s_args = 0x2061b0ec}, before = {tv_sec = 1477418265, tv_nsec = 492342263}, after = {tv_sec = 1477418265, tv_nsec = 492496630}} > > (gdb) print sc > $3 = (struct syscall *) 0x0 > > So line 386 listed above gets a segmentation fault for sc->nargs when t->cs.name is a NULL pointer: sc ends up NULL. > > Looking at the two things that the fprintf on lines 382 and 383 would report: > > (gdb) print t->proc->abi->type > $4 = 0x10166 "FreeBSD ELF32" > > (gdb) print t->cs.number > $5 = 580828064 > > (gdb) print narg > $6 = 0 > > (that last is for context for the get_syscall arguments). > > FYI: 580828064 = 0x229EBBA0 I have a patchset I have tested some in a git branch that I believe fixes handling of unknown system calls. Please try this: https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown (Add .diff to get a diff you can apply with patch) -- John Baldwin From owner-freebsd-stable@freebsd.org Fri Oct 28 23:29:09 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6287BC255C6 for ; Fri, 28 Oct 2016 23:29:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-55.reflexion.net [208.70.210.55]) (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 288A4670 for ; Fri, 28 Oct 2016 23:29:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10780 invoked from network); 28 Oct 2016 23:02:27 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 Oct 2016 23:02:27 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Fri, 28 Oct 2016 19:02:36 -0400 (EDT) Received: (qmail 3659 invoked from network); 28 Oct 2016 23:02:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Oct 2016 23:02:36 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3181CEC8F25; Fri, 28 Oct 2016 16:02:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call From: Mark Millard In-Reply-To: <2661167.K5IN9JAPmQ@ralph.baldwin.cx> Date: Fri, 28 Oct 2016 16:02:26 -0700 Cc: freebsd-current@freebsd.org, freebsd-arm , FreeBSD-STABLE Mailing List , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> <2661167.K5IN9JAPmQ@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 23:29:09 -0000 On 2016-Oct-28, at 7:29 AM, John Baldwin wrote: > On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote: >> [The following has been reported in: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213778 .] >>=20 >> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In = trying to track things down I ran into truss getting a SIGSEGV when it = tries to handle the situation. . . >>=20 >> In truss's enter_syscall there is (from a live gdb on truss, after = the segmentation fault): >>=20 >> 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); >> 381 if (t->cs.name =3D=3D NULL) >> (gdb)=20 >> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", >> 383 t->proc->abi->type, t->cs.number); >> 384=09 >> 385 sc =3D get_syscall(t->cs.name, narg); >> 386 t->cs.nargs =3D sc->nargs; >> 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); >> 388=09 >> 389 t->cs.sc =3D sc; >>=20 >> (gdb) print *t >> $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D= 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name = =3D 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 >> s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec = =3D 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D = 492496630}} >>=20 >> (gdb) print sc >> $3 =3D (struct syscall *) 0x0 >>=20 >> So line 386 listed above gets a segmentation fault for sc->nargs when = t->cs.name is a NULL pointer: sc ends up NULL. >>=20 >> Looking at the two things that the fprintf on lines 382 and 383 would = report: >>=20 >> (gdb) print t->proc->abi->type >> $4 =3D 0x10166 "FreeBSD ELF32" >>=20 >> (gdb) print t->cs.number >> $5 =3D 580828064 >>=20 >> (gdb) print narg >> $6 =3D 0 >>=20 >> (that last is for context for the get_syscall arguments). >>=20 >> FYI: 580828064 =3D 0x229EBBA0 >=20 > I have a patchset I have tested some in a git branch that I believe = fixes handling of > unknown system calls. Please try this: >=20 > = https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown >=20 > (Add .diff to get a diff you can apply with patch) >=20 > --=20 > John Baldwin Sorry it took so long to try the build. . . I got a compile failure for use of bool in my stable/11 context for the = BPI-M3 build that the truss problem was discovered with (quoting the = build log below): > --- main.o --- > cc -target armv6-gnueabihf-freebsd11.0 = --sysroot=3D/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp = -B/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp/usr/bin -O -pipe = -I/usr/src/usr.bin/truss -I. -I/usr/src/usr.bin/truss/../../sys -g -MD = -MF.depend.main.o -MTma > in.o -std=3Dgnu99 -Wsystem-headers -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline = -Wnested-externs=20 > -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = /usr/src/usr.bin/truss/main.c -o main.o > In file included from /usr/src/usr.bin/truss/main.c:53: > /usr/src/usr.bin/truss/syscall.h:75:2: error: unknown type name 'bool' > bool unknown; /* Uknown system call */ > ^ > 1 error generated. > *** [main.o] Error code 1 >=20 > make[4]: stopped in /usr/src/usr.bin/truss > 1 error In C99 bool is a macro from and _Bool is the C99 type = itself. So apparently (or an equivalent) was not directly or = indirectly included. (The macros true and false and = __bool_true_false_are_defined are also from .) Which way do you want the C99 typing to be handled for this: native C99 = with no required? Use ? Side note: I'll see about getting my normal stable/11 build environment going for = the BPI-M3 instead of using the crochet from my first-time build for the = target. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Sat Oct 29 10:22:29 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7187C26136 for ; Sat, 29 Oct 2016 10:22:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-56.reflexion.net [208.70.210.56]) (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 65F5A91C for ; Sat, 29 Oct 2016 10:22:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31941 invoked from network); 29 Oct 2016 10:22:26 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Oct 2016 10:22:26 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Sat, 29 Oct 2016 06:22:31 -0400 (EDT) Received: (qmail 734 invoked from network); 29 Oct 2016 10:22:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Oct 2016 10:22:30 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 92C39EC90F1; Sat, 29 Oct 2016 03:22:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call From: Mark Millard In-Reply-To: Date: Sat, 29 Oct 2016 03:22:25 -0700 Cc: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <05266324-67D0-4487-BF94-58B831C79F5B@dsl-only.net> References: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> <2661167.K5IN9JAPmQ@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 10:22:29 -0000 On 2016-Oct-28, at 4:02 PM, Mark Millard wrote: > On 2016-Oct-28, at 7:29 AM, John Baldwin wrote: >=20 >> On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote: >>> [The following has been reported in: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213778 .] >>>=20 >>> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In = trying to track things down I ran into truss getting a SIGSEGV when it = tries to handle the situation. . . >>>=20 >>> In truss's enter_syscall there is (from a live gdb on truss, after = the segmentation fault): >>>=20 >>> 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); >>> 381 if (t->cs.name =3D=3D NULL) >>> (gdb)=20 >>> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", >>> 383 t->proc->abi->type, t->cs.number); >>> 384=09 >>> 385 sc =3D get_syscall(t->cs.name, narg); >>> 386 t->cs.nargs =3D sc->nargs; >>> 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); >>> 388=09 >>> 389 t->cs.sc =3D sc; >>>=20 >>> (gdb) print *t >>> $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc = =3D 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, = name =3D 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 >>> s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec = =3D 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D = 492496630}} >>>=20 >>> (gdb) print sc >>> $3 =3D (struct syscall *) 0x0 >>>=20 >>> So line 386 listed above gets a segmentation fault for sc->nargs = when t->cs.name is a NULL pointer: sc ends up NULL. >>>=20 >>> Looking at the two things that the fprintf on lines 382 and 383 = would report: >>>=20 >>> (gdb) print t->proc->abi->type >>> $4 =3D 0x10166 "FreeBSD ELF32" >>>=20 >>> (gdb) print t->cs.number >>> $5 =3D 580828064 >>>=20 >>> (gdb) print narg >>> $6 =3D 0 >>>=20 >>> (that last is for context for the get_syscall arguments). >>>=20 >>> FYI: 580828064 =3D 0x229EBBA0 >>=20 >> I have a patchset I have tested some in a git branch that I believe = fixes handling of >> unknown system calls. Please try this: >>=20 >> = https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown >>=20 >> (Add .diff to get a diff you can apply with patch) >>=20 >> --=20 >> John Baldwin >=20 > Sorry it took so long to try the build. . . >=20 > I got a compile failure for use of bool in my stable/11 context for = the BPI-M3 build that the truss problem was discovered with (quoting the = build log below): >=20 >> --- main.o --- >> cc -target armv6-gnueabihf-freebsd11.0 = --sysroot=3D/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp = -B/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp/usr/bin -O -pipe = -I/usr/src/usr.bin/truss -I. -I/usr/src/usr.bin/truss/../../sys -g -MD = -MF.depend.main.o -MTma >> in.o -std=3Dgnu99 -Wsystem-headers -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline = -Wnested-externs=20 >> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = /usr/src/usr.bin/truss/main.c -o main.o >> In file included from /usr/src/usr.bin/truss/main.c:53: >> /usr/src/usr.bin/truss/syscall.h:75:2: error: unknown type name = 'bool' >> bool unknown; /* Uknown system call */ >> ^ >> 1 error generated. >> *** [main.o] Error code 1 >>=20 >> make[4]: stopped in /usr/src/usr.bin/truss >> 1 error >=20 >=20 > In C99 bool is a macro from and _Bool is the C99 type = itself. So apparently (or an equivalent) was not directly or = indirectly included. (The macros true and false and = __bool_true_false_are_defined are also from .) >=20 > Which way do you want the C99 typing to be handled for this: native = C99 with no required? Use ? >=20 >=20 > Side note: >=20 > I'll see about getting my normal stable/11 build environment going for = the BPI-M3 instead of using the crochet from my first-time build for the = target. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net [Once I got back to this test yet again I arbitrarily added a #include = to allow truss to build during buildworld.] The way I normally build (instead of crochet) did not get the original = cc1 problem in its original form. So as of yet I've not managed to = reproduce the test case accurately: Back to crochet. I will note that in my "with debug symbols" and -mcpu=3Dcortex-a7 style = of buildworld buildkernel type of boot context I got an explicit message = in the xgcc/cc1 test that may indicate the original problem for cc1: /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1: Undefined = symbol "__aeabi_uidiv" [bugzilla https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213785 ] At this stage in trying to bootstrap lang/gcc6 as the first gcc compiler = on the BPi-M3: # ldd /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1: libmpc.so.3 =3D> /usr/local/lib/libmpc.so.3 (0x21aff000) libmpfr.so.4 =3D> /usr/local/lib/libmpfr.so.4 (0x21b25000) libgmp.so.10 =3D> /usr/local/lib/libgmp.so.10 (0x21bba000) libz.so.6 =3D> /lib/libz.so.6 (0x21c5b000) libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x21c77000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x21d1d000) libm.so.5 =3D> /lib/libm.so.5 (0x21d3f000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x21d62000) libc.so.7 =3D> /lib/libc.so.7 (0x21e00000) So /usr/local/lib/ is not yet providing gcc's own library of primitives = for xgcc or cc1 to use and when FreeBSD is missing something = like__aeabi_uidiv that xgcc/cc1 expects to use there could then be = problems: # ls -l /usr/local/lib total 127288 -r-xr-xr-x 1 root wheel 10168 Oct 25 07:39 bindtextdomain.so drwxr-xr-x 2 root wheel 512 Oct 25 05:57 gettext -rw-r--r-- 1 root wheel 72026 Oct 25 05:40 libasprintf.a lrwxr-xr-x 1 root wheel 20 Oct 25 05:40 libasprintf.so -> = libasprintf.so.0.0.0 lrwxr-xr-x 1 root wheel 20 Oct 25 05:40 libasprintf.so.0 -> = libasprintf.so.0.0.0 -rwxr-xr-x 1 root wheel 64717 Oct 25 05:40 libasprintf.so.0.0.0 -rw-r--r-- 1 root wheel 58917550 Oct 25 08:52 libbfd.a -rwxr-xr-x 1 root wheel 4421893 Oct 25 05:56 = libgettextlib-0.19.8.1.so lrwxr-xr-x 1 root wheel 25 Oct 25 05:56 libgettextlib.so -> = libgettextlib-0.19.8.1.so -rw-r--r-- 1 root wheel 1611908 Oct 25 05:56 libgettextpo.a lrwxr-xr-x 1 root wheel 21 Oct 25 05:56 libgettextpo.so -> = libgettextpo.so.0.5.4 lrwxr-xr-x 1 root wheel 21 Oct 25 05:56 libgettextpo.so.0 -> = libgettextpo.so.0.5.4 -rwxr-xr-x 1 root wheel 1134132 Oct 25 05:56 libgettextpo.so.0.5.4 -rwxr-xr-x 1 root wheel 1005228 Oct 25 05:56 = libgettextsrc-0.19.8.1.so lrwxr-xr-x 1 root wheel 25 Oct 25 05:56 libgettextsrc.so -> = libgettextsrc-0.19.8.1.so -rw-r--r-- 1 root wheel 2935784 Oct 25 08:01 libgmp.a lrwxr-xr-x 1 root wheel 16 Oct 25 08:01 libgmp.so -> = libgmp.so.10.1.3 lrwxr-xr-x 1 root wheel 16 Oct 25 08:01 libgmp.so.10 -> = libgmp.so.10.1.3 -rwxr-xr-x 1 root wheel 1709666 Oct 25 08:01 libgmp.so.10.1.3 -rw-r--r-- 1 root wheel 1112250 Oct 25 08:01 libgmpxx.a lrwxr-xr-x 1 root wheel 17 Oct 25 08:01 libgmpxx.so -> = libgmpxx.so.4.3.3 lrwxr-xr-x 1 root wheel 17 Oct 25 08:01 libgmpxx.so.4 -> = libgmpxx.so.4.3.3 -rwxr-xr-x 1 root wheel 657771 Oct 25 08:01 libgmpxx.so.4.3.3 -rw-r--r-- 1 root wheel 238518 Oct 25 05:40 libintl.a lrwxr-xr-x 1 root wheel 16 Oct 25 05:40 libintl.so -> = libintl.so.8.1.5 lrwxr-xr-x 1 root wheel 16 Oct 25 05:40 libintl.so.8 -> = libintl.so.8.1.5 -rw-r--r-- 1 root wheel 157207 Oct 25 05:40 libintl.so.8.1.5 lrwxr-xr-x 1 root wheel 12 Oct 25 05:40 libintl.so.9 -> = libintl.so.8 -rw-r--r-- 1 root wheel 565968 Oct 25 09:02 libmpc.a lrwxr-xr-x 1 root wheel 15 Oct 25 09:02 libmpc.so -> = libmpc.so.3.0.0 lrwxr-xr-x 1 root wheel 15 Oct 25 09:02 libmpc.so.3 -> = libmpc.so.3.0.0 -rwxr-xr-x 1 root wheel 346999 Oct 25 09:02 libmpc.so.3.0.0 -rw-r--r-- 1 root wheel 2053300 Oct 25 08:05 libmpfr.a lrwxr-xr-x 1 root wheel 16 Oct 25 08:05 libmpfr.so -> = libmpfr.so.4.1.5 lrwxr-xr-x 1 root wheel 16 Oct 25 08:05 libmpfr.so.4 -> = libmpfr.so.4.1.5 -rwxr-xr-x 1 root wheel 1294011 Oct 25 08:05 libmpfr.so.4.1.5 -rw-r--r-- 1 root wheel 38488604 Oct 25 08:52 libopcodes.a -rw-r--r-- 1 root wheel 7155654 Oct 25 05:36 libpkg.a lrwxr-xr-x 1 root wheel 15 Oct 25 05:36 libpkg.so -> = libpkg.so.3.0.0 lrwxr-xr-x 1 root wheel 15 Oct 25 05:36 libpkg.so.3 -> = libpkg.so.3.0.0 -rwxr-xr-x 1 root wheel 5621424 Oct 25 05:36 libpkg.so.3.0.0 drwxr-xr-x 4 root wheel 512 Oct 25 07:37 perl5 Part of the issue may be that unlike my usual procedure for gcc* builds: OPTIONS_FILE_UNSET+=3DBOOTSTRAP for the BPI-M3 lang/gcc6 build I used: OPTIONS_FILE_SET+=3DBOOTSTRAP This might explain why I did not see a problem on the rpi2 historically. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Sat Oct 29 15:32:23 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B428C258E8 for ; Sat, 29 Oct 2016 15:32:23 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 A5689215 for ; Sat, 29 Oct 2016 15:32:22 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id u9TFWIax020237 for ; Sat, 29 Oct 2016 17:32:18 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 56EE7B23; Sat, 29 Oct 2016 17:32:18 +0200 (CEST) Message-ID: <5814C101.90805@omnilan.de> Date: Sat, 29 Oct 2016 17:32:17 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Unexpected ahci-hd bytes when running in bhyve(8) References: <58124200.5080306@omnilan.de> In-Reply-To: <58124200.5080306@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sat, 29 Oct 2016 17:32:18 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 15:32:23 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 27.10.2016 20:05 (localtime): > Hello, > > I wanted to use a "roaming" ssd with byhve/vmm, which is the home of a > GPT based FreeBSD setup. > I've been using this for years with ESXi and bare-metal-hosts, and > wanted to try out bhyve. > Unfortunately this doesn't work the way I'm used to. > Booting of ufs:/dev/gpt/myROOT fails with error 19, loader does only see > a diskid/BHYVEDISK, not the GPT partitions. > > I guess ahci-hd isn't 1:1 mapping blocks, neither does virtio-blk, since > it shows exactly the same result, which is a bit strange to me: > When I boot a Live-CD in vmm with the physical SSD ahci-hd attached, the > first 8kByte of /dev/ada0 is 0x0. > > The same test on the host ('dd if=/dev/ada4 count=16 | hd') shows me > PMBR and GPT content, which I also expected to see in bhyve… > > What am I missing? To verify whether my assumptions might be correct at all, I installed a bhyve guest on a file backed ahci-hd drive (/usr/local/guest.img). The first 448 byte of that file are exactly the same when inspected on the host as the first 448 bytes of /dev/ada4. Inspecting /dev/ada0 inside the guest vmm, I see again the same 448 bytes when /usr/local/guest.img was attached to ahci-hd (-s 7,ahci-hd,/usr/local/guest.img). That was what I expected. What I don't understand is why my expectations are true for /usr/local/guest.img but not for /dev/ada4. Like mentioned, while reading the first 448 bytes on the host, I get identical results from /usr/local/guest.img and /dev/ada4, but when attaching /dev/ada4 to ahci-hd (-s 7,ahci-hd,/dev/ada4) and inspecting inside vmm, all I see is 0x0, while ahci-hd attached /usr/local/guest.img shows the same pmbr as on the host!? Do I have to exclude /dev/ada4 on the host from geom? As soon as bhyve opens /dev/ada4, all partitions vanish from the host – probably ada4 itself gets blocked somehow? Thanks for any hint in advance, -harry From owner-freebsd-stable@freebsd.org Sat Oct 29 17:35:27 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91CDAC20A4E for ; Sat, 29 Oct 2016 17:35:27 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 173DDD29; Sat, 29 Oct 2016 17:35:26 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id u9THZPo7021161; Sat, 29 Oct 2016 19:35:25 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id DC221B3F; Sat, 29 Oct 2016 19:35:24 +0200 (CEST) Message-ID: <5814DDDC.60104@omnilan.de> Date: Sat, 29 Oct 2016 19:35:24 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org CC: Alexander Motin Subject: Re: Unexpected ahci-hd bytes when running in bhyve(8) References: <58124200.5080306@omnilan.de> <5814C101.90805@omnilan.de> In-Reply-To: <5814C101.90805@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sat, 29 Oct 2016 19:35:25 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 17:35:27 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 29.10.2016 17:32 (localtime): … > Like mentioned, while reading the first 448 bytes on the host, I get > identical results from /usr/local/guest.img and /dev/ada4, but when > attaching /dev/ada4 to ahci-hd (-s 7,ahci-hd,/dev/ada4) and inspecting > inside vmm, all I see is 0x0, while ahci-hd attached > /usr/local/guest.img shows the same pmbr as on the host!? > > Do I have to exclude /dev/ada4 on the host from geom? As soon as bhyve > opens /dev/ada4, all partitions vanish from the host – probably ada4 > itself gets blocked somehow? Maybe that's related? https://lists.freebsd.org/pipermail/freebsd-virtualization/2015-April/003509.html (resulting in https://svnweb.freebsd.org/base?view=revision&revision=281700) Just another symptom I can only describe, not debug: Opening /dev/adaX on the host works by 'hd /dev/ada4 | less', but not inside the guest, where it just leads to endless IO when trying the same on the ahci-hd attached /dev/ada4. Of course I found discussion threads about virtio-scsi, which was more appropriate for my needs, but unfortunately nobody skilled enough had time to implement yet afaik and it also wouldn't solve my problems while this ssd is SATA attached (could switch to a SAS port so the HBA would do SAT which should work then...) Are there any other ways I'm missing to get mass storage into the guest? ZVOl is a very good candidate for many setups, but not for all. RAw-device-mappings to HBA-virtual-drives is doing a great job on ESXi, but replacing HBA-virt-drive RAW-mappings with ZVOL isn't really the same and sometimes I need physical devices in the guest. P(cie)P(ass)T(through) seems to work great in bhyve, but I can't sacrifice a complete HBA to accomplish. Thanks, -harry From owner-freebsd-stable@freebsd.org Sat Oct 29 21:18:04 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74521C267D0 for ; Sat, 29 Oct 2016 21:18:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-58.reflexion.net [208.70.210.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 313DFA44 for ; Sat, 29 Oct 2016 21:18:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3256 invoked from network); 29 Oct 2016 21:18:59 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Oct 2016 21:18:59 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Sat, 29 Oct 2016 17:18:06 -0400 (EDT) Received: (qmail 12710 invoked from network); 29 Oct 2016 21:18:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Oct 2016 21:18:06 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B30F5EC8AEF; Sat, 29 Oct 2016 14:18:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call From: Mark Millard In-Reply-To: <2661167.K5IN9JAPmQ@ralph.baldwin.cx> Date: Sat, 29 Oct 2016 14:18:01 -0700 Cc: freebsd-current@freebsd.org, freebsd-arm , FreeBSD-STABLE Mailing List , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <0699F744-DEB3-4ED5-91A9-B77EA2ACED37@dsl-only.net> <2661167.K5IN9JAPmQ@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 21:18:04 -0000 [I re-established the crotchet-build based failure context finally. = Unfortunately truss just dies in a new place.] On 2016-Oct-28, at 7:29 AM, John Baldwin wrote: > On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote: >> [The following has been reported in: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213778 .] >>=20 >> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In = trying to track things down I ran into truss getting a SIGSEGV when it = tries to handle the situation. . . >>=20 >> In truss's enter_syscall there is (from a live gdb on truss, after = the segmentation fault): >>=20 >> 380 t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi, = t->cs.number); >> 381 if (t->cs.name =3D=3D NULL) >> (gdb)=20 >> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", >> 383 t->proc->abi->type, t->cs.number); >> 384=09 >> 385 sc =3D get_syscall(t->cs.name, narg); >> 386 t->cs.nargs =3D sc->nargs; >> 387 assert(sc->nargs <=3D nitems(t->cs.s_args)); >> 388=09 >> 389 t->cs.sc =3D sc; >>=20 >> (gdb) print *t >> $2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D= 0x20617060, tid =3D 100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name = =3D 0x0, number =3D 580828064, args =3D 0x2061b0c0, nargs =3D 0,=20 >> s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec = =3D 492342263}, after =3D {tv_sec =3D 1477418265, tv_nsec =3D = 492496630}} >>=20 >> (gdb) print sc >> $3 =3D (struct syscall *) 0x0 >>=20 >> So line 386 listed above gets a segmentation fault for sc->nargs when = t->cs.name is a NULL pointer: sc ends up NULL. >>=20 >> Looking at the two things that the fprintf on lines 382 and 383 would = report: >>=20 >> (gdb) print t->proc->abi->type >> $4 =3D 0x10166 "FreeBSD ELF32" >>=20 >> (gdb) print t->cs.number >> $5 =3D 580828064 >>=20 >> (gdb) print narg >> $6 =3D 0 >>=20 >> (that last is for context for the get_syscall arguments). >>=20 >> FYI: 580828064 =3D 0x229EBBA0 >=20 > I have a patchset I have tested some in a git branch that I believe = fixes handling of > unknown system calls. Please try this: >=20 > = https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown >=20 > (Add .diff to get a diff you can apply with patch) >=20 >=20 > --=20 > John Baldwin [Watch out for inlining consequences in how gdb presents things. Also I = extracted from my explorations and changed the presentation order to = eliminate junk.] Summary: st->syscalls ends up NULL from reallocf refusing a huge = allocation because t->cs.number=3D=3D580828064, which would make for a = huge offset in st->syscalls[number] . new_count * = sizeof(st->syscalls[0]) would be rather large (new_count =3D=3D = number+1) . reallocf's result needs to be tested and/or reasonable-value-checks on = t->cs.number (a.k.a. number) need to be made and unreasonable value = handled some other way. The supporting details: = root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-= portbld-freebsd11.0/libgcc # gdb truss GNU gdb 6.1.1 [FreeBSD] . . . (gdb) run -faeH -o truss.log = /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc = -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ = -B/usr/local/armv6-portbld-freebsd11.0/bin/ = -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem = /usr/local/armv6-portbld-freebsd11.0/include -isystem = /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC -W = -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format = -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem = ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g = -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread = -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc = -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include = -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep = -DL_muldi3 -c = /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c = -fvisibility=3Dhidden -DHIDE_EXPORTS Starting program: /usr/bin/truss -faeH -o truss.log . . . . Program received signal SIGSEGV, Segmentation fault. 0x20241ebc in memset () from /lib/libc.so.7 Current language: auto; currently minimal (gdb) bt #0 0x20241ebc in memset () from /lib/libc.so.7 #1 0x0000aec8 in get_syscall (t=3D, = number=3D580828064, nargs=3D0) at /usr/src/usr.bin/truss/syscalls.c:956 #2 0x0000ab8c in enter_syscall (info=3D0x20612000, t=3D0x2061b0a0, = pl=3D) at /usr/src/usr.bin/truss/setup.c:380 #3 0x0000a798 in eventloop (info=3D) at = /usr/src/usr.bin/truss/setup.c:664 #4 0x000098d4 in $a.6 () at /usr/src/usr.bin/truss/main.c:207 #5 0x000098d4 in $a.6 () at /usr/src/usr.bin/truss/main.c:207 (gdb) up #1 0x0000aec8 in get_syscall (t=3D, = number=3D580828064, nargs=3D0) at /usr/src/usr.bin/truss/syscalls.c:956 956 memset(st->syscalls + st->count, 0, (new_count - = st->count) * . . . 0x20241eac : cmp r1, #4 ; 0x4 0x20241eb0 : bge 0x20241dd4 0x20241eb4 : cmp r1, #0 ; 0x0 0x20241eb8 : moveq pc, lr 0x20241ebc : strb r3, [r12], #1 . . . (gdb) info reg r0 0x0 0 r1 0x8a7aee84 -1971655036 r2 0x8a7aee84 -1971655036 r3 0x0 0 r4 0x1 1 r5 0x2062000c 543293452 r6 0x20620000 543293440 r7 0x229ebba1 580828065 r8 0x2061b0b0 543273136 r9 0x0 0 r10 0x229ebba0 580828064 r11 0xbfbfe478 -1077943176 r12 0x0 0 sp 0xbfbfe450 -1077943216 lr 0xaec8 44744 pc 0x20241ebc 539238076 fps 0x0 0 cpsr 0xa0000010 -1610612720 . . . (gdb)=20 946 static void 947 grow_syscall_table(struct syscall_table *st, u_int number) 948 { 949 u_int new_count; 950=09 951 new_count =3D number + 1; 952 if (st->count >=3D new_count) 953 return; 954 st->syscalls =3D reallocf(st->syscalls, new_count * 955 sizeof(st->syscalls[0])); (gdb)=20 956 memset(st->syscalls + st->count, 0, (new_count - = st->count) * 957 sizeof(st->syscalls[0])); 958 } 959=09 960 /* 961 * If/when the list gets big, it might be desirable to do it 962 * as a hash table or binary search. 963 */ 964 struct syscall * 965 get_syscall(struct threadinfo *t, u_int number, u_int nargs) (gdb)=20 966 { 967 struct syscall_table *st; 968 struct syscall *sc; 969 const char *name; 970 u_int i; 971=09 972 st =3D lookup_syscall_table(t->proc->abi->abi); 973 grow_syscall_table(st, number); 974 sc =3D st->syscalls[number]; 975 if (sc !=3D NULL) (gdb)=20 976 return (sc); . . . 951 new_count =3D number + 1; 952 if (st->count >=3D new_count) 953 return; 954 st->syscalls =3D reallocf(st->syscalls, new_count * 955 sizeof(st->syscalls[0])); 956 memset(st->syscalls + st->count, 0, (new_count - = st->count) * 957 sizeof(st->syscalls[0])); 958 } 959=09 960 /* (gdb) up #2 0x0000ab8c in enter_syscall (info=3D0x20612000, t=3D0x2061b0a0, = pl=3D) at /usr/src/usr.bin/truss/setup.c:380 380 sc =3D get_syscall(t, t->cs.number, narg); (gdb) list 375 if (narg !=3D 0 && t->proc->abi->fetch_args(info, narg) = !=3D 0) { 376 free_syscall(t); 377 return; 378 } 379=09 380 sc =3D get_syscall(t, t->cs.number, narg); 381 if (sc->unknown) 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d = --\n", 383 t->proc->abi->type, t->cs.number); 384=09 (gdb) print *t=20 $1 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617028}, proc =3D = 0x20617018, tid =3D 100103, in_syscall =3D 1, cs =3D {sc =3D 0x0, number = =3D 580828064, nargs =3D 0, args =3D 0x2061b0c0, s_args =3D 0x2061b0e8},=20= before =3D {tv_sec =3D 1477771714, tv_nsec =3D 696971654}, after =3D = {tv_sec =3D 1477771714, tv_nsec =3D 697117646}} (gdb) print narg $2 =3D 0 . . . (gdb) print t->cs.number $9 =3D 580828064 . . . (gdb) print *(t->proc) $6 =3D {entries =3D {le_next =3D 0x20617000, le_prev =3D 0x20617048}, = pid =3D 808, abi =3D 0x1ee68, threadlist =3D {lh_first =3D 0x2061b0a0}} (gdb) print *(t->proc->abi) $7 =3D {type =3D 0x1026b "FreeBSD ELF32", abi =3D SYSDECODE_ABI_FREEBSD, = fetch_args =3D 0xda44 , fetch_retval =3D 0xdb64 = } (gdb) print t->proc->abi->abi $8 =3D SYSDECODE_ABI_FREEBSD So for t->cs.number=3D=3D580828064 : 380 sc =3D get_syscall(t, t->cs.number, narg); . . . 965 get_syscall(struct threadinfo *t, u_int number, u_int nargs) . . . 973 grow_syscall_table(st, number); 974 sc =3D st->syscalls[number]; would get very far away from st->syscalls after indexing by the large = number=3D=3D580828064 --if the grow could even complete for = number=3D=3D580828064 : 947 grow_syscall_table(struct syscall_table *st, u_int number) 948 { . .. 951 new_count =3D number + 1; . . . 954 st->syscalls =3D reallocf(st->syscalls, new_count * 955 sizeof(st->syscalls[0])); 956 memset(st->syscalls + st->count, 0, (new_count - = st->count) * 957 sizeof(st->syscalls[0])); st->syscalls was NULL after reallocf returned the value NUKL. =3D=3D=3D Mark Millard markmi at dsl-only.net