From owner-freebsd-arm@freebsd.org Sun Jul 29 01:02:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D79C410634DC for ; Sun, 29 Jul 2018 01:02:05 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6072C88A3A for ; Sun, 29 Jul 2018 01:02:04 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w6T11vcB043290 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 28 Jul 2018 18:01:57 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w6T11vgT043289 for freebsd-arm@FreeBSD.org; Sat, 28 Jul 2018 18:01:57 -0700 (PDT) (envelope-from jmg) Date: Sat, 28 Jul 2018 18:01:57 -0700 From: John-Mark Gurney To: freebsd-arm@FreeBSD.org Subject: sx_sleep not waking up when timo expires Message-ID: <20180729010157.GC2884@funkthat.com> Mail-Followup-To: freebsd-arm@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 28 Jul 2018 18:01:57 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 01:02:06 -0000 I recently upgraded my router to an Pine A64-LTS board, and have hit the same issue as PR 222126[1]. The solution at the end does not work for me, as I do not have that line in my loader.conf: kern.timecounter.smp_tsc_adjust=1 I have verified that the wake up does not happen, as I used a dtrace script to verify that pf_purge_expired_states is called or not called.. When I change the timeout, pf will kick the thread and get things running again, but it has stopped a couple times later... I'm running a recent SNAPSHOT: FreeBSD gate2.funkthat.com 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r336134: Mon Jul 9 19:20:11 UTC 2018 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 This is likely reproducable by just starting pf, even in a pass all mode, and watching for when the function stops getting called... I'll see if I can't get an extermely minimal config to reproduce it. Any suggestions? [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Sun Jul 29 11:29:32 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B5CE1053FC0 for ; Sun, 29 Jul 2018 11:29:32 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D37E7CC82 for ; Sun, 29 Jul 2018 11:29:31 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1532863764; bh=XBzWtCyfpquMRgGAM1mGVXcpXU1lCRL/aldH++zwFOo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=bXBYP4TLAYZqGMWYyIDDLtYhRK6YIprejp87ZVbC1Go0HvF6kPlm8TXrmgskWt/y1 ddM5iFMUaJuP43WYme5PW31YMUO8nfp7l2nB6WVx9vWfVD3IAbEzl12gqDBTkd4zBB n2V3tl8QmnTRjtsdGd2lr1p7UnRyQxxR00aODxog= Subject: Re: rpi3 and Adafruit GPS hat continued To: Ralph Smith Cc: freebsd-arm References: <2f55aaea-6832-7441-1011-b8288628a4a9@nethead.se> <2aee4fd4-c221-23a6-00e4-1db2694bfef6@nethead.se> <6DCECF08-1366-4289-9929-94A967284291@ralphsmith.org> From: Per olof Ljungmark Message-ID: Date: Sun, 29 Jul 2018 13:29:17 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6DCECF08-1366-4289-9929-94A967284291@ralphsmith.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 11:29:32 -0000 On 07/25/18 16:35, Ralph Smith wrote: > > > Sent from my iPhone > >> On Jul 25, 2018, at 10:26 AM, Per olof Ljungmark wrote: >> >>> On 07/25/18 12:35, Ralph Smith wrote: >>> >>> >>> Sent from my iPhone >>> >>>>> On Jul 25, 2018, at 5:55 AM, Per olof Ljungmark wrote: >>>>> >>>>>> On 07/25/18 11:27, Per olof Ljungmark wrote: >>>>>> On 07/25/18 04:25, Warner Losh wrote: >>>>>> >>>>>> >>>>>> On Tue, Jul 24, 2018 at 1:44 PM, Per olof Ljungmark >>>>> > wrote: >>>>>> >>>>>> Thanks to >>>>>> http://freebsd.1045724.x6.nabble.com/Adding-a-GPS-Module-hat-shield-on-a-Raspberry-Pi-td6236680.html >>>>>> >>>>>> and helpful people on the list I managed to get the pi to boot by >>>>>> silencing the console messages in u-boot. >>>>>> >>>>>> I skipped the switch and patched rpi.h: >>>>>> >>>>>> @@ -85,10 +87,13 @@ >>>>>> #define CONFIG_INITRD_TAG >>>>>> >>>>>> /* Environment */ >>>>>> +#define CONFIG_SYS_DEVICE_NULLDEV >>>>>> +#define CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC >>>>>> +#define CONFIG_SILENT_CONSOLE_UPDATE_ON_SET >>>>>> #define ENV_DEVICE_SETTINGS \ >>>>>> - "stdin=serial,usbkbd\0" \ >>>>>> - "stdout=serial,vidconsole\0" \ >>>>>> - "stderr=serial,vidconsole\0" >>>>>> + "stdin=usbkbd\0" \ >>>>>> + "stdout=vidconsole\0" \ >>>>>> + "stderr=vidconsole\0" >>>>>> >>>>>> and now the pi is booting. >>>>>> >>>>>> Now to the next problem, I need to rewire TXD and RXD and add reception >>>>>> of the PPS signal on pin 4. The advice in the link above is not >>>>>> appclicable to current and rpi3. >>>>>> >>>>>> Right now uart1 is wired to the RXD and TXD pins, I want uart0. Is it >>>>>> recompile a dts or use gpioctl? >>>>>> >>>>>> uart0: mem 0x7e201000-0x7e201fff irq 24 on >>>>>> simplebus0 >>>>>> uart1: mem 0x7e215040-0x7e21507f irq 32 on >>>>>> simplebus0 >>>>>> uart1: console (115200,n,8,1) >>>>>> >>>>>> >>>>>> I'm pretty sure that you'll need to hack dts. >>>>> >>>>> Yes. Most importantly, stop the kernel from talking to the serial console. >>>>> >>>>> I've been wandering around the source and right now the theory is to >>>>> change /usr/src/sys/gnu/dts/arm/bcm283x.dtsi, it is the only place in >>>>> all the included dts files where I find a reference to the console: >>>>> >>>>> chosen { >>>>> stdout-path = "serial0:115200n8"; >>>>> }; >>>>> >>>>> Says nothing about stdin though, not anywhere. >>>> >>>> Tried stdout-path = ""; but that did not help. >>>> >>>> I'm giving up and move to rpi2 and 11.2 instead. Phew. >>> >>> Just another gotcha to worry about: be aware of the difference between the rpi2 board versions 1.1 and 1.2. They quietly changed the SOC, so FreeBSD 11.1 would not boot on the rev 1.2 board. It will boot FreeBSD 11.2, but I’ve not tried the GPS HAT on that yet. >> >> I have dug out a rpi2 v1.1 and now wandering what image to boot, the >> v1.1 is armv7 but can't find any images for 11 and armv7. Does this mean >> I have to build it? The idea here was to aviod 12 due to the dts shuffle. > > For 11 you will need to use armv6. > Just FYI, I have the hat working now on the rpi2 v1.1 with 11-STABLE and about to learn how to use the rpi3+current with the hat as well. One thing I have realised is the the pi's can be a bit flaky, perhaps you could recommend some other single board cpu that works with FreeBSD 12? Like the rpi3 or even better spec. Thanks, From owner-freebsd-arm@freebsd.org Sun Jul 29 13:45:11 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CC781057928 for ; Sun, 29 Jul 2018 13:45:11 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 26D6281AEC for ; Sun, 29 Jul 2018 13:45:11 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w6TDhfa0028497 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 29 Jul 2018 06:43:41 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w6TDheX5028496; Sun, 29 Jul 2018 06:43:40 -0700 (PDT) (envelope-from warlock) Date: Sun, 29 Jul 2018 06:43:40 -0700 From: John Kennedy To: Per olof Ljungmark Cc: Ralph Smith , freebsd-arm Subject: Re: rpi3 and Adafruit GPS hat continued Message-ID: <20180729134340.GH75644@phouka1.phouka.net> References: <2f55aaea-6832-7441-1011-b8288628a4a9@nethead.se> <2aee4fd4-c221-23a6-00e4-1db2694bfef6@nethead.se> <6DCECF08-1366-4289-9929-94A967284291@ralphsmith.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 13:45:11 -0000 On Sun, Jul 29, 2018 at 01:29:17PM +0200, Per olof Ljungmark wrote: > Just FYI, I have the hat working now on the rpi2 v1.1 with 11-STABLE and > about to learn how to use the rpi3+current with the hat as well. > > One thing I have realised is the the pi's can be a bit flaky, perhaps > you could recommend some other single board cpu that works with FreeBSD > 12? Like the rpi3 or even better spec. I gave the RPI2* a miss, but I've been running my RPI3B+ on 12 since ~June 22nd (starting with the -RPI3-20180618-r335317 download image). I wouldn't describe the RPI3 as being flaky (hardware-wise, *), and I'd say that 12 has been pretty good for being "current" (vs stable). I expect to follow 12-current down into stable and then release as that process starts over the next few months, so I expect any transient OS flakeyness to get better. And I'm not using any hats. Yet, at least. So pretty stock setup, with the exception of ZFS root and real swap partition. *: I've been experimenting with ZFS and compiling kernels on it for stress- testing, so I've had a fan aimed at it to try and reduce any thermal throttling. From owner-freebsd-arm@freebsd.org Sun Jul 29 14:28:57 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B353310581C1 for ; Sun, 29 Jul 2018 14:28:57 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BA22828DD for ; Sun, 29 Jul 2018 14:28:57 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1532874535; bh=QsUuKNLPFAvJFupyBgp0PC2FfsvB0VSwt0slj6k2Wf8=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=vkr6nR7sAWAbo6JvMA/OcFRFKgi7AKIY2GDgtRlBbqJuRVf/nxSfUVRpeHGIaOusg yzw+9ILj/Ti61a9iUxgEjDbXpN1/M7JYeJ3BqIJFjZgNK8h5YY9hZY3PrkPQ3C6JBZ hE2inx01gF/cpYXlB2RE4Pb2uUdrH2xyC/FCPPQA= Subject: Re: rpi3 and Adafruit GPS hat continued To: John Kennedy Cc: Ralph Smith , freebsd-arm References: <2f55aaea-6832-7441-1011-b8288628a4a9@nethead.se> <2aee4fd4-c221-23a6-00e4-1db2694bfef6@nethead.se> <6DCECF08-1366-4289-9929-94A967284291@ralphsmith.org> <20180729134340.GH75644@phouka1.phouka.net> From: Per olof Ljungmark Message-ID: <2a0c3063-d1d3-00c5-ee59-0a78ca0aaad4@nethead.se> Date: Sun, 29 Jul 2018 16:28:53 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180729134340.GH75644@phouka1.phouka.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 14:28:57 -0000 On 07/29/18 15:43, John Kennedy wrote: > On Sun, Jul 29, 2018 at 01:29:17PM +0200, Per olof Ljungmark wrote: >> Just FYI, I have the hat working now on the rpi2 v1.1 with 11-STABLE and >> about to learn how to use the rpi3+current with the hat as well. >> >> One thing I have realised is the the pi's can be a bit flaky, perhaps >> you could recommend some other single board cpu that works with FreeBSD >> 12? Like the rpi3 or even better spec. > > I gave the RPI2* a miss, but I've been running my RPI3B+ on 12 since ~June 22nd > (starting with the -RPI3-20180618-r335317 download image). I wouldn't describe > the RPI3 as being flaky (hardware-wise, *), and I'd say that 12 has been pretty > good for being "current" (vs stable). > > I expect to follow 12-current down into stable and then release as that process > starts over the next few months, so I expect any transient OS flakeyness to get > better. > > And I'm not using any hats. Yet, at least. So pretty stock setup, with the > exception of ZFS root and real swap partition. > > *: I've been experimenting with ZFS and compiling kernels on it for stress- > testing, so I've had a fan aimed at it to try and reduce any thermal > throttling. > Nice to hear! The flakiness I have seen is mainly with the USB subsystem, for example every other time the RPI3B here loads u-boot it detects 3 devices, and the next 4 devices, this is from cold start without any soft- or hardware changes. Another issue I've seen is file system corruption but of course this is current and I do not expect everything to be top notch. Flaky or not, would be nice to try another arm or arm64 platform just to learn, preferably one of the bigger ones, already got an Orange Pi R1 to delv into now. Cheers, From owner-freebsd-arm@freebsd.org Sun Jul 29 14:35:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F38D91058446 for ; Sun, 29 Jul 2018 14:35:48 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 7010982C0A for ; Sun, 29 Jul 2018 14:35:48 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: ad5a333f-933c-11e8-904b-1d2e466b3c59 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id ad5a333f-933c-11e8-904b-1d2e466b3c59; Sun, 29 Jul 2018 14:35:45 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w6TEZiDQ029467; Sun, 29 Jul 2018 08:35:44 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1532874944.61594.110.camel@freebsd.org> Subject: Re: sx_sleep not waking up when timo expires From: Ian Lepore To: John-Mark Gurney , freebsd-arm@FreeBSD.org Date: Sun, 29 Jul 2018 08:35:44 -0600 In-Reply-To: <20180729010157.GC2884@funkthat.com> References: <20180729010157.GC2884@funkthat.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 14:35:49 -0000 On Sat, 2018-07-28 at 18:01 -0700, John-Mark Gurney wrote: > I recently upgraded my router to an Pine A64-LTS board, and have hit > the same issue as PR 222126[1].  The solution at the end does not work > for me, as I do not have that line in my loader.conf: > kern.timecounter.smp_tsc_adjust=1 > > I have verified that the wake up does not happen, as I used a dtrace > script to verify that pf_purge_expired_states is called or not called.. > When I change the timeout, pf will kick the thread and get things > running again, but it has stopped a couple times later... > > I'm running a recent SNAPSHOT: > FreeBSD gate2.funkthat.com 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r336134: Mon Jul  9 19:20:11 UTC 2018     root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 > > This is likely reproducable by just starting pf, even in a pass all > mode, and watching for when the function stops getting called...  I'll > see if I can't get an extermely minimal config to reproduce it. > > Any suggestions? > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126 > Sounds like https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229644  which has some patches attached which reduce but don't quite eliminate the occurrances, so nothing has been committed yet. I just ordered a SOPINE board so I can do some hands-on debugging. -- Ian From owner-freebsd-arm@freebsd.org Sun Jul 29 14:40:54 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94C7A1058552 for ; Sun, 29 Jul 2018 14:40:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 1095E82D0A for ; Sun, 29 Jul 2018 14:40:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1fjmsG-000BG9-5b; Sun, 29 Jul 2018 17:40:44 +0300 From: Daniel Braniss Message-Id: <1F3C1A04-C385-4A84-9208-2A2C451BEDCE@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: rpi3 and Adafruit GPS hat continued Date: Sun, 29 Jul 2018 17:40:43 +0300 In-Reply-To: <2a0c3063-d1d3-00c5-ee59-0a78ca0aaad4@nethead.se> Cc: John Kennedy , freebsd-arm To: Per olof Ljungmark References: <2f55aaea-6832-7441-1011-b8288628a4a9@nethead.se> <2aee4fd4-c221-23a6-00e4-1db2694bfef6@nethead.se> <6DCECF08-1366-4289-9929-94A967284291@ralphsmith.org> <20180729134340.GH75644@phouka1.phouka.net> <2a0c3063-d1d3-00c5-ee59-0a78ca0aaad4@nethead.se> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 14:40:54 -0000 > On 29 Jul 2018, at 17:28, Per olof Ljungmark wrote: >=20 > On 07/29/18 15:43, John Kennedy wrote: >> On Sun, Jul 29, 2018 at 01:29:17PM +0200, Per olof Ljungmark wrote: >>> Just FYI, I have the hat working now on the rpi2 v1.1 with 11-STABLE = and >>> about to learn how to use the rpi3+current with the hat as well. >>>=20 >>> One thing I have realised is the the pi's can be a bit flaky, = perhaps >>> you could recommend some other single board cpu that works with = FreeBSD >>> 12? Like the rpi3 or even better spec. >>=20 >> I gave the RPI2* a miss, but I've been running my RPI3B+ on 12 since = ~June 22nd >> (starting with the -RPI3-20180618-r335317 download image). I = wouldn't describe >> the RPI3 as being flaky (hardware-wise, *), and I'd say that 12 has = been pretty >> good for being "current" (vs stable). >>=20 >> I expect to follow 12-current down into stable and then release as = that process >> starts over the next few months, so I expect any transient OS = flakeyness to get >> better. >>=20 >> And I'm not using any hats. Yet, at least. So pretty stock setup, = with the >> exception of ZFS root and real swap partition. >>=20 >> *: I've been experimenting with ZFS and compiling kernels = on it for stress- >> testing, so I've had a fan aimed at it to try and reduce any = thermal >> throttling. >>=20 >=20 > Nice to hear! The flakiness I have seen is mainly with the USB > subsystem, for example every other time the RPI3B here loads u-boot it > detects 3 devices, and the next 4 devices, this is from cold start > without any soft- or hardware changes. >=20 > Another issue I've seen is file system corruption but of course this = is > current and I do not expect everything to be top notch. >=20 > Flaky or not, would be nice to try another arm or arm64 platform just = to > learn, preferably one of the bigger ones, already got an Orange Pi R1 = to > delv into now. >=20 i=E2=80=99m using nanopi-neo from Friendlyarm, it=E2=80=99s a bit = challenging to get all the pieces to work (boot et.all.) but it=E2=80=99s cheep and so far I only burned = one :-) can provide help if you want. danny > Cheers, > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Sun Jul 29 14:44:10 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 448681058AF5 for ; Sun, 29 Jul 2018 14:44:10 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 BB18A830F9 for ; Sun, 29 Jul 2018 14:44:09 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: d7ce32e4-933d-11e8-904b-1d2e466b3c59 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id d7ce32e4-933d-11e8-904b-1d2e466b3c59; Sun, 29 Jul 2018 14:44:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w6TEi52G029483; Sun, 29 Jul 2018 08:44:05 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1532875445.61594.113.camel@freebsd.org> Subject: Re: Allwinner dtb overlays on CURRENT. Also, flashrom SPI! From: Ian Lepore To: Greg V , freebsd-arm@freebsd.org Date: Sun, 29 Jul 2018 08:44:05 -0600 In-Reply-To: <1532548163.59286.0@hraggstad.unrelenting.technology> References: <1532548163.59286.0@hraggstad.unrelenting.technology> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 14:44:10 -0000 On Wed, 2018-07-25 at 22:49 +0300, Greg V wrote: > Hi, > > One thing I have noticed with CURRENT on an Orange Pi PC: since we're  > using device trees imported from Linux, some drivers are not accessible  > out of the box. > > So I wrote a couple overlays: > > Thermal sensor: https://github.com/freebsd/freebsd/pull/162 > > SPI: https://github.com/freebsd/freebsd/pull/166 > > But not everyone would figure out how to make and even just use  > overlays… > > (if anyone is wondering: place them into /boot/dtb/overlays and add a  > list of them (filenames including extension) to /boot/loader.conf like  > so: fdt_overlays="sun8i-h3-sid.dtbo,sun8i-h3-ts.dtbo,sun8i-h3-spi.dtbo"  > — and reboot) > > Can someone commit these overlays / add more for other SoCs maybe? > > P.S. I also wrote spigen support for flashrom:  > https://github.com/flashrom/flashrom/pull/53 > With this, I can flash and verify a Winbond W25Q32.V flash chip from my  > Orange Pi! :) Why in the world would you use spigen instead of the normal mx25l spiflash driver and a simple dd to/from /dev/flash/spiN ?   Hrm. Maybe because mx25l, and most SPI-related stuff, isn't documented. My to-do list knows no bounds. -- Ian From owner-freebsd-arm@freebsd.org Sun Jul 29 14:47:53 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96B1F1058C70 for ; Sun, 29 Jul 2018 14:47:53 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from hraggstad.unrelenting.technology (hraggstad.unrelenting.technology [71.19.146.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hraggstad.unrelenting.technology", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF5D1831C6; Sun, 29 Jul 2018 14:47:52 +0000 (UTC) (envelope-from greg@unrelenting.technology) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unrelenting.technology; h=date:from:subject:to:message-id; s=default; bh=Cp7vQ2DT/UFMxc6XyTkGG9DflrAAbSCjuo0dBbeVraI=; b=fVvERCBBU+90KZ4G1msB45fpPin6XLFcTZxHSdVjjVn/2grTiIhTuVDQNkeLSYMVf/dERf6FTmlbRZaFZO32Hn0MF4JN2qf4oKa2vW+7RZUpyP52MToNSfLs9x8CTVb/p9a64nJJq8DSo0ifW3KZuvUj5h95LY2FRar+pmY9OHM= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id 7971d846 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 29 Jul 2018 14:47:37 +0000 (UTC) Date: Sun, 29 Jul 2018 17:47:32 +0300 From: Greg V Subject: Re: Allwinner dtb overlays on CURRENT. Also, flashrom SPI! To: Ian Lepore Cc: freebsd-arm@freebsd.org Message-Id: <1532875652.1648.1@hraggstad.unrelenting.technology> In-Reply-To: <1532875445.61594.113.camel@freebsd.org> References: <1532548163.59286.0@hraggstad.unrelenting.technology> <1532875445.61594.113.camel@freebsd.org> X-Mailer: geary/0.12.2 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 14:47:53 -0000 On Sun, Jul 29, 2018 at 5:44 PM, Ian Lepore wrote: > On Wed, 2018-07-25 at 22:49 +0300, Greg V wrote: >> Hi, >>=20 >> One thing I have noticed with CURRENT on an Orange Pi PC: since=20 >> we're >> using device trees imported from Linux, some drivers are not=20 >> accessible >> out of the box. >>=20 >> So I wrote a couple overlays: >>=20 >> Thermal sensor: https://github.com/freebsd/freebsd/pull/162 >>=20 >> SPI: https://github.com/freebsd/freebsd/pull/166 >>=20 >> But not everyone would figure out how to make and even just use >> overlays=85 >>=20 >> (if anyone is wondering: place them into /boot/dtb/overlays and add=20 >> a >> list of them (filenames including extension) to /boot/loader.conf=20 >> like >> so:=20 >> fdt_overlays=3D"sun8i-h3-sid.dtbo,sun8i-h3-ts.dtbo,sun8i-h3-spi.dtbo" >> =97 and reboot) >>=20 >> Can someone commit these overlays / add more for other SoCs maybe? >>=20 >> P.S. I also wrote spigen support for flashrom: >> https://github.com/flashrom/flashrom/pull/53 >> With this, I can flash and verify a Winbond W25Q32.V flash chip=20 >> from my >> Orange Pi! :) >=20 > Why in the world would you use spigen instead of the normal mx25l > spiflash driver and a simple dd to/from /dev/flash/spiN ? >=20 > Hrm. Maybe because mx25l, and most SPI-related stuff, isn't=20 > documented. > My to-do list knows no bounds. Yeah, because of that too :) but also (as I mentioned below in the thread): flashrom has chip autodetection, support for more chips, it's easy to=20 adjust speed (it's right in the command)=85 also it's just *popular*, people know *flashrom specifically* = From owner-freebsd-arm@freebsd.org Sun Jul 29 15:41:52 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB3E51059BCC for ; Sun, 29 Jul 2018 15:41:52 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E61484877 for ; Sun, 29 Jul 2018 15:41:52 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w6TFeYDF028780 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 29 Jul 2018 08:40:34 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w6TFeXqB028779; Sun, 29 Jul 2018 08:40:33 -0700 (PDT) (envelope-from warlock) Date: Sun, 29 Jul 2018 08:40:33 -0700 From: John Kennedy To: Per olof Ljungmark Cc: freebsd-arm Subject: Re: rpi3 and Adafruit GPS hat continued Message-ID: <20180729154033.GI75644@phouka1.phouka.net> References: <2f55aaea-6832-7441-1011-b8288628a4a9@nethead.se> <2aee4fd4-c221-23a6-00e4-1db2694bfef6@nethead.se> <6DCECF08-1366-4289-9929-94A967284291@ralphsmith.org> <20180729134340.GH75644@phouka1.phouka.net> <2a0c3063-d1d3-00c5-ee59-0a78ca0aaad4@nethead.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a0c3063-d1d3-00c5-ee59-0a78ca0aaad4@nethead.se> User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 15:41:53 -0000 On Sun, Jul 29, 2018 at 04:28:53PM +0200, Per olof Ljungmark wrote: > Nice to hear! The flakiness I have seen is mainly with the USB > subsystem, for example every other time the RPI3B here loads u-boot it > detects 3 devices, and the next 4 devices, this is from cold start > without any soft- or hardware changes. Hmm. So for a while, experimenting with ZFS, I was trying to boot off of USB. In my case, that was a DYNEX DX-C112 SD/microSD memory card reader with the SD card I might have otherwise plugged into the front inserted. I was juggling multiple variables at the time (not that I knew them all at that instant), but it never failed to boot past u-boot (to be clear in my mind, into the software loaded into the msdosfs partition). However, I think I only every had one bootable "disk" device in there on startup, so probably much simpler than your setup. My usual device list looks like this with nothing plugged in except for the wireless USB-keyboard receiver: # usbconfig list ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (98mA) > Another issue I've seen is file system corruption but of course this is > current and I do not expect everything to be top notch. I have not seen corruption. I've got two SanDisk Extreme PLUS 64GiB SD cards (V30 rated) that were new (now only ~1 month old) that I flip-flop between as I experiment. With ZFS, I'd expect that to show up fairly easily as the OS detected it. I was doing a lot of UFS until I got ZFS running. I wasn't experiencing uncontrolled crashes or reboots and I spent most of my time up until recently running off of the RE images (I'm not sure what extra QA value those have). I've been rebuilding FreeBSD as my stress-test. Mostly with /usr/src and /usr/obj NFS-mounted on there, but with ethernet on the USB bus I'm not sure that it matters as much for beating up the I/O subsystem. I've certainly got the gut feeling that slow USB/SD I/O can back up the OS in unexpected ways that fast I/O won't (which manifests as hangs and timeouts, and if you reboot then maybe corruption). I'm also more concerned about write-I/O wear on this tiny SD (or USB), since it's so tiny and really isn't bragging about wear- leveling. In other words, I'm wondering when I'll start to experience media failure corruption that has nothing to do with the OS. > Flaky or not, would be nice to try another arm or arm64 platform just to > learn, preferably one of the bigger ones, already got an Orange Pi R1 to > delv into now. If I wasn't specifically interested in the RPI, I'd be in the same situation. I'm totally spoiled by the speed of my amd64 system though, plus the graphics I can attach to it. From owner-freebsd-arm@freebsd.org Sun Jul 29 21:01:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8033A1063630 for ; Sun, 29 Jul 2018 21:01:07 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA82E79DA0 for ; Sun, 29 Jul 2018 21:01:06 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 24B5019EB0 for ; Sun, 29 Jul 2018 21:01:06 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6TL16TG084218 for ; Sun, 29 Jul 2018 21:01:06 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6TL16Gd084214 for freebsd-arm@FreeBSD.org; Sun, 29 Jul 2018 21:01:06 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201807292101.w6TL16Gd084214@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 29 Jul 2018 21:01:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 21:01:07 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 220297 | arch(7) rename arm64 to aarch64 respecting `uname 1 problems total for which you should take action. From owner-freebsd-arm@freebsd.org Mon Jul 30 04:42:06 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52CED1049EA1 for ; Mon, 30 Jul 2018 04:42:06 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA4CF87428; Mon, 30 Jul 2018 04:42:05 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w6U4fv3h071204 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 29 Jul 2018 21:41:57 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w6U4fvHW071203; Sun, 29 Jul 2018 21:41:57 -0700 (PDT) (envelope-from jmg) Date: Sun, 29 Jul 2018 21:41:57 -0700 From: John-Mark Gurney To: Ian Lepore Cc: freebsd-arm@FreeBSD.org Subject: Re: sx_sleep not waking up when timo expires Message-ID: <20180730044157.GF2884@funkthat.com> Mail-Followup-To: Ian Lepore , freebsd-arm@FreeBSD.org References: <20180729010157.GC2884@funkthat.com> <1532874944.61594.110.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1532874944.61594.110.camel@freebsd.org> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sun, 29 Jul 2018 21:41:57 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 04:42:06 -0000 Ian Lepore wrote this message on Sun, Jul 29, 2018 at 08:35 -0600: > On Sat, 2018-07-28 at 18:01 -0700, John-Mark Gurney wrote: > > I recently upgraded my router to an Pine A64-LTS board, and have hit > > the same issue as PR 222126[1].  The solution at the end does not work > > for me, as I do not have that line in my loader.conf: > > kern.timecounter.smp_tsc_adjust=1 > > > > I have verified that the wake up does not happen, as I used a dtrace > > script to verify that pf_purge_expired_states is called or not called.. > > When I change the timeout, pf will kick the thread and get things > > running again, but it has stopped a couple times later... > > > > I'm running a recent SNAPSHOT: > > FreeBSD gate2.funkthat.com 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r336134: Mon Jul  9 19:20:11 UTC 2018     root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 > > > > This is likely reproducable by just starting pf, even in a pass all > > mode, and watching for when the function stops getting called...  I'll > > see if I can't get an extermely minimal config to reproduce it. > > > > Any suggestions? > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126 > > > > Sounds like > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229644  > > which has some patches attached which reduce but don't quite eliminate > the occurrances, so nothing has been committed yet. I just ordered a > SOPINE board so I can do some hands-on debugging. Hmm... The interesting part is that I haven't seen ANY timer stability issues though... ntpd is still running w/o troubles... Only ntpd logs I have are leap second file related: Jul 28 22:36:56 gate2 ntpd[869]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): expired less than 214 days ago -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Mon Jul 30 05:00:32 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B785A104A278 for ; Mon, 30 Jul 2018 05:00:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A89188190 for ; Mon, 30 Jul 2018 05:00:32 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 760eda8f-93b5-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 760eda8f-93b5-11e8-aff6-0b9b8210da61; Mon, 30 Jul 2018 05:00:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w6U50KmR031141; Sun, 29 Jul 2018 23:00:20 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1532926820.84297.1.camel@freebsd.org> Subject: Re: sx_sleep not waking up when timo expires From: Ian Lepore To: John-Mark Gurney Cc: freebsd-arm@FreeBSD.org Date: Sun, 29 Jul 2018 23:00:20 -0600 In-Reply-To: <20180730044157.GF2884@funkthat.com> References: <20180729010157.GC2884@funkthat.com> <1532874944.61594.110.camel@freebsd.org> <20180730044157.GF2884@funkthat.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 05:00:32 -0000 On Sun, 2018-07-29 at 21:41 -0700, John-Mark Gurney wrote: > Ian Lepore wrote this message on Sun, Jul 29, 2018 at 08:35 -0600: > > > > On Sat, 2018-07-28 at 18:01 -0700, John-Mark Gurney wrote: > > > > > > I recently upgraded my router to an Pine A64-LTS board, and have > > > hit > > > the same issue as PR 222126[1].  The solution at the end does not > > > work > > > for me, as I do not have that line in my loader.conf: > > > kern.timecounter.smp_tsc_adjust=1 > > > > > > I have verified that the wake up does not happen, as I used a > > > dtrace > > > script to verify that pf_purge_expired_states is called or not > > > called.. > > > When I change the timeout, pf will kick the thread and get things > > > running again, but it has stopped a couple times later... > > > > > > I'm running a recent SNAPSHOT: > > > FreeBSD gate2.funkthat.com 12.0-CURRENT FreeBSD 12.0-CURRENT #0 > > > r336134: Mon Jul  9 19:20:11 UTC 2018     root@releng3.nyi.freebs > > > d.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 > > > > > > This is likely reproducable by just starting pf, even in a pass > > > all > > > mode, and watching for when the function stops getting > > > called...  I'll > > > see if I can't get an extermely minimal config to reproduce it. > > > > > > Any suggestions? > > > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126 > > > > > Sounds like > > > >  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229644  > > > > which has some patches attached which reduce but don't quite > > eliminate > > the occurrances, so nothing has been committed yet. I just ordered > > a > > SOPINE board so I can do some hands-on debugging. > Hmm... The interesting part is that I haven't seen ANY timer > stability > issues though...  ntpd is still running w/o troubles... Only ntpd > logs I have are leap second file related: > Jul 28 22:36:56 gate2 ntpd[869]: leapsecond file ('/var/db/ntpd.leap- > seconds.list'): expired less than 214 days ago > ntpd is just a visible victim of the root problem. You found the problem more directly with dtrace. The patches in that PR fix the eventtimer, not the timecounter; give it a try. -- Ian From owner-freebsd-arm@freebsd.org Mon Jul 30 18:20:25 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7BB8105D5E2 for ; Mon, 30 Jul 2018 18:20:24 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 417C17DF73 for ; Mon, 30 Jul 2018 18:20:23 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1532974821; s=strato-dkim-0002; d=ulrich-grey.de; h=Message-Id:Subject:To:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH:From: Subject:Sender; bh=MJDZXLMe4v7uhC370Sfl2TBbNm1ashkr9gkre5uu6Mc=; b=OrFc1AUrB9GHH64WF9zqLpHi+EqfZuhvSd3c5eJh3Hrhb8b/qdoG+UM3rsVHWTH3pI QpwEeWjJweonjJM+DANf7LlZQi0fn/aiREdG+V59sDtkNIpf+jUanPz1mPBPvTsZDJdZ 2MekhLfsvCaG7JwDWn60uKdPvz3G/taUiUNu7EaaL7jKC+6qfZcOEllHS4UC7SysoWiA X9qA9LtF9kKpz2dBLd30nXJrV/GW/pgri3YqAFj55zqe94AQOHH+gsOEN8WzJAwwL4iW 1aXIfMTdldG3P99fn6lnQHtdIfrIliQopDMSnNQGkosytdWvSTVh3GZCznzyY94DcrVx n+Xg== X-RZG-AUTH: ":OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhPcwkcojh9vB3Wa1dWT+c76f0FX5V4KGCpMzTV5pug==" X-RZG-CLASS-ID: mo00 Received: from ap-fbsd by smtp.strato.de (RZmta 43.13 DYNA|AUTH) with ESMTPSA id L072e4u6UIKL9Jh (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Mon, 30 Jul 2018 20:20:21 +0200 (CEST) Date: Mon, 30 Jul 2018 20:20:20 +0200 From: Ulrich Grey To: freebsd-arm@freebsd.org Subject: Booting PINE64-LTS does not work Message-Id: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; i386-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 18:20:25 -0000 I have built an image FreeBSD 12.0-CURRENT #0 r336877 for the PINE64-LTS board, using the crochet fork from Curtis Villamizar: https://github.com/CurtisVillamizar/crochet I had to add user ntpd to my FreeBSD 11.1-RELEASE #0 r321309 amd64 system to create the image. If I try to boot the board, I get this: ## Script started on Sun Oct 30 14:20:25 2016 root@xterminal:~ # cu -l /dev/cuaU0 -s 115200 Connected ## U-Boot SPL 2018.03 (Jul 29 2018 - 16:19:12 +0000) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2018.03 (Jul 29 2018 - 16:19:12 +0000) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: Pine64+ DRAM: 2 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from FAT... Card did not respond to voltage select! ** Bad device mmc 1 ** Failed (-5) Loading Environment from MMC... Card did not respond to voltage select! *** Warning - MMC init failed, using default environment Failed (-5) In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@01c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 2 ### 1 ### 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disks on usb... Disk usb0 not ready Disk usb1 not ready Disk usb2 not ready Disk usb3 not ready Scanning disks on mmc... Card did not respond to voltage select! MMC Device 2 not found MMC Device 3 not found Found 3 disks 84296 bytes read in 34 ms (2.4 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 40080000 ... #[?25h#[2J >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Load Path: /\efi\boot\bootaa64.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD (1,0x01,0,0x403b,0x1ffe0) Probing 3 block devices.....* done ZFS found no pools UFS found 1 partition #[?25h#[18tConsoles: EFI console #[?25h|#/#FreeBSD/arm64 EFI loader, Revision 1.1 (Mon Jul 30 02:26:18 CEST 2018 root@noname.privat) Command line arguments: loader.efi EFI version: 2.70 EFI Firmware: Das U-Boot (rev 0.00) Console: efi (0) Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD (2,0x01,0,0x24400,0x71f400) Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD (2,0x01,0,0x24400,0x71f400) Setting currdev to disk0p2: -#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-# \#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#| #Loading /boot/defaults/loader.conf /#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#| #/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#| ##/#-#\#|#/#/boot/kernel/kernel text=0x8b1df2 -#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-# ##\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-# ##\#|#/#-#\#|#data=0x13f1d0+0x7d397c /#-#\#|#/#-#\#|#/#-#syms=[0x8+0x11cac0\#|#/#-#\#| ###/#-#\#+0x8+0x10d3f1|#/#-#\#|#/#-#\#|#] /#-#\#|#/#-#\#|#/#-#\#|#efi-autoresizecons: Neither Graphics Output Protocol nor Universal Graphics Adapter present Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Booting [/boot/kernel/kernel] in 8 seconds... Booting [/boot/kernel/kernel] in 7 seconds... Booting [/boot/kernel/kernel] in 6 seconds... Booting [/boot/kernel/kernel] in 5 seconds... Booting [/boot/kernel/kernel] in 4 seconds... Booting [/boot/kernel/kernel] in 3 seconds... Booting [/boot/kernel/kernel] in 2 seconds... Booting [/boot/kernel/kernel] in 1 second... Booting [/boot/kernel/kernel]... /#-#\#|#/#-#\#|#/#-#\#|#Using DTB provided by EFI at 0x48000000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 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 12.0-CURRENT #0 r336877: Mon Jul 30 02:25:51 CEST 2018 root@noname.privat:/usr/home/CROCHET/test/crochet.git/branches/pine64-lts/work/obj/usr/home/CROCHET/SRC/head/arm64.aarch64/sys/GENERIC arm64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: no preloaded entropy cache random: entropy device external interface MAP 48000000 mode 2 pages 4 MAP b8f25000 mode 2 pages 1 MAP bdfbb000 mode 2 pages 1 kbd0 at kbdmux0 ofwbus0: clk_fixed0: on ofwbus0 clk_fixed1: on ofwbus0 clk_fixed2: on ofwbus0 simplebus0: on ofwbus0 ccu_a64ng0: mem 0x1c20000-0x1c203ff on simplebus0 iichb0: mem 0x1c2b000-0x1c2b3ff irq 21 on simplebus0 iicbus0: on iichb0 regfix0: on ofwbus0 ccu_sun8i_r0: mem 0x1f01400-0x1f014ff on simplebus0 psci0: on ofwbus0 gic0: mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 23 on simplebus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 gpio0: mem 0x1c20800-0x1c20bff irq 12,13,14 on simplebus0 gpiobus0: on gpio0 gpio1: mem 0x1f02c00-0x1f02fff irq 26 on simplebus0 gpiobus1: on gpio1 generic_timer0: irq 0,1,2,3 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 rtc0: mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0 rtc0: registered as a time-of-day clock, resolution 1.000000s awusbphy0: mem 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0 cpulist0: on ofwbus0 cpu0: on cpulist0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 aw_mmc0: mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0 mmc0: on aw_mmc0 ehci0: mem 0x1c1b000-0x1c1b0ff irq 10 on simplebus0 usbus0: EHCI version 1.0 usbus0 on ehci0 ohci0: mem 0x1c1b400-0x1c1b4ff irq 11 on simplebus0 usbus1 on ohci0 gpioc0: on gpio0 uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on simplebus0 uart0: console (115384,n,8,1) iic0: on iicbus0 gpioc1: on gpio1 awg0: mem 0x1c30000-0x1c31fff,0x1c00030-0x1c00033 irq 27 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-FDX-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-FDX-flow-master, auto, auto-flow awg0: Ethernet address: 02:ba:87:48:13:ae cryptosoft0: Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 mmcsd0: 16GB at mmc0 50.0MHz/4bit/32768-block Release APs...arc4random: no preloaded entropy cache mmc0: done ACMD42 failed, RESULT: 4 CPU 0: ARM Cortex-A53 r0p4mmc0: affinity:Card at relative address 43690 failed to set bus width 0 Instruction Set Attributes 0 = Instruction Set Attributes 1 = <> Processor Features 0 = Processor Features 1 = <0> Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 = <> Memory Model Features 2 = <32b CCIDX,48b VA> Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8> Debug Features 1 = <0> Auxiliary Features 0 = <0> Auxiliary Features 1 = <0> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus1 usbus0 uhub1: 1 port with 1 removable, self powered uhub0: 1 port with 1 removable, self powered Loader variables: Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> random: unblocking device. arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache panic: mountroot: unable to (re-)mount root. cpuid = 2 time = 167 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0xffff000000688e14 lr = 0xffff0000000dad40 sp = 0xffff00005891d590 fp = 0xffff00005891d7a0 db_trace_self_wrapper() at vpanic+0x1a8 pc = 0xffff0000000dad40 lr = 0xffff000000388c98 sp = 0xffff00005891d7b0 fp = 0xffff00005891d860 vpanic() at panic+0x44 pc = 0xffff000000388c98 lr = 0xffff000000388d48 sp = 0xffff00005891d870 fp = 0xffff00005891d8f0 panic() at vfs_mountroot+0x1610 pc = 0xffff000000388d48 lr = 0xffff00000044d1c8 sp = 0xffff00005891d900 fp = 0xffff00005891dab0 vfs_mountroot() at start_init+0x28 pc = 0xffff00000044d1c8 lr = 0xffff000000321ee4 sp = 0xffff00005891dac0 fp = 0xffff00005891db50 start_init() at fork_exit+0x7c pc = 0xffff000000321ee4 lr = 0xffff000000349fa4 sp = 0xffff00005891db60 fp = 0xffff00005891db90 fork_exit() at fork_trampoline+0x10 pc = 0xffff000000349fa4 lr = 0xffff0000006a4cdc sp = 0xffff00005891dba0 fp = 0x0000000000000000 KDB: enter: panic [ thread pid 1 tid 100002 ] Stopped at 0 db> root@xterminal:~ # From owner-freebsd-arm@freebsd.org Mon Jul 30 18:32:08 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92077105DB81 for ; Mon, 30 Jul 2018 18:32:08 +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 153C07EA98 for ; Mon, 30 Jul 2018 18:32:07 +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 735b8a75; Mon, 30 Jul 2018 20:32:00 +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=XSiviyMfGWi4UJ4IbY+QPEYYX3Y=; b=I8MjKRShrrNRJ1071gAim9sexzYM 4lFS734Vyfl8h51dpXedQMzHa9QUekKcuxGkjR7hQZ/pkE9VcKIWnEssUbGMdPdO vEDiKmDlRdcfGkqYApYbdjm9+WIFJuWB7LEE0Dbb9a+hjyienxOgiDqoC+oHar+6 FNzMSJ0Qj0gVhiM= 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=ZTRzeWSimOb3JW3ANGQ7TymrbMHhyNwaczAcbeKSclJdxhGSNH6jPOK5 97zuZH/w7Fw6utlMqiNHyaTNf+gl9nAnGpbTekcd2e0Fzc8tL6JbTl3VATYlQemf bqgQXBgCupm2Sb3LqWekZYyEP0lynYxCzKz523/9rP0Fzq+EbXY= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id ff2c1159 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 30 Jul 2018 20:31:59 +0200 (CEST) Date: Mon, 30 Jul 2018 20:31:59 +0200 From: Emmanuel Vadot To: Ulrich Grey Cc: freebsd-arm@freebsd.org Subject: Re: Booting PINE64-LTS does not work Message-Id: <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> In-Reply-To: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> References: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 18:32:08 -0000 On Mon, 30 Jul 2018 20:20:20 +0200 Ulrich Grey wrote: > I have built an image > > FreeBSD 12.0-CURRENT #0 r336877 > > for the PINE64-LTS board, > > using the crochet fork from Curtis Villamizar: > https://github.com/CurtisVillamizar/crochet God we really have to kill crochet. Now people are making forks ... > I had to add user ntpd to my FreeBSD 11.1-RELEASE #0 r321309 amd64 system > to create the image. > > If I try to boot the board, I get this: > ## > > Script started on Sun Oct 30 14:20:25 2016 > root@xterminal:~ # cu -l /dev/cuaU0 -s 115200 > Connected > ## > U-Boot SPL 2018.03 (Jul 29 2018 - 16:19:12 +0000) > DRAM: 2048 MiB > Trying to boot from MMC1 > > > U-Boot 2018.03 (Jul 29 2018 - 16:19:12 +0000) Allwinner Technology U-Boot should be 2018.07 > CPU: Allwinner A64 (SUN50I) > Model: Pine64+ > DRAM: 2 GiB > MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 > Loading Environment from FAT... Card did not respond to voltage select! > ** Bad device mmc 1 ** > Failed (-5) > Loading Environment from MMC... Card did not respond to voltage select! > *** Warning - MMC init failed, using default environment > > Failed (-5) > In: serial > Out: serial > Err: serial > Net: phy interface7 > eth0: ethernet@01c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 2 ### 1 ### 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Scanning disks on usb... > Disk usb0 not ready > Disk usb1 not ready > Disk usb2 not ready > Disk usb3 not ready > Scanning disks on mmc... > Card did not respond to voltage select! > MMC Device 2 not found > MMC Device 3 not found > Found 3 disks > 84296 bytes read in 34 ms (2.4 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > ## Starting EFI application at 40080000 ... > #[?25h#[2J > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi > > Initializing modules: ZFS UFS > Load Path: /\efi\boot\bootaa64.efi > Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD > (1,0x01,0,0x403b,0x1ffe0) > Probing 3 block devices.....* done > ZFS found no pools > UFS found 1 partition > #[?25h#[18tConsoles: EFI console > #[?25h|#/#FreeBSD/arm64 EFI loader, Revision 1.1 > (Mon Jul 30 02:26:18 CEST 2018 root@noname.privat) > > Command line arguments: loader.efi > EFI version: 2.70 > EFI Firmware: Das U-Boot (rev 0.00) > Console: efi (0) > Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD > (2,0x01,0,0x24400,0x71f400) > Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD > (2,0x01,0,0x24400,0x71f400) > Setting currdev to disk0p2: > -#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-# > \#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#| > #Loading /boot/defaults/loader.conf > /#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#| > #/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#| > ##/#-#\#|#/#/boot/kernel/kernel text=0x8b1df2 -#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-# > ##\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-#\#|#/#-# > ##\#|#/#-#\#|#data=0x13f1d0+0x7d397c /#-#\#|#/#-#\#|#/#-#syms=[0x8+0x11cac0\#|#/#-#\#| > ###/#-#\#+0x8+0x10d3f1|#/#-#\#|#/#-#\#|#] > /#-#\#|#/#-#\#|#/#-#\#|#efi-autoresizecons: Neither Graphics Output Protocol nor > Universal Graphics Adapter present > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel] in 9 seconds... Booting [/boot/kernel/kernel] in 8 seconds... Booting [/boot/kernel/kernel] in 7 seconds... Booting [/boot/kernel/kernel] in 6 seconds... Booting [/boot/kernel/kernel] in 5 seconds... Booting [/boot/kernel/kernel] in 4 seconds... Booting [/boot/kernel/kernel] in 3 seconds... Booting [/boot/kernel/kernel] in 2 seconds... Booting [/boot/kernel/kernel] in 1 second... Booting [/boot/kernel/kernel]... > /#-#\#|#/#-#\#|#/#-#\#|#Using DTB provided by EFI at 0x48000000. > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2018 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 12.0-CURRENT #0 r336877: Mon Jul 30 02:25:51 CEST 2018 > root@noname.privat:/usr/home/CROCHET/test/crochet.git/branches/pine64-lts/work/obj/usr/home/CROCHET/SRC/head/arm64.aarch64/sys/GENERIC > arm64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > VT: init without driver. > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > arc4random: no preloaded entropy cache > random: entropy device external interface > MAP 48000000 mode 2 pages 4 > MAP b8f25000 mode 2 pages 1 > MAP bdfbb000 mode 2 pages 1 > kbd0 at kbdmux0 > ofwbus0: > clk_fixed0: on ofwbus0 > clk_fixed1: on ofwbus0 > clk_fixed2: on ofwbus0 > simplebus0: on ofwbus0 > ccu_a64ng0: mem 0x1c20000-0x1c203ff on simplebus0 > iichb0: mem 0x1c2b000-0x1c2b3ff irq 21 on > simplebus0 iicbus0: on iichb0 > regfix0: on ofwbus0 > ccu_sun8i_r0: mem 0x1f01400-0x1f014ff on > simplebus0 psci0: on ofwbus0 > gic0: mem > 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 23 on > simplebus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 gpio0: GPIO/Pinmux controller> mem 0x1c20800-0x1c20bff irq 12,13,14 on simplebus0 gpiobus0: GPIO bus> on gpio0 gpio1: mem 0x1f02c00-0x1f02fff irq > 26 on simplebus0 gpiobus1: on gpio1 > generic_timer0: irq 0,1,2,3 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > rtc0: mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0 > rtc0: registered as a time-of-day clock, resolution 1.000000s > awusbphy0: mem > 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0 cpulist0: Firmware CPU Group> on ofwbus0 cpu0: on cpulist0 > cpu1: on cpulist0 > cpu2: on cpulist0 > cpu3: on cpulist0 > aw_mmc0: mem 0x1c0f000-0x1c0ffff irq 4 on > simplebus0 mmc0: on aw_mmc0 > ehci0: mem 0x1c1b000-0x1c1b0ff irq 10 on > simplebus0 usbus0: EHCI version 1.0 > usbus0 on ehci0 > ohci0: mem 0x1c1b400-0x1c1b4ff irq 11 on simplebus0 > usbus1 on ohci0 > gpioc0: on gpio0 > uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on simplebus0 > uart0: console (115384,n,8,1) > iic0: on iicbus0 > gpioc1: on gpio1 > awg0: mem 0x1c30000-0x1c31fff,0x1c00030-0x1c00033 irq 27 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-FDX-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-FDX-flow-master, auto, auto-flow awg0: Ethernet address: 02:ba:87:48:13:ae > cryptosoft0: Timecounters tick every 1.000 msec usbus0: 480Mbps High > Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at > usbus0 uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > mmcsd0: 16GB at mmc0 > 50.0MHz/4bit/32768-block Release APs...arc4random: no preloaded entropy cache > mmc0: done > ACMD42 failed, RESULT: 4 > CPU 0: ARM Cortex-A53 r0p4mmc0: affinity:Card at relative address 43690 failed to set > bus width 0 > Instruction Set Attributes 0 = > Instruction Set Attributes 1 = <> > Processor Features 0 = > Processor Features 1 = <0> > Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit > ASID,1TB PA> Memory Model Features 1 = <> > Memory Model Features 2 = <32b CCIDX,48b VA> > Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 > Breakpoints,PMUv3,Debug v8> Debug Features 1 = <0> > Auxiliary Features 0 = <0> > Auxiliary Features 1 = <0> > CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > CPU 2: ARM Cortex-A53 r0p4 affinity: 2 > CPU 3: ARM Cortex-A53 r0p4 affinity: 3 > WARNING: WITNESS option enabled, expect reduced performance. > Root mount waiting for: usbus1 usbus0 > uhub1: 1 port with 1 removable, self powered > uhub0: 1 port with 1 removable, self powered > > Loader variables: > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input That means the kernel doesn't have a root device configured. > mountroot> random: unblocking device. > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > > panic: mountroot: unable to (re-)mount root. > cpuid = 2 > time = 167 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc = 0xffff000000688e14 lr = 0xffff0000000dad40 > sp = 0xffff00005891d590 fp = 0xffff00005891d7a0 > > db_trace_self_wrapper() at vpanic+0x1a8 > pc = 0xffff0000000dad40 lr = 0xffff000000388c98 > sp = 0xffff00005891d7b0 fp = 0xffff00005891d860 > > vpanic() at panic+0x44 > pc = 0xffff000000388c98 lr = 0xffff000000388d48 > sp = 0xffff00005891d870 fp = 0xffff00005891d8f0 > > panic() at vfs_mountroot+0x1610 > pc = 0xffff000000388d48 lr = 0xffff00000044d1c8 > sp = 0xffff00005891d900 fp = 0xffff00005891dab0 > > vfs_mountroot() at start_init+0x28 > pc = 0xffff00000044d1c8 lr = 0xffff000000321ee4 > sp = 0xffff00005891dac0 fp = 0xffff00005891db50 > > start_init() at fork_exit+0x7c > pc = 0xffff000000321ee4 lr = 0xffff000000349fa4 > sp = 0xffff00005891db60 fp = 0xffff00005891db90 > > fork_exit() at fork_trampoline+0x10 > pc = 0xffff000000349fa4 lr = 0xffff0000006a4cdc > sp = 0xffff00005891dba0 fp = 0x0000000000000000 > > KDB: enter: panic > [ thread pid 1 tid 100002 ] > Stopped at 0 > db> root@xterminal:~ # > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Best way to use FreeBSD on Pine64-LTS is to download the Pine64 snapshot image and override u-boot with the u-boot-sopine. Or wait until https://reviews.freebsd.org/D16487 is commited. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Jul 31 01:48:39 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC3CD1069D96 for ; Tue, 31 Jul 2018 01:48:39 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30881734FB for ; Tue, 31 Jul 2018 01:48:38 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w6V1mXHu086625 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Jul 2018 18:48:33 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w6V1mW02086624; Mon, 30 Jul 2018 18:48:32 -0700 (PDT) (envelope-from jmg) Date: Mon, 30 Jul 2018 18:48:32 -0700 From: John-Mark Gurney To: Emmanuel Vadot Cc: Ulrich Grey , freebsd-arm@freebsd.org Subject: Re: Booting PINE64-LTS does not work Message-ID: <20180731014832.GH2884@funkthat.com> Mail-Followup-To: Emmanuel Vadot , Ulrich Grey , freebsd-arm@freebsd.org References: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 30 Jul 2018 18:48:33 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 01:48:39 -0000 Emmanuel Vadot wrote this message on Mon, Jul 30, 2018 at 20:31 +0200: > Best way to use FreeBSD on Pine64-LTS is to download the Pine64 > snapshot image and override u-boot with the u-boot-sopine. I'll second this. It works and is easy to do... the README has slightly wrong file names, but it's easy enough to figure out which one is correct... > Or wait until https://reviews.freebsd.org/D16487 is commited. Any specific reason that hasn't been yet? besides it being just created? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Tue Jul 31 05:47:03 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 980C9104E7C5 for ; Tue, 31 Jul 2018 05:47:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 15C5F7A77E for ; Tue, 31 Jul 2018 05:47:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6V5lCNN092977 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Jul 2018 22:47:13 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6V5lCsO092976; Mon, 30 Jul 2018 22:47:12 -0700 (PDT) (envelope-from fbsd) Date: Mon, 30 Jul 2018 22:47:12 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments Message-ID: <20180731054712.GA92917@www.zefox.net> References: <2deaaec3-f78f-0b09-5ca7-27e14c6979f9@sentry.org> <20180723063526.GA45726@www.zefox.net> <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180725232453.GA57716@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 05:47:03 -0000 OOMA is still killing processes in -j4 buildworld sessions for no obvious reason when using mixed USB/microSD swap. The most recent experiment is with r336877 rebuilding itself from a clean start. The various log files are at http://www.zefox.net/~fbsd/rpi3/swaptests/r336877/ The OOMA kills occur around two hours after the worst read/write delays, which are in the low tens of seconds. Perhaps most curiously, the long delays don't appear to involve swap partitions. Similar problems now seem present with the RPI2 on 11-stable. The first failure was with r335398 trying to compile 336871. Buildworld has been backed down to -j2 and restarted in the hope it'll eventually succeed. In this particular case all swap is on USB, in a single 2 GB partition. It would be most interesting to see what happens if OOMA could be turned off. Is that possible? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Tue Jul 31 06:44:46 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A5631050114 for ; Tue, 31 Jul 2018 06:44:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-15.consmr.mail.bf2.yahoo.com (sonic313-15.consmr.mail.bf2.yahoo.com [74.6.133.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FEC67C79A for ; Tue, 31 Jul 2018 06:44:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Od9WJCYVM1npDQxnsUeyGy4coNZooxMYoL4iGlsvfrkTMugwjKuKP9X4N4yoM9J l8obGdowG8mehkenPKOnHB6YUkmOGkxJV7gC4uOnP20SkbDu2HNfziJa1p0kMd8y3JRnjGIxJ7Lo sxivr2Sd35csURsB.ugP5qH41q4F5gkAB20Y3npWE1MSUVS_EE.L65ZvLW1lZwkXh5zyKg0jFwWo V03dn04wT2oka9yWm87RnjxcLw5iunmZ_nytHr0mnLP.tv3RCaBVm.ITG06W6oZQLPtgfj1ALgnU dVyhxcNr15ZSWNweN94K5sBS.bkOeDdmKbrYsN8Z6DdE.ArWEbLLKG6Iz5ghqXtxhHaU_GFz1iTf LpH6EB9ONo38yrAujmk70WRwKtoVsWH3DKx4Us9kiurmFOnhfAxC0xJ7vYDw_MXx3V_Zuw4mHD3X TPGa7LbEqj1YgFrQ.77vLy_ky9BRiiVNaOnD4pR79fT3RP8sERV2LQtycCI3QrGEmaGwAMUBr1OX Uh.kLg4D7j5ZYahH0XQ00ob7u0gIBWM9EOjqZgJ9AQLwO.rtIvoHP3dsN.SzJjQ1eZ0e9NBQeHtY DLKIOSJHmmxSafMB4wrlbfSCVzmeaO3BiRvFgnlyXerQvb.cfvUY2wYP3tOSL3Ia8AGmMSkt1DIy 1cM28Aw1347JegvzYkJx0okBzWA2oqTjDusACBYV0BLbDiDzZ5ULd.fVB0kukHrvU8t2k5dbJvbr bNiOqkgaC9ADgcJ1cdTJfFeLdCidnpqPahmO8nFZvrEuSfbmAmvQP8sbpq7q6q6Rze2_rc9EcxID KXCLZFNVNosUER8azKmQXTthYKUciTk6CVUFU0EM1OB1mvlSh7AtXFOf_AJHc0rs3OJiYYx4nigp e9IS8Jw8CFIgy2BEOHwDrqbt9Wu2aAnaS2NRRAaYIekqecn5bLc_eCeBi13ThLZbffGDMFwVhAd2 FINDX3SlXrptu3tEJmoutTWnZb7rIidFLx5UG9NbzXFDu2_yZq2cEDFx9uWVGcuVKQPhsRnxJphn Y3zVkA17nSDA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Tue, 31 Jul 2018 06:44:45 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3f2a2c47ec98d5cfdf8e480d2eda9d79; Tue, 31 Jul 2018 06:44:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <20180731054712.GA92917@www.zefox.net> Date: Mon, 30 Jul 2018 23:44:42 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <50802D52-9CB2-4E55-A80D-6E8D68B81431@yahoo.com> References: <2deaaec3-f78f-0b09-5ca7-27e14c6979f9@sentry.org> <20180723063526.GA45726@www.zefox.net> <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> <20180731054712.GA92917@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 06:44:46 -0000 On 2018-Jul-30, at 10:47 PM, bob prohaska wrote: > OOMA is still killing processes in -j4 buildworld sessions for no = obvious reason > when using mixed USB/microSD swap. The most recent experiment is with = r336877=20 > rebuilding itself from a clean start. >=20 > The various log files are at=20 > http://www.zefox.net/~fbsd/rpi3/swaptests/r336877/ > The OOMA kills occur around two hours after > the worst read/write delays, which are in the low tens > of seconds. Perhaps most curiously, the long delays > don't appear to involve swap partitions.=20 >=20 > Similar problems now seem present with the RPI2 on > 11-stable. The first failure was with r335398 trying=20 > to compile 336871. Buildworld has been backed down to=20 > -j2 and restarted in the hope it'll eventually succeed. > In this particular case all swap is on USB, in a single > 2 GB partition. My records indicate (from old boot messages and reported in past list messages): rpi2: . . . exceeds maximum recommended amount (411488 pages). rpi3: . . . exceeds maximum recommended amount (925680 pages). 411488*4K Bytes =3D 1,685,454,848 Bytes for rpi2 (older V1.1 armv7 variant). In other words: you have more swap than is recommended for such a context because of fragmentation issues and such for overhead information related to keeping track of swapping/paging. I suggest trying not exceeding the 1,685,454,848 figure for the rpi2 context, just as a cross check. May be 411000*4K Bytes, so 1,683,456,000 Bytes, avoiding being right at the boundary? 925680*4K Bytes =3D 3,791,585,280 Bytes for rpi3. Are thew drives involved different ones than used with the rpi3 experiments? (Just curious.) > It would be most interesting to see what happens if OOMA > could be turned off. Is that possible?=20 If the code reaches conditions which initiate OOMA now, what would proposed alternate action be? As stands if OOMA itself fails to happen, my guess would be the kernel would panic, deadlock, or livelock in some way. Simply having OOMA not attempted would likely be the same as OOMA failing unless more than disabling OOMA was done. (I'm no expert at such so if someone that knows makes a claim, believe them instead of me.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jul 31 07:02:17 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9373E10505C9 for ; Tue, 31 Jul 2018 07:02:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.ne1.yahoo.com (sonic302-20.consmr.mail.ne1.yahoo.com [66.163.186.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A6AC7CD3C for ; Tue, 31 Jul 2018 07:02:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ibB_3HEVM1lif_I9aBKZXDS439r2IDD.ReH944gubJgMOcswbZPzH.3sckaIs05 lIrUPDLiC8JH6GE9gjcMPxBouewX6TO2DFOdBQld6lEH.tTpeclWlduZCgEM7ybNqN24URjpp8HE 1KYXLl1UB8KqBc_Ocqj9hewfxx_P80WGb.YPPBcaadhifI1T_zm1QXt7ttO6eTeD2224nrGkq13k nm7Gw1TfeXiCKwgxHhXxGVjDO6WGKE.CCy0LQ3fEpZLM9iMofNSHdV2BOMH.r4jFQ._ddy984atz 22m3b.mLUaSSQZx_BY3l.PzKDoLX.Ud2DBeVfDXZ.F6sDx3hCC_jiTHAKMiDZzcMhuodBvmJ9bFU wdNIAgp.s4Zzb.vXH2OioUKm.m2yhSWpOE.yYz2XNsghDcumlsIkfWpkzzZh.Zm19JoE0ySZQu7Q TEaOyAWyvi6z.BHn8nHbQREvPyTRuNk1WrygRmb4Do.kGT9TgxyEPs.fPMy6EBMB0d0yqAtqFhhe V.tbTlu8zi4fPyUHEF3Ihg9yyqzI.xD3B4gg0pUVBpCZ7fD1fXNNSBFlPHgKNEclSd7aTD32Q_yq KiHqH8Wa_E0cw._DxPugmdhraGHvTEjM9mdOmzNYRgnykF8TDT2uooNxpcEpLKSAAukBHXKny.dH N2TnAfs98igBK5YP7M9qaB2IdUx.OM9w3Yyq2j2o82lKC0AmmRoh5WHMpOTQLWXqBIk2MLWPbN_V .m.V9rSJg08larNEEZH.ma1BzqLdc7vgS4UYOe3K9S6bZkACiRtEPVtoddj.NLSVHL_n3NnuTR96 uIX5iS3zdvjP5oxX5AJbsV4uyGQDOJ6r2RDLZgkTTeIlKp_VPPTYnPuJ4GRRqpQRvQqpAec74m2K YnEFQwAeIGiqQAA_ZyWWf61f65iiGpknRDMijTzbjNbDkohcsaO3YqGsowsyC4QqdMmCNp7Q1YqC ORulQ.zeqGOC5rm6lfwiF_cJgDVX4KlzSDbYYbrsYq00p1mKmBWfRE_xNYChvBlGylDKr1ssCg4q ohIdgCSh.YiI1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Tue, 31 Jul 2018 07:02:15 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp424.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e5e8602c2889385dae8be225ade12528; Tue, 31 Jul 2018 07:02:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <50802D52-9CB2-4E55-A80D-6E8D68B81431@yahoo.com> Date: Tue, 31 Jul 2018 00:02:12 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <9FC91439-383B-4A01-ACF4-7CAF36BC9747@yahoo.com> References: <2deaaec3-f78f-0b09-5ca7-27e14c6979f9@sentry.org> <20180723063526.GA45726@www.zefox.net> <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> <20180731054712.GA92917@www.zefox.net> <50802D52-9CB2-4E55-A80D-6E8D68B81431@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 07:02:17 -0000 On 2018-Jul-30, at 11:44 PM, Mark Millard wrote: > On 2018-Jul-30, at 10:47 PM, bob prohaska = wrote: >=20 >> OOMA is still killing processes in -j4 buildworld sessions for no = obvious reason >> when using mixed USB/microSD swap. The most recent experiment is = with r336877=20 >> rebuilding itself from a clean start. >>=20 >> The various log files are at=20 >> http://www.zefox.net/~fbsd/rpi3/swaptests/r336877/ >> The OOMA kills occur around two hours after >> the worst read/write delays, which are in the low tens >> of seconds. Perhaps most curiously, the long delays >> don't appear to involve swap partitions.=20 >>=20 >> Similar problems now seem present with the RPI2 on >> 11-stable. The first failure was with r335398 trying=20 >> to compile 336871. Buildworld has been backed down to=20 >> -j2 and restarted in the hope it'll eventually succeed. >> In this particular case all swap is on USB, in a single >> 2 GB partition. >=20 > My records indicate (from old boot messages and reported > in past list messages): >=20 > rpi2: . . . exceeds maximum recommended amount (411488 pages). > rpi3: . . . exceeds maximum recommended amount (925680 pages). >=20 > 411488*4K Bytes =3D 1,685,454,848 Bytes for rpi2 (older V1.1 armv7 > variant). In other words: you have more swap than is recommended > for such a context because of fragmentation issues and such for > overhead information related to keeping track of swapping/paging. >=20 > I suggest trying not exceeding the 1,685,454,848 figure for the > rpi2 context, just as a cross check. May be 411000*4K Bytes, > so 1,683,456,000 Bytes, avoiding being right at the boundary? >=20 > 925680*4K Bytes =3D 3,791,585,280 Bytes for rpi3. >=20 > Are thew drives involved different ones than used with the > rpi3 experiments? (Just curious.) >=20 >=20 >> It would be most interesting to see what happens if OOMA >> could be turned off. Is that possible?=20 >=20 > If the code reaches conditions which initiate OOMA now, what > would proposed alternate action be? As stands if OOMA itself > fails to happen, my guess would be the kernel would panic, > deadlock, or livelock in some way. Simply having OOMA not > attempted would likely be the same as OOMA failing unless > more than disabling OOMA was done. >=20 > (I'm no expert at such so if someone that knows makes a claim, > believe them instead of me.) Looking around, there have been other rpi2 figures that I've seen and reported on the lists, for example: exceeds maximum recommended amount (405460 pages) exceeds maximum recommended amount (469280 pages) So if you do not have a specific figure from a boot message, your might want: 400000*4K Bytes =3D 1,638,400,000 Bytes or even somewhat less. If you have a specific figure from a current boot message for the same version, I'd go somewhat less than that figure scaled to Bytes. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jul 31 12:44:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D21910593FF for ; Tue, 31 Jul 2018 12:44:18 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7910089372 for ; Tue, 31 Jul 2018 12:44:17 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w6VCVXhX048495 for ; Tue, 31 Jul 2018 22:31:33 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: RPI3 swap experiments To: freebsd-arm@freebsd.org References: <2deaaec3-f78f-0b09-5ca7-27e14c6979f9@sentry.org> <20180723063526.GA45726@www.zefox.net> <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> <20180731054712.GA92917@www.zefox.net> From: Trev Message-ID: Date: Tue, 31 Jul 2018 22:31:33 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <20180731054712.GA92917@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Tue, 31 Jul 2018 22:31:33 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 12:44:18 -0000 bob prohaska wrote on 31/07/2018 15:47: > Similar problems now seem present with the RPI2 on > 11-stable. The first failure was with r335398 trying > to compile 336871. Buildworld has been backed down to > -j2 and restarted in the hope it'll eventually succeed. > In this particular case all swap is on USB, in a single > 2 GB partition. I'm interstate for a week or so, but will re-test the RPi2 when I get back. > It would be most interesting to see what happens if OOMA > could be turned off. Is that possible? Possibly, but you might find you're treating the symptom(s) rather than the cause(s) ... something must be triggering the condition whether correctly or not. From owner-freebsd-arm@freebsd.org Tue Jul 31 15:35:17 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35012105CE20 for ; Tue, 31 Jul 2018 15:35:17 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 952A78EFB0 for ; Tue, 31 Jul 2018 15:35:16 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6VFZWTf094800 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Jul 2018 08:35:33 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6VFZVSU094799; Tue, 31 Jul 2018 08:35:32 -0700 (PDT) (envelope-from fbsd) Date: Tue, 31 Jul 2018 08:35:31 -0700 From: bob prohaska To: Trev Cc: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments Message-ID: <20180731153531.GA94742@www.zefox.net> References: <20180723063526.GA45726@www.zefox.net> <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> <20180731054712.GA92917@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 15:35:17 -0000 On Tue, Jul 31, 2018 at 10:31:33PM +1000, Trev wrote: > bob prohaska wrote on 31/07/2018 15:47: > > > It would be most interesting to see what happens if OOMA > > could be turned off. Is that possible? > > Possibly, but you might find you're treating the symptom(s) rather than > the cause(s) ... something must be triggering the condition whether > correctly or not. That's my point. To determine if OOMA is triggered correctly or not. I'm starting to think not. The reason is the dependency on swap layout (mixed USB/microSD vs all one or the other) and the fact that OOMA kills don't seem to coincide with periods of maximum storage read/write delay, which is the conventional explanation for why OOMA kills happen in the first place. If turning off OOMA allows buildworld to complete successfully it suggests OOMA isn't correctly implemented. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Tue Jul 31 15:52:02 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63969105D330; Tue, 31 Jul 2018 15:52:02 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3CD58F907; Tue, 31 Jul 2018 15:52:01 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x229.google.com with SMTP id y10-v6so13423775ioa.10; Tue, 31 Jul 2018 08:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=vH4Uf0MwVwZ5g0Fo9z1DvyeZn09CUYwNEPq0rVrXYk0=; b=h7RC2V6o33eBIIR1RYemZfxQ0jwN8cagroFYSDXxxIzEozD/1KmfQ895YwfDGFfk6k qSbo+PGUcS4jNdKWkB905WyPvgNAAySiCKNDJzwFdV+Plh5aERAG4pV46/iSMBdnKduo /6PkZTS/8AzK47khQ3rijikT05Mb+qGqeFxowNFS/EisoRJvwN/2tdxsG4l9bVPzHIDc 3va39VZQrf3X9HEbLauu2wy61zJ8uflpAp+a6CcSikAB1SNzWd+defNiAW7V34kPLILm IlR3TuvlLiJfYsd7cyYELxVlCtEt73WF7RP3sjFlYHntwQ5zMQBiCUq7UO2+ydeM8MoQ rLEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=vH4Uf0MwVwZ5g0Fo9z1DvyeZn09CUYwNEPq0rVrXYk0=; b=UFYFUV1yxgLFtFgf8N5pcjrOWJQij1BiLsYeuhrZAsNgg5lxWmiEipYDk55DjhjXOU IYTyQ1v6Vv2PhAhtkx5d4gAQrZZhlcOkSr2Fd+vZvvFtd6ByqeDneR4T7xH2ebljN6rj KVev54fOr+7VjsTkThuWZbGJv4XiJ3E+tSfFzdGBUpzrSQC7G+OSXcpnxGacVufvNh7w GlexCd0XysGN02BBg+XxXX6dDsyKHshON2X2H+M1P83CknDLrmjy7XumIkUvcjLSv5gz X2hldL410hreMuMQrlAfLz593R+cioI3fjKvXHI9oX5IXBRX8rhYUQF+pmoGzz4rooZC Ac0Q== X-Gm-Message-State: AOUpUlGLj8TIp0iv26r/OWH6n30X3TnyEYrSJ+HlAreQvs9k7qNQQVuR SYPUfLiXe7ddKYSBeebomjtVIKTC0PKW5UQ+I6R+HZpV X-Google-Smtp-Source: AAOMgpcM49Jb8pcs3mps/s38KzGA7VfQxqTznVpAOr6y0ATuAydumhcpfwa87nWIEBxspxrI5lMwjmI6SX3B9YBt5/c= X-Received: by 2002:a6b:343:: with SMTP id 64-v6mr285513iod.66.1533052321150; Tue, 31 Jul 2018 08:52:01 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:4a08:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 08:51:38 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Tue, 31 Jul 2018 11:51:38 -0400 X-Google-Sender-Auth: ug3XL4DYXvez8TgLJ4NBU2rA_XE Message-ID: Subject: Re: Migrating arm(v7) to LLD_BOOTSTRAP To: "freebsd-toolchain@FreeBSD.org" , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 15:52:02 -0000 On 16 January 2018 at 18:45, Ed Maste wrote: > With the update to Clang/LLVM/lld 6.0.0 I believe lld is nearly ready > to be used as the system linker for armv7, and I plan to enable > LLD_BOOTSTRAP by default after a couple of WIP patches land and after > a little more testing. This may happen a week or two from now. This > should have little impact on port builds, because /usr/bin/ld will > still be GNU ld.bfd (although there may be some unexpected fallout). There was one significant issue preventing use of lld for armv7 - it was not handling float type flags in the ELF header. This was just fixed upstream, and I brought the change into FreeBSD in r336972. I believe we're now ready to enable LLD_BOOTSTRAP by default for armv7, and have posted the patch in review D16528[1] for comments/feedback. [1] https://reviews.freebsd.org/D16528 From owner-freebsd-arm@freebsd.org Tue Jul 31 15:59:36 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65633105D4F2 for ; Tue, 31 Jul 2018 15:59:36 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BE7A38FB88 for ; Tue, 31 Jul 2018 15:59:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6VFxpH0094863 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Jul 2018 08:59:52 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6VFxpvH094862; Tue, 31 Jul 2018 08:59:51 -0700 (PDT) (envelope-from fbsd) Date: Tue, 31 Jul 2018 08:59:51 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm Subject: Re: RPI3 swap experiments Message-ID: <20180731155951.GB94742@www.zefox.net> References: <20180723063526.GA45726@www.zefox.net> <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> <20180731054712.GA92917@www.zefox.net> <50802D52-9CB2-4E55-A80D-6E8D68B81431@yahoo.com> <9FC91439-383B-4A01-ACF4-7CAF36BC9747@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9FC91439-383B-4A01-ACF4-7CAF36BC9747@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 15:59:36 -0000 On Tue, Jul 31, 2018 at 12:02:12AM -0700, Mark Millard wrote: > On 2018-Jul-30, at 11:44 PM, Mark Millard wrote: > > > On 2018-Jul-30, at 10:47 PM, bob prohaska wrote: > > > >> Similar problems now seem present with the RPI2 on > >> 11-stable. The first failure was with r335398 trying > >> to compile 336871. Buildworld has been backed down to > >> -j2 and restarted in the hope it'll eventually succeed. > >> In this particular case all swap is on USB, in a single > >> 2 GB partition. > > > > My records indicate (from old boot messages and reported > > in past list messages): > > > > rpi2: . . . exceeds maximum recommended amount (411488 pages). > > rpi3: . . . exceeds maximum recommended amount (925680 pages). > > > > 411488*4K Bytes = 1,685,454,848 Bytes for rpi2 (older V1.1 armv7 > > variant). In other words: you have more swap than is recommended > > for such a context because of fragmentation issues and such for > > overhead information related to keeping track of swapping/paging. > > What disturbs me is that the 11-stable machine was in the past able to run a -j4 buildworld successfully. Seemingly it's becomeing less robust, not more. That's a bad sort of progress 8-) > > I suggest trying not exceeding the 1,685,454,848 figure for the > > rpi2 context, just as a cross check. May be 411000*4K Bytes, > > so 1,683,456,000 Bytes, avoiding being right at the boundary? > > > > 925680*4K Bytes = 3,791,585,280 Bytes for rpi3. > > > > Are thew drives involved different ones than used with the > > rpi3 experiments? (Just curious.) > > No, they're different machines entirely. > > > >> It would be most interesting to see what happens if OOMA > >> could be turned off. Is that possible? > > > > If the code reaches conditions which initiate OOMA now, what > > would proposed alternate action be? As stands if OOMA itself > > fails to happen, my guess would be the kernel would panic, > > deadlock, or livelock in some way. Simply having OOMA not > > attempted would likely be the same as OOMA failing unless > > more than disabling OOMA was done. > > I'm simply curious to see if the buildworld completes successfully or not, in the absence of OOMA intervention. The insistence has been that OOMA is triggered by excessive delays in accessing storage devices. However, it looks as if OOMA kills aren't correlated in time with storage read/write delays and do seem to be correlated to swap layout, being worse when swap is distributed across both USB and microSD. There were similar reports of wanton process killing on other platforms, but I haven't seen one in several weeks at least. Was that problem identified and solved, or has it simply faded into old news? Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Tue Jul 31 16:03:10 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBF9F105D7E7 for ; Tue, 31 Jul 2018 16:03:10 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 31EC88FF9F for ; Tue, 31 Jul 2018 16:03:09 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w6VG2xN5072498; Tue, 31 Jul 2018 09:02:59 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w6VG2xcN072497; Tue, 31 Jul 2018 09:02:59 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> Subject: Re: RPI3 swap experiments In-Reply-To: <20180731153531.GA94742@www.zefox.net> To: bob prohaska Date: Tue, 31 Jul 2018 09:02:59 -0700 (PDT) CC: Trev , freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 16:03:10 -0000 > On Tue, Jul 31, 2018 at 10:31:33PM +1000, Trev wrote: > > bob prohaska wrote on 31/07/2018 15:47: > > > > > It would be most interesting to see what happens if OOMA > > > could be turned off. Is that possible? > > > > Possibly, but you might find you're treating the symptom(s) rather than > > the cause(s) ... something must be triggering the condition whether > > correctly or not. > > That's my point. To determine if OOMA is triggered correctly or not. I'm starting > to think not. > > The reason is the dependency on swap layout (mixed USB/microSD vs all one or the > other) and the fact that OOMA kills don't seem to coincide with periods of > maximum storage read/write delay, which is the conventional explanation for > why OOMA kills happen in the first place. If turning off OOMA allows buildworld > to complete successfully it suggests OOMA isn't correctly implemented. > An easy way of triggering OOM that I ran accross the other day is simply: truncate -s 4G foo grep Anything foo grep(1) well gladly grow up to 4G trying to create a "line" of text to search for the string "Anything". On a system with less than 4G of free memory this triggers an OOM and starts killing processes. Probably has to be run as root or limits get hit. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Tue Jul 31 17:52:04 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFFF41060124 for ; Tue, 31 Jul 2018 17:52:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4722B74753 for ; Tue, 31 Jul 2018 17:52:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 3jjNQFEVM1mREEZO70heCF7tyhyt5Dsf9ppbyoIJUuZqHiOnYvxo.hFxVwn2HNk iDX1MYfzy131SS74EaM8g7VnqKLp6E6Cs.LdIvP0PHu0E_jSNcka4whYPmVyb0ItJrzK7V2Oec0R BUHf_dqCmVmyoAloBOpmpmUzxTv1B9Wd.dMQ2MI8Dq3MKLFnjhY0anyZYUzGiYJ0cNmrPbv7Erc6 6v6PDOxlkV5sAtPSf.M6tdybNx.NF8dClPLvbNgG68zvoVeI3ceTKZYmWHK6sVyJ88oiREpf_u6z gAZdDXFoRZ6vjY4ANqxVZnPYphBsaMSG4PzSSccgqZbI1C_Ovt4lcmWP4dqBCtxu92PEmka19zvc 1sbUruSueJcTy.Gf7gosKR54Hdy_osfv1R12UX5AwErJIFPkcyd9_QYVeHkpvqys7khkXjWn8jHc 5vzfcJ8FW7sBOfmb_PAJuFe0QM.wGcyWKtQhpjattJ0Tcjcl8dbAmkB8c_OR3tTJTnGTqOXAV30H 49Xb2djzPobmJuyZuqu3P2uHDB9rXkIi5.TMFDnbQwk3G58_uyb0xFaFCr13gIQTChHvxvoK_8P6 qj_hKa1r4mXYwuFWBC2fERED_ykidMqANvn5DdCBP68DNSqx7tD_v3qXPupLypKqOMgoYRF6Sdow 9z1hlweuBKYzMcwBWRo22Q6WkSU3hzbMdBMm28ugCxSSndrgxZTKThBG_sIcKZgkecZVOvElyiZ6 OGugM.HCOSz.rWRKq4ip1vNHhf.RqqzeM6C2uSz0ILm41peM4.aQ6vxB9wLYjOA8WOgRNu2gIamU OreNk4QBthzXCjqb2FD84mcvOaXNSpnQRY.nvrZJUfZNCDteQjT1INo36JkRp3E2j8oQPRtlfYY7 .U0ehxDunJNdKU87uiw1vS34RNn1mGm2s4UokjP.hHKTw6BQPSNE59AwIbYkPZCWQUw1b2aSvFgw qBEbjrQMTar52KdSZEUFYvPF2e7omIj1oygZWv1f4N7DGj9HtYZSx8RB_WmVuVR2OgrCHmMD3rdi vPwsR0r7f Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Tue, 31 Jul 2018 17:51:56 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp411.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ac671155936c34d194286ae9d6da3f75; Tue, 31 Jul 2018 17:51:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <20180731153531.GA94742@www.zefox.net> Date: Tue, 31 Jul 2018 10:51:51 -0700 Cc: Trev , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <908FB299-07CF-4E88-9C18-298CA357AD01@yahoo.com> References: <20180723063526.GA45726@www.zefox.net> <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> <20180731054712.GA92917@www.zefox.net> <20180731153531.GA94742@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 17:52:05 -0000 On 2018-Jul-31, at 8:35 AM, bob prohaska wrote: > On Tue, Jul 31, 2018 at 10:31:33PM +1000, Trev wrote: >> bob prohaska wrote on 31/07/2018 15:47: >>=20 >>> It would be most interesting to see what happens if OOMA >>> could be turned off. Is that possible? >>=20 >> Possibly, but you might find you're treating the symptom(s) rather = than=20 >> the cause(s) ... something must be triggering the condition whether=20= >> correctly or not. >=20 > That's my point. To determine if OOMA is triggered correctly or not. = I'm starting > to think not. >=20 > The reason is the dependency on swap layout (mixed USB/microSD vs all = one or the > other) and the fact that OOMA kills don't seem to coincide with = periods of=20 > maximum storage read/write delay, which is the conventional = explanation for > why OOMA kills happen in the first place. If turning off OOMA allows = buildworld > to complete successfully it suggests OOMA isn't correctly implemented.=20= Your rpi2 report said: > In this particular case all swap is on USB, in a single > 2 GB partition. which for that example indicates that swap layout being split was not involved. (But there is the potential too-large issue.) Have you had other examples of non-split swap layout getting OOMA kills? If yes, what types of contexts? [Especially any that do not have observed huge latencies or to evidence of device failures (retries required).] Any on rpi3? Any others on rpi2? As for swap use, do you have any tmpfs or other files systems that are memory based that also use swap if they grow too big (and are configured to allow such growth)? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jul 31 18:19:09 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1029F1060D4C for ; Tue, 31 Jul 2018 18:19:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7051D759F1 for ; Tue, 31 Jul 2018 18:19:08 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6VIJN8X095217 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Jul 2018 11:19:24 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6VIJNbQ095216; Tue, 31 Jul 2018 11:19:23 -0700 (PDT) (envelope-from fbsd) Date: Tue, 31 Jul 2018 11:19:23 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments Message-ID: <20180731181923.GC94742@www.zefox.net> References: <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> <20180731054712.GA92917@www.zefox.net> <20180731153531.GA94742@www.zefox.net> <908FB299-07CF-4E88-9C18-298CA357AD01@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <908FB299-07CF-4E88-9C18-298CA357AD01@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 18:19:09 -0000 On Tue, Jul 31, 2018 at 10:51:51AM -0700, Mark Millard wrote: > > > On 2018-Jul-31, at 8:35 AM, bob prohaska wrote: > > > On Tue, Jul 31, 2018 at 10:31:33PM +1000, Trev wrote: > >> bob prohaska wrote on 31/07/2018 15:47: > >> > >>> It would be most interesting to see what happens if OOMA > >>> could be turned off. Is that possible? > >> > >> Possibly, but you might find you're treating the symptom(s) rather than > >> the cause(s) ... something must be triggering the condition whether > >> correctly or not. > > > > That's my point. To determine if OOMA is triggered correctly or not. I'm starting > > to think not. > > > > The reason is the dependency on swap layout (mixed USB/microSD vs all one or the > > other) and the fact that OOMA kills don't seem to coincide with periods of > > maximum storage read/write delay, which is the conventional explanation for > > why OOMA kills happen in the first place. If turning off OOMA allows buildworld > > to complete successfully it suggests OOMA isn't correctly implemented. > > Your rpi2 report said: > > > In this particular case all swap is on USB, in a single > > 2 GB partition. > > which for that example indicates that swap layout being split > was not involved. (But there is the potential too-large issue.) > That's true, I can't test mixed swap on that setup. My point was that formerly (months ago) 2GB of USB swap worked for -j4 buildworld. > Have you had other examples of non-split swap layout getting > OOMA kills? If yes, what types of contexts? [Especially any that > do not have observed huge latencies or to evidence of device > failures (retries required).] Any on rpi3? Any others on rpi2? > Yes. Another storage configuration for the Pi3 (not installed at the moment) has three 1 GB swap partitions on USB and three 1 GB swap partitions on microSD. In that case buildworld fails from OOMA using 2 GB mixed or microSD swap but succeeds using USB swap. That surprised me in that the microSD cards are the same. The USB device in that case is 3.0 vs 3.1, so different in some small way. > As for swap use, do you have any tmpfs or other files systems > that are memory based that also use swap if they grow too > big (and are configured to allow such growth)? > No memory-based filesystems in use. > Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Tue Jul 31 19:05:02 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFED7106202F for ; Tue, 31 Jul 2018 19:05:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4356177C24 for ; Tue, 31 Jul 2018 19:05:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: s0ESbTEVM1mmsGBGI2edhOlY4PtkG7rYwLB.F.GtkTvYQSSvAbEWqHLdqFmzrTc OtVA0McNdssokrEyMHAhSfyefzZkoMfoA7s6RWOgUMtJTEri4xowySPq7YclSyyGZxjMzTvzFxi7 EsKD7aMsMZSlBdvwWugCx50MBL5cIzv8Iua1saazuWw40VMDnHUbm9TkxJHzasxPGzld6zdOLhe7 2gbgpbEtLIpRhWAxoFdG_wewQ8L6OIr46bExgc5qAMcB.jVGoJemx.bOnxn8Kfv5nyscFAf5rs4U yQWkvh5QCWXIfi3x.LQNbhOunZDkRVS1kEPtXg0RImCjHOtIryBhFwvrOTysCj4G3ULPNT9iPlAD LvZAk7Sv6M9afZSFRqIpwtymeRzcqQ3W_SUz7aR8iSkUH46WUeJPhPmXrlmCNt9qSfNJMk.O4y0n J12qs.RVAnpZkaD_EGwGMpLJZs_2BMfYl766huxm6lUUeJg4aE31pR3x5RuR2S5yhrzbgiidbRjA 7zWuCeszcaoA2nHEINXo3lLyYxaHzImkOHvGy2woPrnsihVdYflhZxanUfLH4OTtwS6NjzQaBJwI QQAOPJka5AoCqKAvKvcHAG8wGpjbS2id61tzk4tk.tzU2QdA8AwZjN9YORnoX8M.gx5MCavUC2VX 39uMeLt3zdb0fFkcdv76G2RhGAsCv.qP5c7wx93xZrxzq6QIKMg_IJ5ASVODyVZqKsDmY9Y_jsav xiBSZZe4Lkev_GOLFGUZs4Om1Y3bojz2EN_MsGm7yP9Hua6zEnIr6wrdexUqCFZLwjPFPXfyo8N6 yO5qEpLa_CcFedCrvoHwIHiH3XW9yokzBt.wSQttWiC1K.1w8GtHKSjZi8EbuSwIgsrw84Lzu4PD rrcsrwhDjFI0JySQk3l8.IZ.Rv.IYhYT.a23_vc9m9c6jfixmyqlavTRpzjn9Hq5XDDLQPoMN4kd 2wXLqskSaBnRuv2Sahm1jowWtfKaBpn7MJkCtg4EE9ygyHlD64dHLt6Z3QqZA4QHEmyXUN70VVcg iEmhGNQBl Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 31 Jul 2018 19:04:51 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 09e8c7573ff9f8f46615093b850e6cf4; Tue, 31 Jul 2018 18:54:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <20180731181923.GC94742@www.zefox.net> Date: Tue, 31 Jul 2018 11:54:41 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <93D7A41F-3AFA-48FE-A82E-FC4AA76A355C@yahoo.com> References: <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> <20180731054712.GA92917@www.zefox.net> <20180731153531.GA94742@www.zefox.net> <908FB299-07CF-4E88-9C18-298CA357AD01@yahoo.com> <20180731181923.GC94742@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 19:05:02 -0000 On 2018-Jul-31, at 11:19 AM, bob prohaska wrote: > On Tue, Jul 31, 2018 at 10:51:51AM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2018-Jul-31, at 8:35 AM, bob prohaska = wrote: >>=20 >>> On Tue, Jul 31, 2018 at 10:31:33PM +1000, Trev wrote: >>>> bob prohaska wrote on 31/07/2018 15:47: >>>>=20 >>>>> It would be most interesting to see what happens if OOMA >>>>> could be turned off. Is that possible? >>>>=20 >>>> Possibly, but you might find you're treating the symptom(s) rather = than=20 >>>> the cause(s) ... something must be triggering the condition whether=20= >>>> correctly or not. >>>=20 >>> That's my point. To determine if OOMA is triggered correctly or not. = I'm starting >>> to think not. >>>=20 >>> The reason is the dependency on swap layout (mixed USB/microSD vs = all one or the >>> other) and the fact that OOMA kills don't seem to coincide with = periods of=20 >>> maximum storage read/write delay, which is the conventional = explanation for >>> why OOMA kills happen in the first place. If turning off OOMA allows = buildworld >>> to complete successfully it suggests OOMA isn't correctly = implemented.=20 >>=20 >> Your rpi2 report said: >>=20 >>> In this particular case all swap is on USB, in a single >>> 2 GB partition. >>=20 >> which for that example indicates that swap layout being split >> was not involved. (But there is the potential too-large issue.) >>=20 > That's true, I can't test mixed swap on that setup. My point was=20 > that formerly (months ago) 2GB of USB swap worked for -j4 buildworld. >=20 >> Have you had other examples of non-split swap layout getting >> OOMA kills? If yes, what types of contexts? [Especially any that >> do not have observed huge latencies or to evidence of device >> failures (retries required).] Any on rpi3? Any others on rpi2? >>=20 > Yes. Another storage configuration for the Pi3 (not installed=20 > at the moment) has three 1 GB swap partitions on USB and three > 1 GB swap partitions on microSD. In that case buildworld fails > from OOMA using 2 GB mixed or microSD swap but succeeds using=20 > USB swap. You seem to be indicating "one swap device" worked even with multiple swap partitions on the device, at least for the USB example. But you also have the example of a microsSD which got the OOMA activity with only one swap device in use (but multiple swap partitions on that device). Do you have examples that are multi-device swap but that do not involve that microSD? What was the mix of OOMA vs. it finishing for such example(s) (if any)? Can you attempt such tests with devices that seems to always work for "one swap device" tests? > That surprised me in that the microSD cards are the same. The USB=20 > device in that case is 3.0 vs 3.1, so different in some small way. >=20 >> As for swap use, do you have any tmpfs or other files systems >> that are memory based that also use swap if they grow too >> big (and are configured to allow such growth)? >>=20 > No memory-based filesystems in use.=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jul 31 19:10:02 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3535106234C for ; Tue, 31 Jul 2018 19:10:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 166B5780A5 for ; Tue, 31 Jul 2018 19:10:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6VJAHrt095359 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Jul 2018 12:10:18 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6VJAHqK095358; Tue, 31 Jul 2018 12:10:17 -0700 (PDT) (envelope-from fbsd) Date: Tue, 31 Jul 2018 12:10:16 -0700 From: bob prohaska To: "Rodney W. Grimes" Cc: bob prohaska , freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments Message-ID: <20180731191016.GD94742@www.zefox.net> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 19:10:02 -0000 On Tue, Jul 31, 2018 at 09:02:59AM -0700, Rodney W. Grimes wrote: > > An easy way of triggering OOM that I ran accross the other day is simply: > truncate -s 4G foo > grep Anything foo > > grep(1) well gladly grow up to 4G trying to create a "line" of text > to search for the string "Anything". On a system with less than > 4G of free memory this triggers an OOM and starts killing processes. > If grep actually uses 4GB before OOMA kills it then maybe OOMA is working correctly. Naive reasoning wonders why it would take that much memory to find an eight-character string, but that's not germane here. Unless, of course, buildworld is using grep in a similar way. What I'm seeing is OOMA kills that happen when swap usage is low, swap paritions don't seem overwhelmingly busy and read write delays are far less than maximums observed for the session. One possibility is that my gstat logs are not accurate measurements of storage activity. The logging script is #!/bin/sh while true do gstat -abd -I 10s ; date ; swapinfo ; tail -n 2 /var/log/messages done Does the script contain errors or omissions? In the most recent case the worst delays were 15 seconds for read and 38 seconds for write, OOMA didn't act until two hours later, when swap usage was only about 130 MB and write delay to swap was 135 ms. That's what tempts me to think the kills are an artifact of some other behavior. This is why I'd like to see what happens if OOMA could simply be turned off or its trigger level adjusted. On a Pi, bogging down for a few minutes during a buildworld session is perfectly ok. I appreciate that an e-commerce server or cloud computing system is a different kettle of fish entirely. Some weeks (months?) ago there was a thread about swap being broken. Was that in any way related to what I'm seeing? Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Tue Jul 31 19:19:34 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63FBF106281D for ; Tue, 31 Jul 2018 19:19:34 +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 CCB3178FEB for ; Tue, 31 Jul 2018 19:19:33 +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 8d920b94; Tue, 31 Jul 2018 21:19:25 +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=YmFGmPnM/BewFZ2pAqkXnUEofLc=; b=nfczisokVQpIOfpL4JHqTnSlwuMx CtTgFsJziJlyK2X0pkWTk/rdKjlQheZqsODAEfAunuKOtn7Hb6efzqOO2sqXVU56 45084uqYqT5mleT2TYJwXdSf1OReckMopLOcORYa4CYZ6LpCTFbQsPNOJH5ImeCI yg8gBDJqcgiG9e0= 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=cTYeZ023EiNwgdPocR+HDEjf4GCTUqdTCkPZGR8f8bM1jN8T2fSwlXBk aNQ85uljzStQo9vfclaUV2f8w3QFXTXRCPdX/V6lVIi4abrah5HjeTHSj0+qtKcB T5hWe7s4gH8GlV2oUMGpeiw5VQrP/P6wLU/UyT7Qz+0QxCMt2gY= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id e5439d17 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 31 Jul 2018 21:19:25 +0200 (CEST) Date: Tue, 31 Jul 2018 21:19:25 +0200 From: Emmanuel Vadot To: John-Mark Gurney Cc: Ulrich Grey , freebsd-arm@freebsd.org Subject: Re: Booting PINE64-LTS does not work Message-Id: <20180731211925.420d4068a8447c8dcbe8c0f0@bidouilliste.com> In-Reply-To: <20180731014832.GH2884@funkthat.com> References: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> <20180731014832.GH2884@funkthat.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 19:19:34 -0000 On Mon, 30 Jul 2018 18:48:32 -0700 John-Mark Gurney wrote: > Emmanuel Vadot wrote this message on Mon, Jul 30, 2018 at 20:31 +0200: > > Best way to use FreeBSD on Pine64-LTS is to download the Pine64 > > snapshot image and override u-boot with the u-boot-sopine. > > I'll second this. It works and is easy to do... the README has > slightly wrong file names, but it's easy enough to figure out which > one is correct... Fixed in r476018. > > Or wait until https://reviews.freebsd.org/D16487 is commited. > > Any specific reason that hasn't been yet? besides it being just > created? Commited in r337000. I always wait for someone from re@ for release/ related patches. > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Jul 31 20:46:03 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BA6D1064759 for ; Tue, 31 Jul 2018 20:46:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DC3CB7C0E8 for ; Tue, 31 Jul 2018 20:46:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6VKI9mc095514 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Jul 2018 13:18:10 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6VKI8Hq095513; Tue, 31 Jul 2018 13:18:08 -0700 (PDT) (envelope-from fbsd) Date: Tue, 31 Jul 2018 13:18:08 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments Message-ID: <20180731201808.GE94742@www.zefox.net> References: <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> <20180731054712.GA92917@www.zefox.net> <20180731153531.GA94742@www.zefox.net> <908FB299-07CF-4E88-9C18-298CA357AD01@yahoo.com> <20180731181923.GC94742@www.zefox.net> <93D7A41F-3AFA-48FE-A82E-FC4AA76A355C@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93D7A41F-3AFA-48FE-A82E-FC4AA76A355C@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 20:46:03 -0000 On Tue, Jul 31, 2018 at 11:54:41AM -0700, Mark Millard wrote: > > You seem to be indicating "one swap device" worked even with > multiple swap partitions on the device, at least for the USB > example. Yes, in both "all on USB" and "all on microSD" configurations, but it's not symmetric: One pair of storage devices will run -j4 buildworld with all swap on microSD but not with all swap on USB, the other pair runs -j4 buildworld with all swap on USB but not all swap on microSD. The microSD cards are marked the same, the USB devices are marked USB3.0 versus USB3.1 and the 3.1 devices is reported to be "slower" by some reviewers. That's the pair running now. > But you also have the example of a microsSD which got > the OOMA activity with only one swap device in use (but multiple > swap partitions on that device). > Yes. The storage pair containing the USB 3.0 flash drive will run -j4 buildworld with all swap on USB but will not with all swap on microSD. It also won't run with mixed swap, which was a surprise. My hope was to demonstrate that interleaving was somehow the culprit, but that backfired, since microSD alone failed too. I'm planning to switch back to the USB3.0 setup, just to eliminate one variable (out of far too many!) That storage pair has the most flexible swap partitioning and presumably better performance. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Tue Jul 31 20:50:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41D08106481B for ; Tue, 31 Jul 2018 20:50:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD0F87C1D4 for ; Tue, 31 Jul 2018 20:50:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: GHC41ZcVM1kJDg44jajtN9b1lH2KC0GVRL7gf6zYfGFk6JsCg_NQNJb9JaHm9dC A0wsHiRArVzT2s9JB5aHstOhJeufrX7tbi6KfIDBwySXuVMa4M9hybL8n0vHCAOhUyg3czTXZNu_ dA0VAFOqsHIjZYogdC8Vpdl.IcH5zLkf1wnnuu3gm7XgSsf30Pwn9hZkbkSJkP2no2SUK5mgCeq_ jjV_GbfOrfN3rEXTzRbxZQYk.E76YLZNb8tBvtkpGuQjje3eglwtJK4H1oRV6SGNL7CuC5OVt1S8 6Jn3fZk9CPuL7r.ABOiI07nJFMU9FNa9Qqk13niWEiGS09At33urQrrTwmvvBzCbm7FinVFWw5Ov wO_mBoKlx.x_kGDg5ZJEdl025VaQI9DNaef.ah50c9gL_2KJ8bG8NJjE4lXHSOMXIRPAhby1rB7v fcqpvMS8VCXw.tr5JlB9Dn5a7T3GpaF7iq8Hiva6oN4BImFUnwe_DEz_7zbFVZIq.uaW7LC3znmk 4r55DOFJngDvZsUICX2g97UtDuOYcYrWbEG9YcfPtY.iXEknUROOFDnRqeu9Xt8ppRwPgxYI8TVM AJjgkUAoqE1EJ3hhxNf4SFDoI5EhelXsbsprFqTonNI1AiF2DG07zqXlwSGv.DtXypiEOzP4gahz cEmBqlovu9YQfY07KMbHVsi7uBs7stOKd2VlVvhWeuFryJU0A8gsrnF7G4.aMFguwwHIC.ABdhfp CsfX619.8BH3fdyWOAHidSzmxuZFzlMcRaWMszH7VxWnAiRwUTG5d57AMNgMHGwQsvXNwpRsJrJo Q2L9mTnbIqJYtuYyBu2TNJ9dLa3oJudzbaAQbY3ddf.dS6MWFlNydw0v5iI2s6G33ZdfYMK3uXBI 8M1tqFpjAWcCsZ4bhsZz7g4eTij7kbi0E3T.cpGrSAm9Jr6Oh3.LjKIMprw_t3DmTyOEb_AefxVV EzzbRLTJ9.KYAKdZfapHT2B5hBXtlqDyKbJZYEaIrOZswkqbOPHVkBr6cg1nDmrYS9AmT1ABvncu kpUCkWxcoyg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 31 Jul 2018 20:50:03 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp428.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID cab5d4f075e47a2e0c3fed8f8e295e25; Tue, 31 Jul 2018 20:49:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <20180731191016.GD94742@www.zefox.net> Date: Tue, 31 Jul 2018 13:49:57 -0700 Cc: "Rodney W. Grimes" , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 20:50:05 -0000 On 2018-Jul-31, at 12:10 PM, bob prohaska wrote: > On Tue, Jul 31, 2018 at 09:02:59AM -0700, Rodney W. Grimes wrote: >>=20 >> An easy way of triggering OOM that I ran accross the other day is = simply: >> truncate -s 4G foo >> grep Anything foo >>=20 >> grep(1) well gladly grow up to 4G trying to create a "line" of text >> to search for the string "Anything". On a system with less than >> 4G of free memory this triggers an OOM and starts killing processes. >>=20 >=20 > If grep actually uses 4GB before OOMA kills it then maybe OOMA is = working > correctly. Naive reasoning wonders why it would take that much memory = to find > an eight-character string, but that's not germane here. Unless, of = course, > buildworld is using grep in a similar way.=20 >=20 > What I'm seeing is OOMA kills that happen when swap usage is low, swap > paritions don't seem overwhelmingly busy and read write delays are far = less > than maximums observed for the session.=20 >=20 > One possibility is that my gstat logs are not accurate measurements of > storage activity. The logging script is >=20 > #!/bin/sh > while true > do gstat -abd -I 10s ; date ; swapinfo ; tail -n 2 /var/log/messages=20= > done >=20 > Does the script contain errors or omissions? A sudden change is easily possible (sub-second by far). The scripting technique is not good at providing real-time information that is fairly detailed over an interval just before the OOMA starts up to it having started. I'm not aware of a good way to get such information over such an interval. The best I'm aware of is to change the initiation of the OOMA kills to dump out the information that could lead to the OOMA-kill-needed classification. (This might not tell how it progressed to that point, which might also be needed. ) ["Change" here might just be enabling some existing debug mode for all I know.] > In the most recent case the worst delays were 15 seconds for read and = 38=20 > seconds for write, OOMA didn't act until two hours later, when swap = usage > was only about 130 MB and write delay to swap was 135 ms. That's what = tempts > me to think the kills are an artifact of some other behavior.=20 >=20 > This is why I'd like to see what happens if OOMA could simply be = turned off > or its trigger level adjusted. On a Pi, bogging down for a few minutes = during > a buildworld session is perfectly ok. I appreciate that an e-commerce = server > or cloud computing system is a different kettle of fish entirely. At this point we have no clue just what internal tracking leads to the initiation of OOMA kills: no clue just what would be involved/appropriate. > Some weeks (months?) ago there was a thread about swap being broken. = Was > that in any way related to what I'm seeing? There was some ZFS context stuff that seemed to be independent of UFS stuff relative to memory use. I continue to see reports tied to ZFS contexts. But I'm not sure if this is in any way related to what you are calling "swap being broken". I do not remember anything about swap being directly broken for swap partitions. (Swap files are a different issue and are problematical.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jul 31 23:15:35 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44FFA1067E82 for ; Tue, 31 Jul 2018 23:15:35 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3A9282D7F for ; Tue, 31 Jul 2018 23:15:34 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w6VNFO86003776 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Jul 2018 16:15:24 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w6VNFNi8003775; Tue, 31 Jul 2018 16:15:23 -0700 (PDT) (envelope-from jmg) Date: Tue, 31 Jul 2018 16:15:23 -0700 From: John-Mark Gurney To: Emmanuel Vadot Cc: Ulrich Grey , freebsd-arm@freebsd.org Subject: Re: Booting PINE64-LTS does not work Message-ID: <20180731231523.GI2884@funkthat.com> Mail-Followup-To: Emmanuel Vadot , Ulrich Grey , freebsd-arm@freebsd.org References: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> <20180731014832.GH2884@funkthat.com> <20180731211925.420d4068a8447c8dcbe8c0f0@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180731211925.420d4068a8447c8dcbe8c0f0@bidouilliste.com> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Tue, 31 Jul 2018 16:15:24 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 23:15:35 -0000 Emmanuel Vadot wrote this message on Tue, Jul 31, 2018 at 21:19 +0200: > On Mon, 30 Jul 2018 18:48:32 -0700 > John-Mark Gurney wrote: > > > Emmanuel Vadot wrote this message on Mon, Jul 30, 2018 at 20:31 +0200: > > > Best way to use FreeBSD on Pine64-LTS is to download the Pine64 > > > snapshot image and override u-boot with the u-boot-sopine. > > > > I'll second this. It works and is easy to do... the README has > > slightly wrong file names, but it's easy enough to figure out which > > one is correct... > > Fixed in r476018. > > > > Or wait until https://reviews.freebsd.org/D16487 is commited. > > > > Any specific reason that hasn't been yet? besides it being just > > created? > > Commited in r337000. > I always wait for someone from re@ for release/ related patches. Thanks, makes sense. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Tue Jul 31 23:18:58 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D2991067EF9 for ; Tue, 31 Jul 2018 23:18:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ABD8382E1B for ; Tue, 31 Jul 2018 23:18:57 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6VNJD5q095948 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Jul 2018 16:19:13 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6VNJCgI095947; Tue, 31 Jul 2018 16:19:12 -0700 (PDT) (envelope-from fbsd) Date: Tue, 31 Jul 2018 16:19:12 -0700 From: bob prohaska To: Mark Millard Cc: "Rodney W. Grimes" , freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments Message-ID: <20180731231912.GF94742@www.zefox.net> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 23:18:58 -0000 On Tue, Jul 31, 2018 at 01:49:57PM -0700, Mark Millard wrote: > On 2018-Jul-31, at 12:10 PM, bob prohaska wrote: > > > > Some weeks (months?) ago there was a thread about swap being broken. Was > > that in any way related to what I'm seeing? > > There was some ZFS context stuff that seemed to be independent of > UFS stuff relative to memory use. I continue to see reports tied > to ZFS contexts. > > But I'm not sure if this is in any way related to what you are > calling "swap being broken". I do not remember anything about > swap being directly broken for swap partitions. (Swap files are > a different issue and are problematical.) > The thread I'm referring to starts with https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069728.html and titled " swapping is completely broken in -CURRENT r334649? " There's no mention whether ARM is affected, just "certain hardware". It looks like a bug was introduced in r329882 and fixed in r334752. Workarounds suggested include sysctl vm.pageout_update_period=0 and sysctl vm.pageout_update_period=1000. Maybe the first will turn OOMA off, and the second delay it? On RPi the value is 600. The one correspondent who tried 1000 said it didn't help, maybe zero is a better guess. For me it's a shot in total darkness either way 8-) Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Wed Aug 1 02:09:56 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8F9C106CDA8 for ; Wed, 1 Aug 2018 02:09:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74F2A8E588 for ; Wed, 1 Aug 2018 02:09:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: cxVoY2QVM1kUqaz.b6ZEtDbxgQUM6PlmWgIVnq3vxMt7eMLJT1MVZyv4Geo0ukX kUngLqr8ZDtAImF5ApAjFgfdttPsquJfHGviQrZCnZK7Jyu75FRWfn9UuH1xwjPqOZbzz3746MNp qJOEKiS2vMQukiXG5D8iD8HPekH7mbpse1SguO0097Q2U3dnY4R8O6Bm5FpwjGdrYxgSMWhHM4fW VFOLLpCTbgQZ9DTsZj5lSg14oXCgabLTlsNza.uIhVIDNUELoelEwe_Xo2lOIyA6DkrPHT52MolU kFdodWyHN40GAdcdNo_llef_yf1Tku9gyFiqDK0dlGJmLHhlJZYGgJA_i.JOrW8gxJ7lZRSqfmMz X1qxVvRGh7QR5GzqENB5tvkEdSWByvHThJbCA37v1kc6aBcr2ekygC.jh12VZ1nBbcgC4EP7XQ65 Lc51rZuXpj85t9AB8CjDP6hUh5rzJOIBohHq82vx2.rK9CycYnj54Qhrheuvdhk.ZgEEkgA5CCRw jlxWwyzhHr6OqC7L_WjTEGX4IwD0YRlaGOpF70468TLZS54NSWasym_wLym6G7FgzJFRiDafuwJ4 6vS_sVrGUcBqbEDJ_d.aGfJuAxBrkMxAhTg00r_kirQEoR1Rj2PPmTFvysPwEAEoMh0S5ntSv08w tN_Ms7OXWq0x1aiBWYd8yBAHdoWZNwNXPobB8_iRxg5wpj8DoDReDoLCVzV7vfxyMO.hpslPL6t2 a_dkr0F7Udf7vTUMSKHdxnQTsDTtRiwpMz4KquzIBGY8EbysJXoYpkXLlTKon.pjsoc5bI8.QOIm Q0fI4s_j7x2T3_aogmScGOCrQywC.baFKwkVPpNtTMFOl24NyHzo3Ys1ybJn9UurtddOPa0CaxKk 3Nb2_dz.6_vewcZf_uejyS9vLfMgwLSVwNMH_SaxMNnSrZMY_W5lNRJPFfI132owohKT0.DydEq3 PkzC.sUpnacfc7l7tR2KdosD2T3doENki2c1adR8Wvw9_6veOfihsHTvc1LDGWhW6Gm0LPiMw7th 0iZjrP45Atb0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 1 Aug 2018 02:09:47 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp424.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 63171a5e30b10ec42b4410fce2c6e214; Wed, 01 Aug 2018 02:09:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <20180731231912.GF94742@www.zefox.net> Date: Tue, 31 Jul 2018 19:09:43 -0700 Cc: "Rodney W. Grimes" , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 02:09:56 -0000 On 2018-Jul-31, at 4:19 PM, bob prohaska wrote: > On Tue, Jul 31, 2018 at 01:49:57PM -0700, Mark Millard wrote: >> On 2018-Jul-31, at 12:10 PM, bob prohaska = wrote: >>=20 >>=20 >>> Some weeks (months?) ago there was a thread about swap being broken. = Was >>> that in any way related to what I'm seeing? >>=20 >> There was some ZFS context stuff that seemed to be independent of >> UFS stuff relative to memory use. I continue to see reports tied >> to ZFS contexts. >>=20 >> But I'm not sure if this is in any way related to what you are >> calling "swap being broken". I do not remember anything about >> swap being directly broken for swap partitions. (Swap files are >> a different issue and are problematical.) >>=20 >=20 > The thread I'm referring to starts with=20 > = https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069728.html = and titled > " swapping is completely broken in -CURRENT r334649? " >=20 > There's no mention whether ARM is affected, just "certain hardware".=20= > It looks like a bug was introduced in r329882 and fixed in r334752. > Workarounds suggested include=20 > sysctl vm.pageout_update_period=3D0 > and > sysctl vm.pageout_update_period=3D1000.=20 >=20 > Maybe the first will turn OOMA off, and the second delay it?=20 > On RPi the value is 600. The one correspondent who tried 1000 > said it didn't help, maybe zero is a better guess. For me it's > a shot in total darkness either way 8-)=20 In that thread is the message: = https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069835.html that has a patch for dumping out more information to demsg before it does the kill: diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index 264c98203c51..9c7ebcf451ec 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1670,6 +1670,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, int = page_shortage, * start OOM. Initiate the selection and signaling of the * victim. */ + printf("v_free_count: %u, v_inactive_count: %u\n", + vmd->vmd_free_count, = vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt); vm_pageout_oom(VM_OOM_MEM); =20 /* Mark Johnston also mentions "sysctl vm" output as proving more contextual information. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Aug 1 03:44:57 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCA051045AF7 for ; Wed, 1 Aug 2018 03:44:57 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2794B716F9 for ; Wed, 1 Aug 2018 03:44:56 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w713jCrL096668 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Jul 2018 20:45:13 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w713jB89096667; Tue, 31 Jul 2018 20:45:11 -0700 (PDT) (envelope-from fbsd) Date: Tue, 31 Jul 2018 20:45:11 -0700 From: bob prohaska To: Mark Millard Cc: "Rodney W. Grimes" , freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments Message-ID: <20180801034511.GA96616@www.zefox.net> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 03:44:58 -0000 On Tue, Jul 31, 2018 at 07:09:43PM -0700, Mark Millard wrote: > > > On 2018-Jul-31, at 4:19 PM, bob prohaska wrote: > > > On Tue, Jul 31, 2018 at 01:49:57PM -0700, Mark Millard wrote: > >> On 2018-Jul-31, at 12:10 PM, bob prohaska wrote: > >> > >> > >>> Some weeks (months?) ago there was a thread about swap being broken. Was > >>> that in any way related to what I'm seeing? > >> > >> There was some ZFS context stuff that seemed to be independent of > >> UFS stuff relative to memory use. I continue to see reports tied > >> to ZFS contexts. > >> > >> But I'm not sure if this is in any way related to what you are > >> calling "swap being broken". I do not remember anything about > >> swap being directly broken for swap partitions. (Swap files are > >> a different issue and are problematical.) > >> > > > > The thread I'm referring to starts with > > https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069728.html and titled > > " swapping is completely broken in -CURRENT r334649? " > > > > There's no mention whether ARM is affected, just "certain hardware". > > It looks like a bug was introduced in r329882 and fixed in r334752. > > Workarounds suggested include > > sysctl vm.pageout_update_period=0 > > and > > sysctl vm.pageout_update_period=1000. > > > > Maybe the first will turn OOMA off, and the second delay it? > > On RPi the value is 600. The one correspondent who tried 1000 > > said it didn't help, maybe zero is a better guess. For me it's > > a shot in total darkness either way 8-) > > In that thread is the message: > > https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069835.html > > that has a patch for dumping out more information to demsg before > it does the kill: > > diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c > index 264c98203c51..9c7ebcf451ec 100644 > --- a/sys/vm/vm_pageout.c > +++ b/sys/vm/vm_pageout.c > @@ -1670,6 +1670,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, int page_shortage, > * start OOM. Initiate the selection and signaling of the > * victim. > */ > + printf("v_free_count: %u, v_inactive_count: %u\n", > + vmd->vmd_free_count, vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt); > vm_pageout_oom(VM_OOM_MEM); > > /* > > > Mark Johnston also mentions "sysctl vm" output as proving more > contextual information. > The significance of those lines isn't totally lost on me, but it's not obvious how to apply them. Any guidance appreciated! Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Wed Aug 1 04:01:26 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05EF61048132 for ; Wed, 1 Aug 2018 04:01:26 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (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 AE0B37220C for ; Wed, 1 Aug 2018 04:01:25 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w7141OKJ086678; Wed, 1 Aug 2018 05:01:24 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w7141N3H086677; Wed, 1 Aug 2018 05:01:23 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201808010401.w7141N3H086677@donotpassgo.dyslexicfish.net> Date: Wed, 01 Aug 2018 05:01:23 +0100 Organization: Dyslexic Fish To: marklmi@yahoo.com, fbsd@www.zefox.net Cc: freebsd-rwg@pdx.rh.CN85.dnsmgr.net, freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> In-Reply-To: <20180801034511.GA96616@www.zefox.net> 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 (donotpassgo.dyslexicfish.net [104.207.135.49]); Wed, 01 Aug 2018 05:01:24 +0100 (BST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 04:01:26 -0000 bob prohaska wrote: > The significance of those lines isn't totally lost on me, but > it's not obvious how to apply them. Any guidance appreciated! Hi Bob. Save the patch file somewhere, e.g. /tmp/patch then: cd /usr/src/sys/vm patch -l < /tmp/patch cd /usr/src remake the kernel, and reboot! cheers, Jamie From owner-freebsd-arm@freebsd.org Wed Aug 1 04:05:28 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E774310483CA for ; Wed, 1 Aug 2018 04:05:27 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (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 91B377236D for ; Wed, 1 Aug 2018 04:05:27 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w7145RWO086731; Wed, 1 Aug 2018 05:05:27 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w7145RS6086730; Wed, 1 Aug 2018 05:05:27 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> Date: Wed, 01 Aug 2018 05:05:27 +0100 Organization: Dyslexic Fish To: marklmi@yahoo.com, fbsd@www.zefox.net Cc: freebsd-rwg@pdx.rh.CN85.dnsmgr.net, freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> In-Reply-To: <20180801034511.GA96616@www.zefox.net> 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 (donotpassgo.dyslexicfish.net [104.207.135.49]); Wed, 01 Aug 2018 05:05:27 +0100 (BST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 04:05:28 -0000 bob prohaska wrote: > On Tue, Jul 31, 2018 at 07:09:43PM -0700, Mark Millard wrote: > > > > Mark Johnston also mentions "sysctl vm" output as proving more > > contextual information. > > > > The significance of those lines isn't totally lost on me, but > it's not obvious how to apply them. Any guidance appreciated! N.B. I know Mark just made a typo, but for info, It's actually "systat -vm" cheers, J From owner-freebsd-arm@freebsd.org Wed Aug 1 04:11:37 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 127A1104875E for ; Wed, 1 Aug 2018 04:11:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-30.consmr.mail.ne1.yahoo.com (sonic301-30.consmr.mail.ne1.yahoo.com [66.163.184.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D38372625 for ; Wed, 1 Aug 2018 04:11:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ePLBQ.oVM1lIlOmzU2CDlV9sU91kXpru0S4qxDTL4AZyI2jLgM7VSsTgZA9dFGL Wd54Wu6JZlQoToZRqHnvT5YpVoBLjELzd7caRirua6kd29CeDIgFmHmHyXMvBX.eHMOXWcSYODcy w111p8OBtEDf6aAM0flhUyV9UBomc6a7iwMIu6lYzkm8f5uM6Ns9ghypTUM9RSOrLSw6gR_ugtgA u0LGsfYTDhr3O9RUDleuj6buTX53sOh7isSZNGi643NqJUB7JHuzUsX2zhTPobELwRGcV6oi.ir6 T.WbQy707jMqJ3Q6UWVLsmSwahVfsRNTuERTfYt8onBsCSvd_4RaMvvPCI1h53ibx8khICnXeJ5f YWwhFdZk46skPdmuN_vUGNscL1FOlXVVNtXYCIYR2T97Y2u7zlSQurZ1oJupmibc2Xj0CuZmopwC IBqmyjCpw8_cbJ86RMixV0w0HlVkNpz5VVwZSrvqmNS9cdhwpesIeoOX8rYCyYcIGJAk6k3fsODo pDeONFov0kmljEZDtAVSOfxNQp7T0u.h1QhEdyxtu3va.NhLxPEejENF.YZ0uXeAfjHPImvUmfwa F9UbtHKGbR8Od8vIWlKlOgTFNOZGLiv275LdDGKLKU2ejl337EpBLg6k1HimZNfFbSgI8hqo_T1K kIIJZAdgODqzhrcUSW4n6IO40DrEyICYZMZxaeHpfxuoyeEudWkcf18nM620TMjyGzEUeSmc_UHA 6f.llX3VjBAREcsUHmPcxuJtnb1O2W0U.zg5bTOPLSwYJwVBFy0RcDyPlmgHQWPh43rTacropP_o NLY68y5mdCsfc6JXPA14Q4Sd.dNLjbQOFzKdYHcK4rsYMjTP3v68C1UrsPZFncDiQ2fFIUIpFcQv vo4kREEolZW18SX1tVVhu3eeqel2dBmjdlYNtlj33LClBfSiHubSelwtvxT1gOJY14XjO.S8AgmG 8dp0Xx21CevVlNH30vJhYHc8WBUt_Dp66Otpc_cTVC2d5o8PyKsQExsuQTSd_55MUr6QhOFcgf0K 4WpYKQt0p33E- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Wed, 1 Aug 2018 04:11:30 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp426.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d0027c247b65cc24ff74eb0699baa885; Wed, 01 Aug 2018 04:11:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> Date: Tue, 31 Jul 2018 21:11:26 -0700 Cc: fbsd@www.zefox.net, freebsd-rwg@pdx.rh.CN85.dnsmgr.net, freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> To: Jamie Landeg-Jones X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 04:11:37 -0000 On 2018-Jul-31, at 9:05 PM, Jamie Landeg-Jones wrote: > bob prohaska wrote: > >> On Tue, Jul 31, 2018 at 07:09:43PM -0700, Mark Millard wrote: >>> >>> Mark Johnston also mentions "sysctl vm" output as proving more >>> contextual information. >>> >> >> The significance of those lines isn't totally lost on me, but >> it's not obvious how to apply them. Any guidance appreciated! > > N.B. I know Mark just made a typo, but for info, It's actually "systat -vm" I do not expect so: Mark Johnston was likely correct . . . Here is an example of what "sysctl vm" reports (not from an rpi3 or rpi2 context): # sysctl vm vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 3 Disk Wait: 0 Page Wait: 0 Sleep: 87) Virtual Memory: (Total: 1488612K Active: 1407284K) Real Memory: (Total: 563000K Active: 558164K) Shared Virtual Memory: (Total: 92196K Active: 17316K) Shared Real Memory: (Total: 11004K Active: 6368K) Free Memory: 605944K vm.loadavg: { 3.01 4.87 6.85 } vm.v_free_min: 9627 vm.v_free_target: 32385 vm.v_free_reserved: 2041 vm.v_inactive_target: 48577 vm.v_pageout_free_min: 34 vm.swap_enabled: 1 vm.overcommit: 0 vm.domain.0.pidctrl.kdd: 8 vm.domain.0.pidctrl.kid: 4 vm.domain.0.pidctrl.kpd: 3 vm.domain.0.pidctrl.bound: 518160 vm.domain.0.pidctrl.interval: 10 vm.domain.0.pidctrl.setpoint: 32385 vm.domain.0.pidctrl.ticks: -2145424009 vm.domain.0.pidctrl.output: 0 vm.domain.0.pidctrl.input: 151503 vm.domain.0.pidctrl.derivative: 0 vm.domain.0.pidctrl.integral: 0 vm.domain.0.pidctrl.olderror: -119118 vm.domain.0.pidctrl.error: -119118 vm.domain.0.stats.free_severe: 5834 vm.domain.0.stats.free_min: 9627 vm.domain.0.stats.free_reserved: 2041 vm.domain.0.stats.free_target: 32385 vm.domain.0.stats.inactive_target: 48577 vm.domain.0.stats.unswappable: 0 vm.domain.0.stats.laundry: 5742 vm.domain.0.stats.inactive: 1052185 vm.domain.0.stats.active: 135574 vm.domain.0.stats.free_count: 151486 vm.kvm_free: 2197983064064 vm.kvm_size: 2199023251456 vm.pmap.pdpe.demotions: 0 vm.pmap.pde.promotions: 3254 vm.pmap.pde.p_failures: 545 vm.pmap.pde.mappings: 65 vm.pmap.pde.demotions: 544 vm.pmap.pcid_save_cnt: 65336953 vm.pmap.pti: 1 vm.pmap.invpcid_works: 1 vm.pmap.pcid_enabled: 1 vm.pmap.pg_ps_enabled: 1 vm.pmap.pat_works: 1 vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 vm.swap_idle_enabled: 0 vm.reserv.reclaimed: 156 vm.reserv.partpopq: DOMAIN LEVEL SIZE NUMBER 0, -1, 75560K, 41 vm.reserv.fullpop: 57 vm.reserv.freed: 219798 vm.reserv.broken: 156 vm.ndomains: 1 vm.phys_locality: 0: -1 vm.phys_segs: SEGMENT 0: start: 0x1000 end: 0x9f000 domain: 0 free list: 0xffffffff82852d30 SEGMENT 1: start: 0x103000 end: 0x200000 domain: 0 free list: 0xffffffff82852d30 SEGMENT 2: start: 0x200000 end: 0x1000000 domain: 0 free list: 0xffffffff82852d30 SEGMENT 3: start: 0x1000000 end: 0x2f66000 domain: 0 free list: 0xffffffff82852ac0 SEGMENT 4: start: 0x2f73000 end: 0x2fac000 domain: 0 free list: 0xffffffff82852ac0 SEGMENT 5: start: 0x3000000 end: 0xd562d000 domain: 0 free list: 0xffffffff82852ac0 SEGMENT 6: start: 0x100000000 end: 0x19ffe8000 domain: 0 free list: 0xffffffff82852ac0 vm.phys_free: DOMAIN 0: FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 -- -- -- -- -- -- 12 ( 16384K) | 0 | 0 11 ( 8192K) | 0 | 0 10 ( 4096K) | 0 | 0 9 ( 2048K) | 0 | 0 8 ( 1024K) | 0 | 0 7 ( 512K) | 0 | 0 6 ( 256K) | 0 | 0 5 ( 128K) | 103 | 43 4 ( 64K) | 4403 | 95 3 ( 32K) | 5840 | 112 2 ( 16K) | 1201 | 249 1 ( 8K) | 115 | 416 0 ( 4K) | 239 | 871 FREE LIST 1: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 -- -- -- -- -- -- 12 ( 16384K) | 0 | 0 11 ( 8192K) | 0 | 0 10 ( 4096K) | 0 | 0 9 ( 2048K) | 0 | 0 8 ( 1024K) | 0 | 0 7 ( 512K) | 1 | 0 6 ( 256K) | 2 | 0 5 ( 128K) | 2 | 0 4 ( 64K) | 2 | 0 3 ( 32K) | 1 | 0 2 ( 16K) | 1 | 0 1 ( 8K) | 1 | 0 0 ( 4K) | 2 | 0 vm.max_wired: 497115 vm.background_launder_max: 20480 vm.background_launder_rate: 4096 vm.act_scan_laundry_weight: 3 vm.pageout_oom_seq: 12 vm.pageout_lock_miss: 0 vm.disable_swapspace_pageouts: 0 vm.lowmem_period: 10 vm.pageout_update_period: 600 vm.panic_on_oom: 0 vm.page_blacklist: vm.tryrelock_restart: 263 vm.boot_pages: 6 vm.old_msync: 0 vm.old_mlock: 0 vm.stats.object.bypasses: 586213 vm.stats.object.collapses: 1826958 vm.stats.vm.v_tcached: 0 vm.stats.vm.v_cache_count: 0 vm.stats.vm.v_free_severe: 5834 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_laundry_count: 5741 vm.stats.vm.v_inactive_count: 1052185 vm.stats.vm.v_inactive_target: 48577 vm.stats.vm.v_active_count: 135573 vm.stats.vm.v_wire_count: 278033 vm.stats.vm.v_free_count: 151486 vm.stats.vm.v_free_min: 9627 vm.stats.vm.v_free_target: 32385 vm.stats.vm.v_free_reserved: 2041 vm.stats.vm.v_page_count: 1517488 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 114 vm.stats.vm.v_vforkpages: 49721622 vm.stats.vm.v_forkpages: 24418323 vm.stats.vm.v_kthreads: 24 vm.stats.vm.v_rforks: 2 vm.stats.vm.v_vforks: 270619 vm.stats.vm.v_forks: 634766 vm.stats.vm.v_tfree: 428360565 vm.stats.vm.v_pfree: 247353817 vm.stats.vm.v_dfree: 6766410 vm.stats.vm.v_pdshortfalls: 0 vm.stats.vm.v_pdpages: 14832514 vm.stats.vm.v_pdwakeups: 249 vm.stats.vm.v_reactivated: 379188 vm.stats.vm.v_intrans: 3403 vm.stats.vm.v_vnodepgsout: 1257759 vm.stats.vm.v_vnodepgsin: 611952 vm.stats.vm.v_vnodeout: 44317 vm.stats.vm.v_vnodein: 90033 vm.stats.vm.v_swappgsout: 2264 vm.stats.vm.v_swappgsin: 35 vm.stats.vm.v_swapout: 633 vm.stats.vm.v_swapin: 8 vm.stats.vm.v_ozfod: 28169 vm.stats.vm.v_zfod: 353095159 vm.stats.vm.v_cow_optim: 20637 vm.stats.vm.v_cow_faults: 22850387 vm.stats.vm.v_io_faults: 88884 vm.stats.vm.v_vm_faults: 385818918 vm.stats.sys.v_soft: 469272 vm.stats.sys.v_intr: 14185328 vm.stats.sys.v_syscall: 275196453 vm.stats.sys.v_trap: 387983799 vm.stats.sys.v_swtch: 102366146 vm.v_free_severe: 5834 vm.max_kernel_address: 18446744073709547520 vm.min_kernel_address: 18446741874686296064 vm.kstacks: 278 vm.kstack_cache_size: 128 vm.zone_warnings: 1 vm.zone_count: 124 vm.nswapdev: 1 vm.dmmax: 32 vm.swap_fragmentation: Free space on device gpt/FBSDUSSDswap: number of maximal free ranges: 5 largest free range: 3929888 average maximal free range size: 785979 number of maximal free ranges of different sizes: count | size range ----- | ---------- 3 | 2 1 | 3 to 4 1 | 3929888 vm.swap_async_max: 4 vm.swap_maxpages: 12140096 vm.swzone: 103190816 vm.swap_reserved: 1631981568 vm.swap_total: 16106127360 vm.phys_pager_cluster: 1024 vm.kmem_map_free: 5778546688 vm.kmem_map_size: 437084160 vm.kmem_size_scale: 1 vm.kmem_size_max: 1319413950874 vm.kmem_size_min: 0 vm.kmem_zmax: 65536 vm.kmem_size: 6215630848 vm.md_malloc_wait: 0 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Aug 1 04:15:22 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 436FC10488A5 for ; Wed, 1 Aug 2018 04:15:22 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (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 EAD497278C for ; Wed, 1 Aug 2018 04:15:21 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w714FLYN086999; Wed, 1 Aug 2018 05:15:21 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w714FL5j086998; Wed, 1 Aug 2018 05:15:21 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201808010415.w714FL5j086998@donotpassgo.dyslexicfish.net> Date: Wed, 01 Aug 2018 05:15:20 +0100 Organization: Dyslexic Fish To: marklmi@yahoo.com, jamie@catflap.org Cc: freebsd-rwg@pdx.rh.CN85.dnsmgr.net, freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> In-Reply-To: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> 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 (donotpassgo.dyslexicfish.net [104.207.135.49]); Wed, 01 Aug 2018 05:15:21 +0100 (BST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 04:15:22 -0000 Mark Millard via freebsd-arm wrote: > > N.B. I know Mark just made a typo, but for info, It's actually "systat -vm" > > I do not expect so: Mark Johnston was likely correct . . . > > Here is an example of what "sysctl vm" reports (not from an rpi3 > or rpi2 context): Sorry. Huge apologies. In my 5.13am-still-awake daze, I read 'sysctl' as 'systat' - a command I often use with "-vm". Bob, ignore my previous message. Cheers Mark for the quick corrrection, Jamie From owner-freebsd-arm@freebsd.org Wed Aug 1 05:37:59 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65082104AF86 for ; Wed, 1 Aug 2018 05:37:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB83979DB7 for ; Wed, 1 Aug 2018 05:37:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 7DzcgLIVM1kF5EAlq0IQub_aMjjPkvKkGpAjZRlDmzpg8ysaIxWJGJgoW2MiXeN bE6e78QZ1xOfPMISWqAVWkmrDlIwAduTmdfBEVNoqHIovRoTw5rTAiYGRc_Ti50uPtGIfqOXjOD6 5ozW6nOmICHkWPsrKo3ICinQwZVrg9KVQGl4o47bOyUVggyhdWvzAvs378a5_qpgG6G6FWwnAN_l plgtjd7OFjNoT.aYxanApjoWG.ftAFQHp4sYe78RVDP4gNdPcdjx3C09FxHrnXguKZjL4k0cDWVK ShfLQKWUyL7bLIo_wE6g5FBh1NI.DFBMcuZfWI1uPhOOOcfO.tNVs1.8kBddTT.QaZxGcWqOWQz0 n3OBbXl5PvzPR9xR.w4LiN3RLTsAFd2tyENNlac1.ibnvFQLsgoC1d4abce3QozY_diAOpfNujGs BqznqvAD27cVN7ZUg6MHzsoAh73VLXG.FCWcG438gNAIURR5lmzKbma1c6_v4MHTpczwevLTx9kn ouZIJxYFA33VXZ0Y8Ve.Ngg4lbT0m7t0hpuwRyxEb2l.LWoSfBp4l9VtoRt_jMNQEtwDtIRSKRDO cDNZRhbVDBNyL4Z.e5FFcV6maemY2aBYrDTZwJh5Dl6rhfMfnBdAvH6ymok0F33cYKllRb6w3XQE nC5URR9Wb7BNF6n6m1A2.OU1z5_c_EIQj3aUVC0cq8T68SfEo8KiETxA3cFL7rEw4R.YJG55fGgy tWwG.oZXZanner98RLxUSqUG5jl6ErIwa2BT1jK0yv7dh9ORiynHiRGDSt0tCuQsOOdZzLBYPiR1 BvfdUdrZWa98qssG3UB7tvtpshAtW9y9n2iThfr7bPHSlerD5_2O__3jPoeO0a9EM5A8UC3hdM_T 9_sAZRGm39LzvTxP9MF4j.1uUNGMiJ5UU9IH7rYjOtnIOKL_o6alAytw8IRveU7dojB0ZXPRyaXF KxlhmF4ZIT0xk0wBkMi.B16ibeHrJgivbP94vZ7Lv4MOZXNt.QMMPQBgDygvu0KqqaLMwaqwIl9A OBdh_Jeui9A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 1 Aug 2018 05:37:51 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp408.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 56f5cecac42fd550e8e34b9551ed5d11; Wed, 01 Aug 2018 05:37:48 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: poudriere-devel build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 failed Message-Id: <451D906A-3807-4029-BFFA-1A00AD8FB0F9@yahoo.com> Date: Tue, 31 Jul 2018 22:37:46 -0700 To: freebsd-arm , freebsd-uboot@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 05:37:59 -0000 [It will likely be some time before I'll be able to look into the cause of the below. After u-boot-pine64 failed the following succeeded during the same bulk build: sysutils/u-boot-rpi3 | u-boot-rpi3-2018.07_1 sysutils/u-boot-rpi2 | u-boot-rpi2-2018.07_1 sysutils/u-boot-sinovoip-bpi-m3 | u-boot-sinovoip-bpi-m3-2018.07_1 ] My attempt to update port packages based on -r476026 source code via poudriere-devel got: cc -Wp,-MD,scripts/dtc/.fstree.o.d -Wall -Wstrict-prototypes -O2 = -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/fstree.o scripts/dtc/fstree.c set -e; : ' CHK include/generated/generic-asm-offsets.h'; mkdir -p = include/generated/; (set -e; echo "#ifndef = __GENERIC_ASM_OFFSETS_H__"; echo "#define __GENERIC_ASM_OFFSETS_H__"; = echo "/*"; echo " * DO NOT MODIFY."; echo " *"; echo " * This file was = generated by Kbuild"; echo " */"; echo ""; sed -ne = "s:[[:space:]]*\.ascii[[:space:]]*\"\(.*\)\":\1:; /^->/{s:->#\(.*\):/* = \1 */:; s:^->\([^ ]*\) [\$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; = s:^->\([^ ]*\) [\$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; s:->::; = p;}"; echo ""; echo "#endif" ) < lib/asm-offsets.s > = include/generated/generic-asm-offsets.h.tmp; if [ -r = include/generated/generic-asm-offsets.h ] && cmp -s = include/generated/generic-asm-offsets.h = include/generated/generic-asm-offsets.h.tmp; then rm -f = include/generated/generic-asm-offsets.h.tmp; else : ' UPD = include/generated/generic-asm-offsets.h'; mv -f = include/generated/generic-asm-offsets.h.tmp = include/generated/generic-asm-offsets.h; fi cc -Wp,-MD,scripts/dtc/.data.o.d -Wall -Wstrict-prototypes -O2 = -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/data.o scripts/dtc/data.c if [ -d arch/arm/mach-sunxi/include/mach ]; then \ dest=3D../../mach-sunxi/include/mach; \ else \ dest=3Darch-sunxi; \ fi; \ ln -fsn $dest arch/arm/include/asm/arch fixdep: error opening config file: arch/arm/include/asm/arch/cpu.h: No = such file or directory set -e; : ' CHK include/config.h'; mkdir -p include/; (echo = "/* Automatically generated - do not edit */"; for i in $(echo "" | sed = 's/,/ /g'); do echo \#define CONFIG_$i | sed '/=3D/ {s/=3D/ /;q; } ; { = s/$/ 1/; }'; done; echo \#define CONFIG_BOARDDIR board/sunxi; echo = \#include \; echo \#include \; = echo \#include \; echo \#include \; = echo \#include \; echo \#include = \;) < scripts/Makefile.autoconf > = include/config.h.tmp; if [ -r include/config.h ] && cmp -s = include/config.h include/config.h.tmp; then rm -f include/config.h.tmp; = else : ' UPD include/config.h'; mv -f include/config.h.tmp = include/config.h; fi gmake[2]: *** [Kbuild:65: arch/arm/lib/asm-offsets.s] Error 2 gmake[1]: *** [Makefile:1434: prepare0] Error 2 gmake[1]: *** Waiting for unfinished jobs.... . . . cc -Wp,-MD,scripts/dtc/.dtc-lexer.lex.o.d -Wall -Wstrict-prototypes = -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/dtc-lexer.lex.o scripts/dtc/dtc-lexer.lex.c cc -Wp,-MD,scripts/dtc/.dtc-parser.tab.o.d -Wall -Wstrict-prototypes = -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/dtc-parser.tab.o scripts/dtc/dtc-parser.tab.c scripts/dtc/pylibfdt/libfdt_wrap.c:4656:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] fdt1 =3D fdt1; /* avoid unused variable warning */ ~~~~ ^ ~~~~ scripts/dtc/pylibfdt/libfdt_wrap.c:4681:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] fdt1 =3D fdt1; /* avoid unused variable warning */ ~~~~ ^ ~~~~ . . . scripts/dtc/pylibfdt/libfdt_wrap.c:8418:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] fdt1 =3D fdt1; /* avoid unused variable warning */ ~~~~ ^ ~~~~ scripts/dtc/pylibfdt/libfdt_wrap.c:8427:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] fdt2 =3D fdt2; /* avoid unused variable warning */ ~~~~ ^ ~~~~ cc -o scripts/dtc/dtc scripts/dtc/dtc.o scripts/dtc/flattree.o = scripts/dtc/fstree.o scripts/dtc/data.o scripts/dtc/livetree.o = scripts/dtc/treesource.o scripts/dtc/srcpos.o scripts/dtc/checks.o = scripts/dtc/util.o scripts/dtc/dtc-lexer.lex.o = scripts/dtc/dtc-parser.tab.o =20 98 warnings generated. gmake[1]: Leaving directory = '/wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07' =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/u-boot-pine64 =3D>> Cleaning up wrkdir =3D=3D=3D> Cleaning for u-boot-pine64-2018.07_1 build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 ended at Tue = Jul 31 20:27:47 PDT 2018 build time: 00:08:08 !!! build failure encountered !!! =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Aug 1 06:02:38 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3B7B104D134 for ; Wed, 1 Aug 2018 06:02:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-15.consmr.mail.bf2.yahoo.com (sonic311-15.consmr.mail.bf2.yahoo.com [74.6.131.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7664F7D963 for ; Wed, 1 Aug 2018 06:02:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: QjjW.p4VM1k3DqTd8D2ZCY1227RWe3BLWeI00gVhdtBmDJLfeIuBOgyyNNRH4uP RHMmN5.fQg7pjpWb9R72wVT.adLL.Of9nj2kqbzSr_Es_em6ZP82Y2d1P_1d1kVK3nGO4TzIL6W1 YLyB0iOVWx6XdtVoi3BlXP8AruUK9o_LE9eiCMY8N_uxVPiUWYwEW60XH3rJi064uQcW2pRAKomq sVWiUZhZZakqu18d46Fy7nZ71380LCgXFk1GWRhl4Pug35Zeg94GVVLXppFa6.XofZOtdXnvOh0t MREZEcTuEtloZcJB9NeyjXunLpsUNav24BbGDrC06n6IJocZCgly25ixwik9YoV08sC1sp_nZZ1X pEudCQKwUDicuOFZ8ZXJCxhuOCol6wqNPxjFmMaAaAZcL2_sNRozfUCHRi.msXSfRx0G8hVhDKOW ttB4v9qPZYU2TkaKnrNvKqGuX0OMI9O2uJO8dpeI7QRGJ8GEoAlG4769XQD724V0ducHFPdREj4s HIPvLJFvxzLDmtoGJuE9IGJF9AxD0yTVgv.epeXG6Ys2dWAZK1s.S8bDBy79SyWSfhtsvTPFF9JX X7bQpda357E0qXRPqimFllZ0EFIPhbkLSz8A5PiU1kDdlhHR4QCLlfXHtSf_.zsKSnrDxVeXH.gt xuu_Pp0sfX6xEgI38TqWOWLB7uLPH36QDm1nrVxqJidmB15AW3K4ywL4aCiTEOvdV3qOq11dpL4W qmZ5adAu5RBpPgEVjK614pNgu2MXOTb4JP8zj66k4qYpXwjDBwI9eVNPBM4n80_DsjRGCKpkgkxk ZlQ7bzWrNV_7c.2TO0fb31T0Y96Ofyp6detQEprEmDPvb7Z_1ZVajfMJ7t1pj0JHPqa63V4fpLq8 JmfuRrcJk5AtNNVzEQjJN6aMqVBO_CitcdkfhH_SggyOpMEqPzV1Z4KoIdsSW7c8MjoeqOen9fgI ex4iFJkCpdEX1lOfmlhkvSTjWV5OX0CZ4g8rRm.6NvkUo5FVNOCh3LhJFLsNQz8fRo_hRXeacwuo - Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Wed, 1 Aug 2018 06:02:29 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp424.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c81dd212f71be84bb38bd12a89235462; Wed, 01 Aug 2018 06:02:29 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: poudriere-devel build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 failed Date: Tue, 31 Jul 2018 23:02:27 -0700 References: <451D906A-3807-4029-BFFA-1A00AD8FB0F9@yahoo.com> To: freebsd-arm , freebsd-uboot@freebsd.org In-Reply-To: <451D906A-3807-4029-BFFA-1A00AD8FB0F9@yahoo.com> Message-Id: <6D377AEB-C359-4DC3-A95F-2A4A72CBF090@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 06:02:38 -0000 On 2018-Jul-31, at 10:37 PM, Mark Millard wrote: > [It will likely be some time before I'll be able to look into > the cause of the below. After u-boot-pine64 failed the following > succeeded during the same bulk build: > sysutils/u-boot-rpi3 | u-boot-rpi3-2018.07_1 > sysutils/u-boot-rpi2 | u-boot-rpi2-2018.07_1 > sysutils/u-boot-sinovoip-bpi-m3 | u-boot-sinovoip-bpi-m3-2018.07_1 > ] >=20 > My attempt to update port packages based on -r476026 source code > via poudriere-devel got: >=20 > cc -Wp,-MD,scripts/dtc/.fstree.o.d -Wall -Wstrict-prototypes -O2 = -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/fstree.o scripts/dtc/fstree.c > set -e; : ' CHK include/generated/generic-asm-offsets.h'; mkdir = -p include/generated/; (set -e; echo "#ifndef = __GENERIC_ASM_OFFSETS_H__"; echo "#define __GENERIC_ASM_OFFSETS_H__"; = echo "/*"; echo " * DO NOT MODIFY."; echo " *"; echo " * This file was = generated by Kbuild"; echo " */"; echo ""; sed -ne = "s:[[:space:]]*\.ascii[[:space:]]*\"\(.*\)\":\1:; /^->/{s:->#\(.*\):/* = \1 */:; s:^->\([^ ]*\) [\$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; = s:^->\([^ ]*\) [\$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; s:->::; = p;}"; echo ""; echo "#endif" ) < lib/asm-offsets.s > = include/generated/generic-asm-offsets.h.tmp; if [ -r = include/generated/generic-asm-offsets.h ] && cmp -s = include/generated/generic-asm-offsets.h = include/generated/generic-asm-offsets.h.tmp; then rm -f = include/generated/generic-asm-offsets.h.tmp; else : ' UPD = include/generated/generic-asm-offsets.h'; mv -f = include/generated/generic-asm-offsets.h.tmp = include/generated/generic-asm-offsets.h; fi > cc -Wp,-MD,scripts/dtc/.data.o.d -Wall -Wstrict-prototypes -O2 = -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/data.o scripts/dtc/data.c > if [ -d arch/arm/mach-sunxi/include/mach ]; then \ > dest=3D../../mach-sunxi/include/mach; \ > else \ > dest=3Darch-sunxi; \ > fi; \ > ln -fsn $dest arch/arm/include/asm/arch > fixdep: error opening config file: arch/arm/include/asm/arch/cpu.h: No = such file or directory > set -e; : ' CHK include/config.h'; mkdir -p include/; (echo = "/* Automatically generated - do not edit */"; for i in $(echo "" | sed = 's/,/ /g'); do echo \#define CONFIG_$i | sed '/=3D/ {s/=3D/ /;q; } ; { = s/$/ 1/; }'; done; echo \#define CONFIG_BOARDDIR board/sunxi; echo = \#include \; echo \#include \; = echo \#include \; echo \#include \; = echo \#include \; echo \#include = \;) < scripts/Makefile.autoconf > = include/config.h.tmp; if [ -r include/config.h ] && cmp -s = include/config.h include/config.h.tmp; then rm -f include/config.h.tmp; = else : ' UPD include/config.h'; mv -f include/config.h.tmp = include/config.h; fi > gmake[2]: *** [Kbuild:65: arch/arm/lib/asm-offsets.s] Error 2 > gmake[1]: *** [Makefile:1434: prepare0] Error 2 > gmake[1]: *** Waiting for unfinished jobs.... >=20 > . . . >=20 > cc -Wp,-MD,scripts/dtc/.dtc-lexer.lex.o.d -Wall -Wstrict-prototypes = -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/dtc-lexer.lex.o scripts/dtc/dtc-lexer.lex.c > cc -Wp,-MD,scripts/dtc/.dtc-parser.tab.o.d -Wall -Wstrict-prototypes = -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/dtc-parser.tab.o scripts/dtc/dtc-parser.tab.c > scripts/dtc/pylibfdt/libfdt_wrap.c:4656:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] > fdt1 =3D fdt1; /* avoid unused variable warning */ > ~~~~ ^ ~~~~ > scripts/dtc/pylibfdt/libfdt_wrap.c:4681:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] > fdt1 =3D fdt1; /* avoid unused variable warning */ > ~~~~ ^ ~~~~ >=20 > . . . >=20 > scripts/dtc/pylibfdt/libfdt_wrap.c:8418:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] > fdt1 =3D fdt1; /* avoid unused variable warning */ > ~~~~ ^ ~~~~ > scripts/dtc/pylibfdt/libfdt_wrap.c:8427:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] > fdt2 =3D fdt2; /* avoid unused variable warning */ > ~~~~ ^ ~~~~ > cc -o scripts/dtc/dtc scripts/dtc/dtc.o scripts/dtc/flattree.o = scripts/dtc/fstree.o scripts/dtc/data.o scripts/dtc/livetree.o = scripts/dtc/treesource.o scripts/dtc/srcpos.o scripts/dtc/checks.o = scripts/dtc/util.o scripts/dtc/dtc-lexer.lex.o = scripts/dtc/dtc-parser.tab.o =20 > 98 warnings generated. > gmake[1]: Leaving directory = '/wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07' > =3D=3D=3D> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to > the maintainer. > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/sysutils/u-boot-pine64 > =3D>> Cleaning up wrkdir > =3D=3D=3D> Cleaning for u-boot-pine64-2018.07_1 > build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 ended at Tue = Jul 31 20:27:47 PDT 2018 > build time: 00:08:08 > !!! build failure encountered !!! >=20 FYI (from expansing the .tbz): # find /wrkdirs/usr/ports/sysutils/u-boot-pine64/ -name "cpu*.h" | more = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/cpu= /armv8/fsl-layerscape/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/cpu= /armv8/s32v234/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-am33xx/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-armada100/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-fsl-layerscape/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-imx/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-lpc32xx/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-omap3/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-omap4/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-omap5/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpu_sun4i.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpu_sun9i.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpucfg.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-exynos/include/mach/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-kirkwood/include/mach/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-mvebu/include/mach/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-orion5x/include/mach/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-s5pc1xx/include/mach/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-tegra/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/m68k/cp= u/mcf52x2/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/mips/in= clude/asm/cpu-features.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/mips/in= clude/asm/mach-generic/cpu-feature-overrides.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh2.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh3.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh4.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7203.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7264.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7269.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7706.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7710.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7720.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7722.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7723.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7724.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7734.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7750.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7752.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7753.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7757.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7763.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7780.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/incl= ude/asm/cpu_sh7785.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/x86/inc= lude/asm/arch-broadwell/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/x86/inc= lude/asm/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/x86/inc= lude/asm/cpu_common.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/x86/inc= lude/asm/cpu_x86.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/cpu.= h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/conf= ig/display/cpuinfo.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/conf= ig/sys/cpu.h = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/post/lib_pow= erpc/cpu_asm.h It makes me wonder if the failing: fixdep: error opening config file: arch/arm/include/asm/arch/cpu.h: No = such file or directory was supposed to reference: = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpu.h Looking . . . # more = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpu.h /* SPDX-License-Identifier: GPL-2.0+ */ /* * (C) Copyright 2015 Hans de Goede */ #ifndef _SUNXI_CPU_H #define _SUNXI_CPU_H #if defined(CONFIG_MACH_SUN9I) #include #else #include #endif #define SOCID_A64 0x1689 #define SOCID_H3 0x1680 #define SOCID_H5 0x1718 #define SOCID_R40 0x1701 #endif /* _SUNXI_CPU_H */ =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Aug 1 07:59:46 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DAF3105D241; Wed, 1 Aug 2018 07:59:46 +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 AECC387211; Wed, 1 Aug 2018 07:59:45 +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 3b7e4117; Wed, 1 Aug 2018 09:59:43 +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=xSFWKXD/NKDhVemKn1/7yyxBuHU=; b=rLgK2nIFWsf64Fk+Msvb/YhuMF5R GxgRYu1d5mcW6mWYT/mPOetgPVBqPHbw7BuvNxLN7g8Mf4fyZpmilIofPD5QjYgu c6vpWs3xaJ6agxJ6+sEY+161NzNXGCU9+zXikZzsLnzfUy4I90nLwcdlq8UcSMpv rFQkRvUHhsM6OAU= 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=Pxgxu+Nkc34KuChR/88DpGu45yZpd1UqtROZRiKa88nJerCtThrW2xkY s2ths24bfCWwvnMg2XuJ5EFWuRAyKQDM+b/uj7556uBOtuvk97CNVynH5a6wbfnh 5aQ4cDAwIHAa55sg+TV9ldft0L4soc8XxHcY/Dot2vjRY8HvJXM= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 33dd166a TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 1 Aug 2018 09:59:43 +0200 (CEST) Date: Wed, 1 Aug 2018 09:59:42 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Mark Millard via freebsd-arm , freebsd-uboot@freebsd.org Subject: Re: poudriere-devel build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 failed Message-Id: <20180801095942.91dfc4d5907b75b4fe63c1d0@bidouilliste.com> In-Reply-To: <6D377AEB-C359-4DC3-A95F-2A4A72CBF090@yahoo.com> References: <451D906A-3807-4029-BFFA-1A00AD8FB0F9@yahoo.com> <6D377AEB-C359-4DC3-A95F-2A4A72CBF090@yahoo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 07:59:46 -0000 On Tue, 31 Jul 2018 23:02:27 -0700 Mark Millard via freebsd-arm wrote: > On 2018-Jul-31, at 10:37 PM, Mark Millard wrote: > > > [It will likely be some time before I'll be able to look into > > the cause of the below. After u-boot-pine64 failed the following > > succeeded during the same bulk build: > > sysutils/u-boot-rpi3 | u-boot-rpi3-2018.07_1 > > sysutils/u-boot-rpi2 | u-boot-rpi2-2018.07_1 > > sysutils/u-boot-sinovoip-bpi-m3 | u-boot-sinovoip-bpi-m3-2018.07_1 > > ] > > > > My attempt to update port packages based on -r476026 source code > > via poudriere-devel got: > > > > cc -Wp,-MD,scripts/dtc/.fstree.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o scripts/dtc/fstree.o scripts/dtc/fstree.c > > set -e; : ' CHK include/generated/generic-asm-offsets.h'; mkdir -p include/generated/; (set -e; echo "#ifndef __GENERIC_ASM_OFFSETS_H__"; echo "#define __GENERIC_ASM_OFFSETS_H__"; echo "/*"; echo " * DO NOT MODIFY."; echo " *"; echo " * This file was generated by Kbuild"; echo " */"; echo ""; sed -ne "s:[[:space:]]*\.ascii[[:space:]]*\"\(.*\)\":\1:; /^->/{s:->#\(.*\):/* \1 */:; s:^->\([^ ]*\) [\$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; s:^->\([^ ]*\) [\$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; s:->::; p;}"; echo ""; echo "#endif" ) < lib/asm-offsets.s > include/generated/generic-asm-offsets.h.tmp; if [ -r include/generated/generic-asm-offsets.h ] && cmp -s include/generated/generic-asm-offsets.h include/generated/generic-asm-offsets.h.tmp; then rm -f include/generated/generic-asm-offsets.h.tmp; else : ' UPD include/generated/generic-asm-offsets.h'; mv -f include/generated/generic-asm-offsets.h.tmp include/generated/generic-asm-offsets.h; fi > > cc -Wp,-MD,scripts/dtc/.data.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o scripts/dtc/data.o scripts/dtc/data.c > > if [ -d arch/arm/mach-sunxi/include/mach ]; then \ > > dest=../../mach-sunxi/include/mach; \ > > else \ > > dest=arch-sunxi; \ > > fi; \ > > ln -fsn $dest arch/arm/include/asm/arch > > fixdep: error opening config file: arch/arm/include/asm/arch/cpu.h: No such file or directory > > set -e; : ' CHK include/config.h'; mkdir -p include/; (echo "/* Automatically generated - do not edit */"; for i in $(echo "" | sed 's/,/ /g'); do echo \#define CONFIG_$i | sed '/=/ {s/=/ /;q; } ; { s/$/ 1/; }'; done; echo \#define CONFIG_BOARDDIR board/sunxi; echo \#include \; echo \#include \; echo \#include \; echo \#include \; echo \#include \; echo \#include \;) < scripts/Makefile.autoconf > include/config.h.tmp; if [ -r include/config.h ] && cmp -s include/config.h include/config.h.tmp; then rm -f include/config.h.tmp; else : ' UPD include/config.h'; mv -f include/config.h.tmp include/config.h; fi > > gmake[2]: *** [Kbuild:65: arch/arm/lib/asm-offsets.s] Error 2 > > gmake[1]: *** [Makefile:1434: prepare0] Error 2 > > gmake[1]: *** Waiting for unfinished jobs.... > > > > . . . > > > > cc -Wp,-MD,scripts/dtc/.dtc-lexer.lex.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o scripts/dtc/dtc-lexer.lex.o scripts/dtc/dtc-lexer.lex.c > > cc -Wp,-MD,scripts/dtc/.dtc-parser.tab.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o scripts/dtc/dtc-parser.tab.o scripts/dtc/dtc-parser.tab.c > > scripts/dtc/pylibfdt/libfdt_wrap.c:4656:10: warning: explicitly assigning value of variable of type 'const void *' to itself [-Wself-assign] > > fdt1 = fdt1; /* avoid unused variable warning */ > > ~~~~ ^ ~~~~ > > scripts/dtc/pylibfdt/libfdt_wrap.c:4681:10: warning: explicitly assigning value of variable of type 'const void *' to itself [-Wself-assign] > > fdt1 = fdt1; /* avoid unused variable warning */ > > ~~~~ ^ ~~~~ > > > > . . . > > > > scripts/dtc/pylibfdt/libfdt_wrap.c:8418:10: warning: explicitly assigning value of variable of type 'const void *' to itself [-Wself-assign] > > fdt1 = fdt1; /* avoid unused variable warning */ > > ~~~~ ^ ~~~~ > > scripts/dtc/pylibfdt/libfdt_wrap.c:8427:10: warning: explicitly assigning value of variable of type 'const void *' to itself [-Wself-assign] > > fdt2 = fdt2; /* avoid unused variable warning */ > > ~~~~ ^ ~~~~ > > cc -o scripts/dtc/dtc scripts/dtc/dtc.o scripts/dtc/flattree.o scripts/dtc/fstree.o scripts/dtc/data.o scripts/dtc/livetree.o scripts/dtc/treesource.o scripts/dtc/srcpos.o scripts/dtc/checks.o scripts/dtc/util.o scripts/dtc/dtc-lexer.lex.o scripts/dtc/dtc-parser.tab.o > > 98 warnings generated. > > gmake[1]: Leaving directory '/wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07' > > ===> Compilation failed unexpectedly. > > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > > the maintainer. > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/ports/sysutils/u-boot-pine64 > > =>> Cleaning up wrkdir > > ===> Cleaning for u-boot-pine64-2018.07_1 > > build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 ended at Tue Jul 31 20:27:47 PDT 2018 > > build time: 00:08:08 > > !!! build failure encountered !!! > > > > FYI (from expansing the .tbz): > > # find /wrkdirs/usr/ports/sysutils/u-boot-pine64/ -name "cpu*.h" | more > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/cpu/armv8/fsl-layerscape/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/cpu/armv8/s32v234/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-am33xx/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-armada100/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-fsl-layerscape/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-imx/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-lpc32xx/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-omap3/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-omap4/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-omap5/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpucfg.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-exynos/include/mach/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-kirkwood/include/mach/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-mvebu/include/mach/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-orion5x/include/mach/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-s5pc1xx/include/mach/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-tegra/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/m68k/cpu/mcf52x2/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/mips/include/asm/cpu-features.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/mips/include/asm/mach-generic/cpu-feature-overrides.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh2.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh3.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh4.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7203.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7264.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7269.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7706.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7710.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7720.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7722.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7723.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7724.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7734.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7750.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7752.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7753.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7757.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7763.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7780.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/sh/include/asm/cpu_sh7785.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/x86/include/asm/arch-broadwell/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/x86/include/asm/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/x86/include/asm/cpu_common.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/x86/include/asm/cpu_x86.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/config/display/cpuinfo.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/config/sys/cpu.h > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/post/lib_powerpc/cpu_asm.h > > It makes me wonder if the failing: > > fixdep: error opening config file: arch/arm/include/asm/arch/cpu.h: No such file or directory > > was supposed to reference: > > /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpu.h > > Looking . . . > > # more /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpu.h > /* SPDX-License-Identifier: GPL-2.0+ */ > /* > * (C) Copyright 2015 Hans de Goede > */ > > #ifndef _SUNXI_CPU_H > #define _SUNXI_CPU_H > > #if defined(CONFIG_MACH_SUN9I) > #include > #else > #include > #endif > > #define SOCID_A64 0x1689 > #define SOCID_H3 0x1680 > #define SOCID_H5 0x1718 > #define SOCID_R40 0x1701 > > #endif /* _SUNXI_CPU_H */ > > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Again too much context for unneeded stuff and no context at all for what matters. Are you familiar with Aesop fable "The Shepherd's Boy and the Wolf" ? One day you will report something important but no one will listen to you. Anyhow, I've just build succesfully u-boot-pine64 with poudriere and poudriere-devel from package on my amd64 box. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Aug 1 14:02:16 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA41D105D2A9 for ; Wed, 1 Aug 2018 14:02:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-13.consmr.mail.bf2.yahoo.com (sonic311-13.consmr.mail.bf2.yahoo.com [74.6.131.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 004997534D for ; Wed, 1 Aug 2018 14:02:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: VGVbnywVM1k.aZkDgUGX6r..GN0tONty0CMIg3PvBXZoRtwj52y6BeDdmiUG.Y_ JaOT9rsmB5k_zcSaSkf69TfsldjNiapuLvWk_ILW2T5OYrlMMnLeRfiKtS2AReIF8F_76FqfYZm5 0rq8EApGxFCp_q56opHeLmZ0NQO8JSIVGvrUUkR3Zudq6.7dJCEfLHT2i6C3e0W_mYniDZ7rp6bO WUjXtk2wrxSC0wCD22XfixjcWgOnIIf__cdDYSDPj9sfHf56YEwQOj4RYWxlMr_.cfY3Z.fc2GzO 0yb84tqoRxHaU4JULav7zFv907D1sCDmP_1yLb.OJGYApQdnZwTxvmUYSbVcpm6lp8gN6AmkntJh 1K2kIRGnxxI22Tz57SvpiB.O0lLDXBzJFgmHKXDSmoslfg1jvy.xM_QXjorgufYqjn48A4dVtSKV 3bYjjW_VnDypqfieGunKuS17LzmrDY1L.G8vZao7OGw2GRN.WvSczKnp_091RvzXRcTWb53F1OYk 8SgUjA_lCd0lOXaHf5.aNj6OW8s2sxVJ9mlZZoAkvM7QHqJzXQgmk.difGM4UzXLrMkUqPcn1y0N 6M959d8PyG4t2_t.v0hKQHSFdyXWnF.I6UySVJlcDdJNIPB13ZybdCQm1Mou3arQH8X5MAz_DQI8 q5DFyl_m5n_IikWRdJ7tWCb8yilbGtoYwcjnrg1qKI2pZE_kzIGa1d0Y2eWrEF0cM0E6RJsk8PT5 qs5laQGFojSe3P4iEimF67.vAh4TdrAqJuSULAwPrIr.eeodTJc1PHJi_HQmm6Oz2yXaerzBtJU4 AMDf2ckGAV2D4UvoINDl.E1r1G7_QKSNlMFxTEOsxHLv8hpnbw1auHmyU5.fHxD6cCIvuHj3Tz.n EX.yVYiwUM_nfqPi6oIdlsaeIi2r5mSob9QTYJIOIZx_wu_UT8lUSkBmm1Rd.LO3TOXdrmdMfxz1 QbZIGgzh_xzk1DjoGMCp92tvooGlGNx0w.MAmWUAS7hd_w2oBB5V4eeUNk1WNq40O.Qln6iJyV2c - Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Wed, 1 Aug 2018 14:02:15 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp405.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 48e8db11d29acb9ed99a9795cbbe6763; Wed, 01 Aug 2018 14:02:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: poudriere-devel build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 failed From: Mark Millard In-Reply-To: <20180801095942.91dfc4d5907b75b4fe63c1d0@bidouilliste.com> Date: Wed, 1 Aug 2018 07:02:08 -0700 Cc: freebsd-uboot@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <451D906A-3807-4029-BFFA-1A00AD8FB0F9@yahoo.com> <6D377AEB-C359-4DC3-A95F-2A4A72CBF090@yahoo.com> <20180801095942.91dfc4d5907b75b4fe63c1d0@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 14:02:16 -0000 On 2018-Aug-1, at 12:59 AM, Emmanuel Vadot = wrote: > On Tue, 31 Jul 2018 23:02:27 -0700 > Mark Millard via freebsd-arm wrote: >=20 >> On 2018-Jul-31, at 10:37 PM, Mark Millard = wrote: >>=20 >>> [It will likely be some time before I'll be able to look into >>> the cause of the below. After u-boot-pine64 failed the following >>> succeeded during the same bulk build: >>> sysutils/u-boot-rpi3 | u-boot-rpi3-2018.07_1 >>> sysutils/u-boot-rpi2 | u-boot-rpi2-2018.07_1 >>> sysutils/u-boot-sinovoip-bpi-m3 | u-boot-sinovoip-bpi-m3-2018.07_1 >>> ] >>>=20 >>> My attempt to update port packages based on -r476026 source code >>> via poudriere-devel got: >>>=20 >>> cc -Wp,-MD,scripts/dtc/.fstree.o.d -Wall -Wstrict-prototypes -O2 = -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/fstree.o scripts/dtc/fstree.c >>> set -e; : ' CHK include/generated/generic-asm-offsets.h'; mkdir = -p include/generated/; (set -e; echo "#ifndef = __GENERIC_ASM_OFFSETS_H__"; echo "#define __GENERIC_ASM_OFFSETS_H__"; = echo "/*"; echo " * DO NOT MODIFY."; echo " *"; echo " * This file was = generated by Kbuild"; echo " */"; echo ""; sed -ne = "s:[[:space:]]*\.ascii[[:space:]]*\"\(.*\)\":\1:; /^->/{s:->#\(.*\):/* = \1 */:; s:^->\([^ ]*\) [\$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; = s:^->\([^ ]*\) [\$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; s:->::; = p;}"; echo ""; echo "#endif" ) < lib/asm-offsets.s > = include/generated/generic-asm-offsets.h.tmp; if [ -r = include/generated/generic-asm-offsets.h ] && cmp -s = include/generated/generic-asm-offsets.h = include/generated/generic-asm-offsets.h.tmp; then rm -f = include/generated/generic-asm-offsets.h.tmp; else : ' UPD = include/generated/generic-asm-offsets.h'; mv -f = include/generated/generic-asm-offsets.h.tmp = include/generated/generic-asm-offsets.h; fi >>> cc -Wp,-MD,scripts/dtc/.data.o.d -Wall -Wstrict-prototypes -O2 = -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/data.o scripts/dtc/data.c >>> if [ -d arch/arm/mach-sunxi/include/mach ]; then \ >>> dest=3D../../mach-sunxi/include/mach; \ >>> else \ >>> dest=3Darch-sunxi; \ >>> fi; \ >>> ln -fsn $dest arch/arm/include/asm/arch >>> fixdep: error opening config file: arch/arm/include/asm/arch/cpu.h: = No such file or directory >>> set -e; : ' CHK include/config.h'; mkdir -p include/; = (echo "/* Automatically generated - do not edit */"; for i in $(echo "" = | sed 's/,/ /g'); do echo \#define CONFIG_$i | sed '/=3D/ {s/=3D/ /;q; = } ; { s/$/ 1/; }'; done; echo \#define CONFIG_BOARDDIR board/sunxi; echo = \#include \; echo \#include \; = echo \#include \; echo \#include \; = echo \#include \; echo \#include = \;) < scripts/Makefile.autoconf > = include/config.h.tmp; if [ -r include/config.h ] && cmp -s = include/config.h include/config.h.tmp; then rm -f include/config.h.tmp; = else : ' UPD include/config.h'; mv -f include/config.h.tmp = include/config.h; fi >>> gmake[2]: *** [Kbuild:65: arch/arm/lib/asm-offsets.s] Error 2 >>> gmake[1]: *** [Makefile:1434: prepare0] Error 2 >>> gmake[1]: *** Waiting for unfinished jobs.... >>>=20 >>> . . . >>>=20 >>> cc -Wp,-MD,scripts/dtc/.dtc-lexer.lex.o.d -Wall -Wstrict-prototypes = -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/dtc-lexer.lex.o scripts/dtc/dtc-lexer.lex.c >>> cc -Wp,-MD,scripts/dtc/.dtc-parser.tab.o.d -Wall -Wstrict-prototypes = -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o = scripts/dtc/dtc-parser.tab.o scripts/dtc/dtc-parser.tab.c >>> scripts/dtc/pylibfdt/libfdt_wrap.c:4656:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] >>> fdt1 =3D fdt1; /* avoid unused variable warning */ >>> ~~~~ ^ ~~~~ >>> scripts/dtc/pylibfdt/libfdt_wrap.c:4681:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] >>> fdt1 =3D fdt1; /* avoid unused variable warning */ >>> ~~~~ ^ ~~~~ >>>=20 >>> . . . >>>=20 >>> scripts/dtc/pylibfdt/libfdt_wrap.c:8418:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] >>> fdt1 =3D fdt1; /* avoid unused variable warning */ >>> ~~~~ ^ ~~~~ >>> scripts/dtc/pylibfdt/libfdt_wrap.c:8427:10: warning: explicitly = assigning value of variable of type 'const void *' to itself = [-Wself-assign] >>> fdt2 =3D fdt2; /* avoid unused variable warning */ >>> ~~~~ ^ ~~~~ >>> cc -o scripts/dtc/dtc scripts/dtc/dtc.o scripts/dtc/flattree.o = scripts/dtc/fstree.o scripts/dtc/data.o scripts/dtc/livetree.o = scripts/dtc/treesource.o scripts/dtc/srcpos.o scripts/dtc/checks.o = scripts/dtc/util.o scripts/dtc/dtc-lexer.lex.o = scripts/dtc/dtc-parser.tab.o =20 >>> 98 warnings generated. >>> gmake[1]: Leaving directory = '/wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07' >>> =3D=3D=3D> Compilation failed unexpectedly. >>> Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to >>> the maintainer. >>> *** Error code 1 >>>=20 >>> Stop. >>> make: stopped in /usr/ports/sysutils/u-boot-pine64 >>> =3D>> Cleaning up wrkdir >>> =3D=3D=3D> Cleaning for u-boot-pine64-2018.07_1 >>> build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 ended at = Tue Jul 31 20:27:47 PDT 2018 >>> build time: 00:08:08 >>> !!! build failure encountered !!! >>>=20 >>=20 >> FYI (from expansing the .tbz): >>=20 >> # find /wrkdirs/usr/ports/sysutils/u-boot-pine64/ -name "cpu*.h" | = more >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/cpu= /armv8/fsl-layerscape/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/cpu= /armv8/s32v234/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-am33xx/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-armada100/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-fsl-layerscape/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-imx/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-lpc32xx/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-omap3/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-omap4/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-omap5/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpu_sun4i.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpu_sun9i.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpucfg.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-exynos/include/mach/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-kirkwood/include/mach/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-mvebu/include/mach/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-orion5x/include/mach/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-s5pc1xx/include/mach/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mac= h-tegra/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/m68k/cp= u/mcf52x2/cpu.h . . . >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/x86/inc= lude/asm/cpu_x86.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/cpu.= h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/conf= ig/display/cpuinfo.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/conf= ig/sys/cpu.h >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/post/lib_pow= erpc/cpu_asm.h >>=20 >> It makes me wonder if the failing: >>=20 >> fixdep: error opening config file: arch/arm/include/asm/arch/cpu.h: = No such file or directory >>=20 >> was supposed to reference: >>=20 >> = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpu.h >>=20 >> Looking . . . >>=20 >> # more = /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/inc= lude/asm/arch-sunxi/cpu.h >> /* SPDX-License-Identifier: GPL-2.0+ */ >> /* >> * (C) Copyright 2015 Hans de Goede >> */ >>=20 >> #ifndef _SUNXI_CPU_H >> #define _SUNXI_CPU_H >>=20 >> #if defined(CONFIG_MACH_SUN9I) >> #include >> #else >> #include >> #endif >>=20 >> #define SOCID_A64 0x1689 >> #define SOCID_H3 0x1680 >> #define SOCID_H5 0x1718 >> #define SOCID_R40 0x1701 >>=20 >> #endif /* _SUNXI_CPU_H */ >>=20 >> . . . >=20 > Again too much context for unneeded stuff and no context at all for > what matters. Definitely true that I do not yet know what matters for this context. I'll continue to try to figure that out. > Are you familiar with Aesop fable "The Shepherd's Boy and the Wolf" ? > One day you will report something important but no one will listen to > you. >=20 > Anyhow, I've just build succesfully u-boot-pine64 with poudriere and > poudriere-devel from package on my amd64 box. Good to know that you can build it. Thanks for letting me know. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Aug 2 00:04:27 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D2D7106D3BC for ; Thu, 2 Aug 2018 00:04:27 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EF6BB8E534 for ; Thu, 2 Aug 2018 00:04:26 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w7204YeI000154 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Aug 2018 17:04:34 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7204XZ1000153; Wed, 1 Aug 2018 17:04:33 -0700 (PDT) (envelope-from fbsd) Date: Wed, 1 Aug 2018 17:04:32 -0700 From: bob prohaska To: Jamie Landeg-Jones Cc: marklmi@yahoo.com, freebsd-rwg@pdx.rh.CN85.dnsmgr.net, freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments Message-ID: <20180802000432.GA99523@www.zefox.net> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010401.w7141N3H086677@donotpassgo.dyslexicfish.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201808010401.w7141N3H086677@donotpassgo.dyslexicfish.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 00:04:27 -0000 On Wed, Aug 01, 2018 at 05:01:23AM +0100, Jamie Landeg-Jones wrote: > bob prohaska wrote: > > > The significance of those lines isn't totally lost on me, but > > it's not obvious how to apply them. Any guidance appreciated! > > Hi Bob. > Save the patch file somewhere, e.g. /tmp/patch then: > > cd /usr/src/sys/vm > patch -l < /tmp/patch > cd /usr/src > > remake the kernel, and reboot! > cheers, Jamie That works like a charm, the new kernel is (re)building world now. So far the only surprise is that top quit with a segfault, which hasn't happened in a very long time. Buildworld seems undisturbed, the gstat script is still running. Where will the output go? Serial console? Thank you very much! bob prohaska From owner-freebsd-arm@freebsd.org Thu Aug 2 00:28:27 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D44C106DB92 for ; Thu, 2 Aug 2018 00:28:27 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D7FF28EFCA for ; Thu, 2 Aug 2018 00:28:26 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w720SgU4000220 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Aug 2018 17:28:43 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w720SgYD000219; Wed, 1 Aug 2018 17:28:42 -0700 (PDT) (envelope-from fbsd) Date: Wed, 1 Aug 2018 17:28:41 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments Message-ID: <20180802002841.GB99523@www.zefox.net> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 00:28:27 -0000 On Tue, Jul 31, 2018 at 09:11:26PM -0700, Mark Millard wrote: > > > On 2018-Jul-31, at 9:05 PM, Jamie Landeg-Jones wrote: > > > bob prohaska wrote: > > > >> On Tue, Jul 31, 2018 at 07:09:43PM -0700, Mark Millard wrote: > >>> > >>> Mark Johnston also mentions "sysctl vm" output as proving more > >>> contextual information. > >>> > >> > >> The significance of those lines isn't totally lost on me, but > >> it's not obvious how to apply them. Any guidance appreciated! > > > > N.B. I know Mark just made a typo, but for info, It's actually "systat -vm" > > I do not expect so: Mark Johnston was likely correct . . . > > Here is an example of what "sysctl vm" reports (not from an rpi3 > or rpi2 context): > [snip] The output isn't any more concise on an rpi3. Is there a set of options and arguments that would pare the result down to something that would not bloat the gstat logging output and still be informative to an expert? Thanks very much to everybody! bob prohaska From owner-freebsd-arm@freebsd.org Thu Aug 2 01:30:11 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1BCA104C91E for ; Thu, 2 Aug 2018 01:30:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-10.consmr.mail.gq1.yahoo.com (sonic307-10.consmr.mail.gq1.yahoo.com [98.137.64.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48BC5912C8 for ; Thu, 2 Aug 2018 01:30:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: RVc3Rc8VM1n0uB2v1uFh4lPZoHMZDnCXZlWstXbprCG72Bk6Ilg4oeG3FBf5YBA LLcXEazwxovmUy63QYI.auLstyXQlHmTHNtbydaM8aiCT7bBjIFr2f745CTPRnc3AUlyRqLnwayH qb7fKp.raDh5.eQ.Y03VSxIxn7RIg9lAilqpphwliQiDs5DW3T0dEh78PosZ2WzrjlCUoupHK37A metOiOgXsyAE5tnr9OLS5fEyFYoJkqvs8pcqqqONCjKK7h7soisrgnR5ENM7wTYmx.urXkXzpNNS DDCrxNotPVQ8JgJ8QLekbdIzI.k2y.tAq33NXL4ieEFGNSxrwt7Zl1nuF.66aYYeygewwIObuyRk FcGB2ReRECpe0RX06mOoOSAtMl49LFn8yUjXeEAbC3Wy1Iaz.FrRchyCGWYCpEHq.edmf.g8Lz4s JbJhneXITwSbXeQwC__8P.E6H5WJOF4irq4g_jKqaXltKmGgGAs814PSHlR6C18yedsBjDA65JuT 4Cb6sxmYb3o5yA5vE.NaSgG7JXpyLcd3KzxKI8lg1RuIFJdlv0H6buaWhlNGw_tJy6AF5kuQO25S WpCeCgYvvYYt5FYOyn8Y6_GzXkrxXRI5tmPiuYG2vznnc6FhZXMN9GxRWzCscBqt2pcBwa22_QaA c4IQnUG9T4wxyA3c_xLhkWPyQ0XkdGUCh_TINE3VJ8ceE.Nsfyz0MvhrhhVNRxo_FTGaMXerY7VJ w2FpD_WTaPgPJhPHW714pZKhNlmn4oY_1v2gbRzYT2uOTmGlb7xHG0IZL6ClvkZGtw5eHkPprnXg Rzc2Kf9VAuw7jeUUbyW_URKNOCt1mAebSjj2NE0fI6VvqxwhN2LEmYkGhlPEscH0u2KcFz9nw850 MM3oLNTRVelKdS_rvoeV8kWo4Aji8MJQKU9ICOAQYaOU3X4Vm8kBh.3pjhmd69dMDp4vn.d0zHH4 zNYq0H_TVUGxPr94khJ8_IRrO1QHWjBYNOx1KdjbkSH.DM5iAqcD_XLA3zT7kpyt5E9MhOEzP0Sk nR6bOmkxW Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 2 Aug 2018 01:30:04 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp416.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4dcb2f82f5b04366acad9176226d083c; Thu, 02 Aug 2018 01:29:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <20180802000432.GA99523@www.zefox.net> Date: Wed, 1 Aug 2018 18:29:58 -0700 Cc: Jamie Landeg-Jones , "Rodney W. Grimes" , freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <6C72EFB2-6E3D-4B36-BCD7-49C6E6E0D529@yahoo.com> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010401.w7141N3H086677@donotpassgo.dyslexicfish.net> <20180802000432.GA99523@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 01:30:12 -0000 On 2018-Aug-1, at 5:04 PM, bob prohaska wrote: > On Wed, Aug 01, 2018 at 05:01:23AM +0100, Jamie Landeg-Jones wrote: >> bob prohaska wrote: >> >>> The significance of those lines isn't totally lost on me, but >>> it's not obvious how to apply them. Any guidance appreciated! >> >> Hi Bob. >> Save the patch file somewhere, e.g. /tmp/patch then: >> >> cd /usr/src/sys/vm >> patch -l < /tmp/patch >> cd /usr/src >> >> remake the kernel, and reboot! >> cheers, Jamie > > That works like a charm, the new kernel is (re)building world now. > So far the only surprise is that top quit with a segfault, which > hasn't happened in a very long time. Buildworld seems undisturbed, > the gstat script is still running. > > Where will the output go? Serial console? What I originally wrote indicates that dmesg would get the output: QUOTE In that thread is the message: https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069835.html that has a patch for dumping out more information to demsg before it does the kill END QUOTE (More accurately: the output goes to where dmseg gets what it reports. I tend to use dmesg -a .) The original Mark Johnston message said: QUOTE The patch below prints a few stats to the dmesg before the kill. The output of that together with "sysctl vm" output should be enough to determine what's happening. END QUOTE === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Aug 2 01:40:48 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50F2C104D3DE for ; Thu, 2 Aug 2018 01:40:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.ne1.yahoo.com (sonic311-23.consmr.mail.ne1.yahoo.com [66.163.188.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD89B91921 for ; Thu, 2 Aug 2018 01:40:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: PEwpp_gVM1muqfd5iR90Uyn520T8y8v7JodXJC0qAvK.j.MtG2jbxtcnxRZUIoR 9N68PR4UBAh2tynkFk9sDQAH_RtlhGwSomTQFTLspKqApMhvlIQ0TyGDGgGjIQpxqf.hrIce89ph KSGLvSYWd1toh1rEM6q.dMJXnNTKm4QNiA8NKMUS7FJNSgQj.vs87u033Tkd8Vxuuxo5UpxOe_69 nkwqV7.ikt_f4C68dBgQgK3pLmAx0pvYfoJDZw4A5l0u_1b9.eOjUDEtOqSAaSbEkigAl8sR4nfC PtNEinpV8u4ddznKduDf9yztKi7GZidv8xp62lF8cbRa7KZ_l5NKj2f8RidvxNlnKNrLxXnmm3v7 Zlw4TDyhSnS4nfiaU6iFcOeUOxrrP3IAdBe8TwdrdQVg4P3SL2bpazC8pnL27NQd37aclIHH7CeJ jCVAQyBappJqi6hzIRvnwVqU1SDpixbsDnm6DWzVqlAvoQD.TOQRxtBl.U6NBxofQBmNP609zGDO I8ZWfi2KbRC2GS33KaU2InIhprkK5083LcpIC2DtHGn6OMy3BgoLM7CifHou8pU0rymTCBb_7JLo R7UAEUrVUTAu.Svmzh1rtyDbu9ErERhW1lUCY5T1jeWIq0QlTTHOWCRHs2e0mZiDff1qaYSa6EFr JjDyPrUmhjyobmv4QUK2aO.bhcSf14uQncYpGddWlGgam8tyUqvFqTN2yZ9QvfuJLVHT_NWtpsV2 cA6O7L9YRpFU86zAAo.ElJOTD6Ql8Yxbsk4sQItXbI51fOLOv9Fjk6DAj.coBwhL9_ThOKvTtdYt LjYi7FsirEHEUcjUzOljH4Ndpng1xsyLMjo0Ex7thaZZ3f.6k2_WfUtSx8iMhxJ9YMWixdUXSrfW Bfz7QPGJHuZ0eu08wE75Z.0hQpt.I87Y5EG6X3V2rdrYHCRUkU0UQz6yGcnf1alz0x2C1WEPGa96 fXxKmgk5Ht1OuIvNnlEi0G.YmdMDe6ajcmgSyZPMh_imnsqdu1jWjByXINn9H_5RGbgJvTfruJ1V BhToNibgjDG4A Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Thu, 2 Aug 2018 01:40:41 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp401.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a53e462089119424eb0924155c7ca7f2; Thu, 02 Aug 2018 01:40:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments From: Mark Millard In-Reply-To: <20180802002841.GB99523@www.zefox.net> Date: Wed, 1 Aug 2018 18:40:38 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0C434AF9-65B2-4E24-A160-3FF4007CB544@yahoo.com> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 01:40:48 -0000 On 2018-Aug-1, at 5:28 PM, bob prohaska wrote: > On Tue, Jul 31, 2018 at 09:11:26PM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2018-Jul-31, at 9:05 PM, Jamie Landeg-Jones = wrote: >>=20 >>> bob prohaska wrote: >>>=20 >>>> On Tue, Jul 31, 2018 at 07:09:43PM -0700, Mark Millard wrote: >>>>>=20 >>>>> Mark Johnston also mentions "sysctl vm" output as proving more >>>>> contextual information. >>>>>=20 >>>>=20 >>>> The significance of those lines isn't totally lost on me, but=20 >>>> it's not obvious how to apply them. Any guidance appreciated!=20 >>>=20 >>> N.B. I know Mark just made a typo, but for info, It's actually = "systat -vm" >>=20 >> I do not expect so: Mark Johnston was likely correct . . . >>=20 >> Here is an example of what "sysctl vm" reports (not from an rpi3 >> or rpi2 context): >>=20 > [snip] >=20 > The output isn't any more concise on an rpi3. Is there a set of = options and > arguments that would pare the result down to something that would not = bloat=20 > the gstat logging output and still be informative to an expert? While Mark Johnston indicated that "sysctl vm" likely provided = sufficient additional information, I do not know what of it is necessary vs. what might be irrelevant. Nor do I know the right time frame(s) for the execution relative to when = the OOMA kill(s) happen during buildworld. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Aug 2 01:51:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20615104E093 for ; Thu, 2 Aug 2018 01:51:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8667D9202A for ; Thu, 2 Aug 2018 01:51:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w721panv000448 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Aug 2018 18:51:36 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w721pZWU000447; Wed, 1 Aug 2018 18:51:35 -0700 (PDT) (envelope-from fbsd) Date: Wed, 1 Aug 2018 18:51:35 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments Message-ID: <20180802015135.GC99523@www.zefox.net> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180802002841.GB99523@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 01:51:21 -0000 The patch to report OOMA information did its job, very tersely. The console reported v_free_count: 5439, v_inactive_count: 1 Aug 1 18:08:25 www kernel: pid 93301 (c++), uid 0, was killed: out of swap space The entire buildworld.log and gstat output are at http://www.zefox.net/~fbsd/rpi3/swaptests/r336877M/ It appears that at 18:08:21 a write to the USB swap device took 530.5 ms, next top was killed and ten seconds later c++ was killed, _after_ da0b was no longer busy. This buildworld stopped a quite a bit earlier than usual; most of the time the buildworld.log file is close to 20 MB at the time OOMA acts. In this case it was around 13 MB. Not clear if that's of significance. If somebody would indicate whether this result is informative, and any possible improvements to the test, I'd be most grateful. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Thu Aug 2 04:09:36 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 105DA10553BB; Thu, 2 Aug 2018 04:09: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 6FE7670876; Thu, 2 Aug 2018 04:09:35 +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 64a9ec56; Thu, 2 Aug 2018 06:09:27 +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=gxUiUJ/TqU334RP/lTmRIPsrUc8=; b=SKgHCh+zLnpGmmatJVmsb4XlsytY YSGVgADhoHmh/c/UWkSLPAZ4cgScYWDkVEhQZHEolvpaA03GbZJxM0dzFxGRwE/w CuifkvM/xCl6QZt3tD/TP5zTCFN4m67gg94OvrokHmoVN0JRd2EKGhVs+GxWTk3i ncopwiqS77WX+OQ= 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=CqTBUVs0GNj+mUmbnxNFDizSTjfi8Ck69xvDuJaHjHJK8n13p3hLqoql b6HWNSILpbC2ozVh3Voez9F68INACG4s9CJ9+3/nGoMNyCIGK5GlpfuBsn/J8c8P nZYhUDtoN6wxZRFdLUsEjnVC4IVEZrdUbrAfV+cPMbxTfDdF/O0= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 8d1b1ea1 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 2 Aug 2018 06:09:27 +0200 (CEST) Date: Thu, 2 Aug 2018 06:09:27 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Mark Millard via freebsd-uboot , freebsd-arm Subject: Re: poudriere-devel build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 failed Message-Id: <20180802060927.72eadf5b1f8fe8bcf8860dc3@bidouilliste.com> In-Reply-To: References: <451D906A-3807-4029-BFFA-1A00AD8FB0F9@yahoo.com> <6D377AEB-C359-4DC3-A95F-2A4A72CBF090@yahoo.com> <20180801095942.91dfc4d5907b75b4fe63c1d0@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 04:09:36 -0000 On Wed, 1 Aug 2018 07:02:08 -0700 Mark Millard via freebsd-uboot wrote: > > > On 2018-Aug-1, at 12:59 AM, Emmanuel Vadot wrote: > > > On Tue, 31 Jul 2018 23:02:27 -0700 > > Mark Millard via freebsd-arm wrote: > > > >> On 2018-Jul-31, at 10:37 PM, Mark Millard wrote: > >> > >>> [It will likely be some time before I'll be able to look into > >>> the cause of the below. After u-boot-pine64 failed the following > >>> succeeded during the same bulk build: > >>> sysutils/u-boot-rpi3 | u-boot-rpi3-2018.07_1 > >>> sysutils/u-boot-rpi2 | u-boot-rpi2-2018.07_1 > >>> sysutils/u-boot-sinovoip-bpi-m3 | u-boot-sinovoip-bpi-m3-2018.07_1 > >>> ] > >>> > >>> My attempt to update port packages based on -r476026 source code > >>> via poudriere-devel got: > >>> > >>> cc -Wp,-MD,scripts/dtc/.fstree.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o scripts/dtc/fstree.o scripts/dtc/fstree.c > >>> set -e; : ' CHK include/generated/generic-asm-offsets.h'; mkdir -p include/generated/; (set -e; echo "#ifndef __GENERIC_ASM_OFFSETS_H__"; echo "#define __GENERIC_ASM_OFFSETS_H__"; echo "/*"; echo " * DO NOT MODIFY."; echo " *"; echo " * This file was generated by Kbuild"; echo " */"; echo ""; sed -ne "s:[[:space:]]*\.ascii[[:space:]]*\"\(.*\)\":\1:; /^->/{s:->#\(.*\):/* \1 */:; s:^->\([^ ]*\) [\$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; s:^->\([^ ]*\) [\$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; s:->::; p;}"; echo ""; echo "#endif" ) < lib/asm-offsets.s > include/generated/generic-asm-offsets.h.tmp; if [ -r include/generated/generic-asm-offsets.h ] && cmp -s include/generated/generic-asm-offsets.h include/generated/generic-asm-offsets.h.tmp; then rm -f include/generated/generic-asm-offsets.h.tmp; else : ' UPD include/generated/generic-asm-offsets.h'; mv -f include/generated/generic-asm-offsets.h.tmp include/generated/generic-asm-offsets.h; fi > >>> cc -Wp,-MD,scripts/dtc/.data.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o scripts/dtc/data.o scripts/dtc/data.c > >>> if [ -d arch/arm/mach-sunxi/include/mach ]; then \ > >>> dest=../../mach-sunxi/include/mach; \ > >>> else \ > >>> dest=arch-sunxi; \ > >>> fi; \ > >>> ln -fsn $dest arch/arm/include/asm/arch > >>> fixdep: error opening config file: arch/arm/include/asm/arch/cpu.h: No such file or directory > >>> set -e; : ' CHK include/config.h'; mkdir -p include/; (echo "/* Automatically generated - do not edit */"; for i in $(echo "" | sed 's/,/ /g'); do echo \#define CONFIG_$i | sed '/=/ {s/=/ /;q; } ; { s/$/ 1/; }'; done; echo \#define CONFIG_BOARDDIR board/sunxi; echo \#include \; echo \#include \; echo \#include \; echo \#include \; echo \#include \; echo \#include \;) < scripts/Makefile.autoconf > include/config.h.tmp; if [ -r include/config.h ] && cmp -s include/config.h include/config.h.tmp; then rm -f include/config.h.tmp; else : ' UPD include/config.h'; mv -f include/config.h.tmp include/config.h; fi > >>> gmake[2]: *** [Kbuild:65: arch/arm/lib/asm-offsets.s] Error 2 > >>> gmake[1]: *** [Makefile:1434: prepare0] Error 2 > >>> gmake[1]: *** Waiting for unfinished jobs.... > >>> > >>> . . . > >>> > >>> cc -Wp,-MD,scripts/dtc/.dtc-lexer.lex.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o scripts/dtc/dtc-lexer.lex.o scripts/dtc/dtc-lexer.lex.c > >>> cc -Wp,-MD,scripts/dtc/.dtc-parser.tab.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -Iscripts/dtc -Iscripts/dtc/libfdt -c -o scripts/dtc/dtc-parser.tab.o scripts/dtc/dtc-parser.tab.c > >>> scripts/dtc/pylibfdt/libfdt_wrap.c:4656:10: warning: explicitly assigning value of variable of type 'const void *' to itself [-Wself-assign] > >>> fdt1 = fdt1; /* avoid unused variable warning */ > >>> ~~~~ ^ ~~~~ > >>> scripts/dtc/pylibfdt/libfdt_wrap.c:4681:10: warning: explicitly assigning value of variable of type 'const void *' to itself [-Wself-assign] > >>> fdt1 = fdt1; /* avoid unused variable warning */ > >>> ~~~~ ^ ~~~~ > >>> > >>> . . . > >>> > >>> scripts/dtc/pylibfdt/libfdt_wrap.c:8418:10: warning: explicitly assigning value of variable of type 'const void *' to itself [-Wself-assign] > >>> fdt1 = fdt1; /* avoid unused variable warning */ > >>> ~~~~ ^ ~~~~ > >>> scripts/dtc/pylibfdt/libfdt_wrap.c:8427:10: warning: explicitly assigning value of variable of type 'const void *' to itself [-Wself-assign] > >>> fdt2 = fdt2; /* avoid unused variable warning */ > >>> ~~~~ ^ ~~~~ > >>> cc -o scripts/dtc/dtc scripts/dtc/dtc.o scripts/dtc/flattree.o scripts/dtc/fstree.o scripts/dtc/data.o scripts/dtc/livetree.o scripts/dtc/treesource.o scripts/dtc/srcpos.o scripts/dtc/checks.o scripts/dtc/util.o scripts/dtc/dtc-lexer.lex.o scripts/dtc/dtc-parser.tab.o > >>> 98 warnings generated. > >>> gmake[1]: Leaving directory '/wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07' > >>> ===> Compilation failed unexpectedly. > >>> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > >>> the maintainer. > >>> *** Error code 1 > >>> > >>> Stop. > >>> make: stopped in /usr/ports/sysutils/u-boot-pine64 > >>> =>> Cleaning up wrkdir > >>> ===> Cleaning for u-boot-pine64-2018.07_1 > >>> build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 ended at Tue Jul 31 20:27:47 PDT 2018 > >>> build time: 00:08:08 > >>> !!! build failure encountered !!! > >>> > >> > >> FYI (from expansing the .tbz): > >> > >> # find /wrkdirs/usr/ports/sysutils/u-boot-pine64/ -name "cpu*.h" | more > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/cpu/armv8/fsl-layerscape/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/cpu/armv8/s32v234/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-am33xx/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-armada100/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-fsl-layerscape/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-imx/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-lpc32xx/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-omap3/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-omap4/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-omap5/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpucfg.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-exynos/include/mach/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-kirkwood/include/mach/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-mvebu/include/mach/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-orion5x/include/mach/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-s5pc1xx/include/mach/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/mach-tegra/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/m68k/cpu/mcf52x2/cpu.h > . . . > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/x86/include/asm/cpu_x86.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/config/display/cpuinfo.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/include/config/sys/cpu.h > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/post/lib_powerpc/cpu_asm.h > >> > >> It makes me wonder if the failing: > >> > >> fixdep: error opening config file: arch/arm/include/asm/arch/cpu.h: No such file or directory > >> > >> was supposed to reference: > >> > >> /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpu.h > >> > >> Looking . . . > >> > >> # more /wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2018.07/arch/arm/include/asm/arch-sunxi/cpu.h > >> /* SPDX-License-Identifier: GPL-2.0+ */ > >> /* > >> * (C) Copyright 2015 Hans de Goede > >> */ > >> > >> #ifndef _SUNXI_CPU_H > >> #define _SUNXI_CPU_H > >> > >> #if defined(CONFIG_MACH_SUN9I) > >> #include > >> #else > >> #include > >> #endif > >> > >> #define SOCID_A64 0x1689 > >> #define SOCID_H3 0x1680 > >> #define SOCID_H5 0x1718 > >> #define SOCID_R40 0x1701 > >> > >> #endif /* _SUNXI_CPU_H */ > >> > >> . . . > > > > Again too much context for unneeded stuff and no context at all for > > what matters. > > Definitely true that I do not yet know what matters for this context. > I'll continue to try to figure that out. Well it's a port and you are building via poudriere so just put the log file (the full log file) somewhere so we can have a look. Also arch, ports tree revision, blah, the usual suspects. > > Are you familiar with Aesop fable "The Shepherd's Boy and the Wolf" ? > > One day you will report something important but no one will listen to > > you. > > > > Anyhow, I've just build succesfully u-boot-pine64 with poudriere and > > poudriere-devel from package on my amd64 box. > > Good to know that you can build it. Thanks for letting me know. > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-uboot@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-uboot > To unsubscribe, send any mail to "freebsd-uboot-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Aug 2 04:27:40 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 491981056118 for ; Thu, 2 Aug 2018 04:27:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEBF8719A4 for ; Thu, 2 Aug 2018 04:27:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 8Na0_XoVM1lXGiB5LaizAvMibPrcHxdIx4A5R7abdBRG2SQtJpviYQgALgKFkRA s7isd6j2VLupygG3wtxm87mL_C2Esr9.aix4HUvzFM.pf4NnnUm4VK3IEfvyZMsgXicflkhTi2Yf ZWHsl0iyaALos9fgLX_MaKKYrJjRJ8o6fq_08.OOWEnQh63QYGuFxJHJJrpCjLChWTbYzVataq4E XQmGkiAgGpPhAShrfdG.10dGVk2Dmlyl86M66AafgflAD5QYDykXAirbrF.DjFri0mkHS8hAZAdZ PovOAwAbaBSUhmwgBb6xQ0GRp0CSMg1BqG2x0L7f0ZXzcIpuAEedkJFlevicRFHqpKqs4Sbum9Eq ho.hog7u0NRDvqJrbhWFNiihtfrCOiWuY4sMlh5XMmPW2VzDlF44A3Vl83XEMsBggUTMfioljQew rRSmjvvNqLmmW.xChNY3Y3nfUzb6LqDmKkpc9lHmvsxLoHdVU2kcmitLmOgGVGj1NSV68J5BLGom 40Wai9a3Sa56A68lVgHENGhZfsXprMgkMIeVZ_XlWRiNt9q2JLMSYm5mVqVKBONK2d7CDuJ8xh7. kscnwS2uShFR2iXbNJaN.D_N2pg0KsV30410aj4xEwM338JxXtQOOLkwpbB1ltlrKUxuetZRIuYY g.1b3vlo8FcHAkq.geArnGNdTynLMBgH_3JIjKM7wiO.cf7x_OqSRhhtREV7XjPPBFD3NEdirDZY ZK5F9qk_9vphwgkPIN1wXWkAb7jJbEIBtmg2O0_Ir1oypxBgRl_ehgDd_2UnmP_svfjsfYVmiamd VJFioxnb2k7PyVUuuLypN1qMpooaXDVrQmhsgDKATNMpSiQADQywXeI.FBg0bIU8iKdaEL_5gOY7 LQya4lW8V6j50dDOWE4euJ0tEK2SwdWWCViSt3oPW7ZfzhjIlu0puKUFGfPjgQaz_s9sHfwYEXDX Hne5K8BU7WhpDIRFXmqi65FD02tUV088s5E_qrEmGL2KNEggXrnqznMAZ9PSUOQdI7QOVmIo8rzN B00sjz8UunAIHRkLhZw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 2 Aug 2018 04:27:32 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp421.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 812d4bb9e8fa533c39ce787735e349a8; Thu, 02 Aug 2018 04:27:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180802015135.GC99523@www.zefox.net> Date: Wed, 1 Aug 2018 21:27:31 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> To: bob prohaska , Mark Johnston X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 04:27:40 -0000 [I have a top-posted introduction here in reply to a message listed at the bottom.] Bob P. meet Mark J. Mark J. meet Bob P. I'm hopinh you can help Bob P. use a patch that you once published on the lists. This was from: = https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069835.html Bob P. has been having problems with an rpi3 based buildworld ending up with "was killed: out of swap space" but when the swap partitions do not seem to be heavily used (seen via swapinfo or watching top). [I will avoid the long, complicated history of investigations here and also any past hypothesis about contributing causes.] Bob P. recently introduced Mark J.'s patch to report the likes of: v_free_count: 5439, v_inactive_count: 1 . The issue happens during time periods were simple means of observation suggest that their is lots of swap space available. Sorting by time (a looping script was running, logging output, including swapinfo output): Wed Aug 1 18:08:10 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 28248 1020328 3% /dev/mmcsd0s3b 1048576 28256 1020320 3% Total 2097152 56504 2040648 3% Aug 1 18:08:13 www kernel: v_free_count: 5439, v_inactive_count: 1 Wed Aug 1 18:08:21 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 31768 1016808 3% /dev/mmcsd0s3b 1048576 31640 1016936 3% Total 2097152 63408 2033744 3% Aug 1 18:08:25 www kernel: pid 93301 (c++), uid 0, was killed: out of = swap space Wed Aug 1 18:08:35 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 24840 1023736 2% /dev/mmcsd0s3b 1048576 25404 1023172 2% Total 2097152 50244 2046908 2% The above is a clean up of the output which had more and had repeated information from the tail of a log until it gets new messages. The original script was something like: #!/bin/sh while true do gstat -abd -I 10s ; date ; swapinfo ; tail -n 2 /var/log/messages=20 done I ran out of ability indicate what more to investigate. For example I'm unsure of when to do the "sysctl vm" that you [Mark J.] have suggested back in June. It is unlikely that Bob P. will happen to be there when buildworld has the kill(s) occur. When it happens in the build sequence is not stable from one try to the next. This introduction is a reply to the following. On 2018-Aug-1, at 6:51 PM, bob prohaska wrote: > The patch to report OOMA information did its job, very tersely. The = console reported > v_free_count: 5439, v_inactive_count: 1 > Aug 1 18:08:25 www kernel: pid 93301 (c++), uid 0, was killed: out of = swap space >=20 > The entire buildworld.log and gstat output are at > http://www.zefox.net/~fbsd/rpi3/swaptests/r336877M/ >=20 > It appears that at 18:08:21 a write to the USB swap device took 530.5 = ms,=20 > next top was killed and ten seconds later c++ was killed, _after_ da0b > was no longer busy. >=20 > This buildworld stopped a quite a bit earlier than usual; most of the = time > the buildworld.log file is close to 20 MB at the time OOMA acts. In = this case > it was around 13 MB. Not clear if that's of significance. >=20 > If somebody would indicate whether this result is informative, and any = possible > improvements to the test, I'd be most grateful.=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Aug 2 05:57:23 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73EB01059301 for ; Thu, 2 Aug 2018 05:57:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EEACA74C84 for ; Thu, 2 Aug 2018 05:57:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: fAqwpp8VM1m.prDIZX9dg.wH6awo0LUsDeQf8Hdw9z1H_llUXeqSmP9CwUjo9Iw jQxzobPs5l8cklAzimDYVUdIqMgiwZVA2DtETiCWLrHr97sXil6APQOcOs0nAFxOlxOFwMhXe61R xS2fVsEtaaybfl62Z45.8PKODj90YURfuJEaZECojAyyXLwNo1moYbNH62DRFBV8kOzP42d1QLpo lVIwK2Tspl0p7BFXTT2vGiASrBMS_Kyw388NaimPtXAeA88w7Z5kkF_RvkfJJHnJlgMibeNOHthu T9wYxRxL__qKFok6nsI_LCfZ5GISoNYAQykKlh15z7pNlOWw3gzW.6ZBHldYxdPjpDs17u3Fhxfn 8abSlyHj3nxVSqBMfJN6czRR3LD2NGSPJ0oC592291rrM1CS.oMtBK1UwIxEDvvttyiZBJ0f7ql3 jl1jH33uaTRJJrONu0AUNOtBqjZjZjwSbVka.axQvDgCEYnwsIJXN8yDhVJRY9sL9x47LU5sc0Cb cUi81BEiTZ_OgVsPt6LfokK2qNMtaSZYRu.lDEFYYQu2L9sM.t0KzdRUwAjGSZnP2V3wdb6sh2gP xxODynt2pl2wEFSkew5U_aZ5sRSYobBXg3_SiqD8lqVk8Z81FpDLq18gbxVE5XUUwRBO8sBrgiJE FTVr33RlK1o1OlnVtthTBd727zeNL6AbrEzCKMiNiiQ7C_g0oU82f_uNGPcTltkaoTYcBvV9jfhZ Di8V3d5jYxC1spmJeP6RW885VxZP3wdGkX2qubs0prHduzm9MQp74tEWlCJ1TXi0oUSdqJ6AMu.n 1sP3cUBDVlVpBldkFvBc5ACCpfQe8qCQmrbKBLoP0jrwpagAaf8tUjCeJgVLnSk6XKXWniiF94jB 8Xn6Owm5ubNTXUse2gn.VM8hMDqahGzTgGa2WGfeVP11g6csgLbwm_VxE1yR80.6osANBXRqvC71 D7c6L2MXi95J43ZKUYVVI9fEm.u0hvfPwPnoQeNMybuOnMe.1141JDIOFit5R.Fvh1hxNnHZD.xJ 0mMofGeoOB6ZHgLI- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 2 Aug 2018 05:57:15 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b72c64780cdf4652b8830607abc280bd; Thu, 02 Aug 2018 05:57:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: poudriere-devel build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 failed From: Mark Millard In-Reply-To: <20180802060927.72eadf5b1f8fe8bcf8860dc3@bidouilliste.com> Date: Wed, 1 Aug 2018 22:57:13 -0700 Cc: Mark Millard via freebsd-uboot , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <451D906A-3807-4029-BFFA-1A00AD8FB0F9@yahoo.com> <6D377AEB-C359-4DC3-A95F-2A4A72CBF090@yahoo.com> <20180801095942.91dfc4d5907b75b4fe63c1d0@bidouilliste.com> <20180802060927.72eadf5b1f8fe8bcf8860dc3@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 05:57:23 -0000 On 2018-Aug-1, at 9:09 PM, Emmanuel Vadot = wrote: > On Wed, 1 Aug 2018 07:02:08 -0700 > Mark Millard via freebsd-uboot wrote: >=20 >>=20 >>=20 >> On 2018-Aug-1, at 12:59 AM, Emmanuel Vadot = wrote: >>=20 >>> . . . >>=20 >> Definitely true that I do not yet know what matters for this context. >> I'll continue to try to figure that out. >=20 > Well it's a port and you are building via poudriere so just put the > log file (the full log file) somewhere so we can have a look. > Also arch, ports tree revision, blah, the usual suspects. The build did not get far: the log file is only 747 lines long. I'll probably submit a bugzilla for the issue at some point. I'll report the number when I do. I suggest looking at: = https://lists.freebsd.org/pipermail/freebsd-ports/2018-August/113981.html for a recent build failure type that I analyzed (devel/*-gcc failures). = John Baldwin reduced the history down to the final result for our exchanges and so it = will will not be a long read. The issue was tied to my use of WITHOUT_BINTUILS for the = buildworld that was installed and in use but devel/powerpc64-gcc (the master port = for the devel/*-gcc ports) not listing devel/binutils in BUILD_DEPENDS in = addition to the historical devel/${PKGNAMEPREFIX}binutils for the cross-build. Other gcc-ish ports that cross-build things may have similar issues with = expecting but missing "builder-architecture" tools from binutils. I'm not claiming = that is the problem here but it is a fairly new type of problem to be aware of. Just FYI for the pine64 u-boot port context: (To be in the bugzilla submittal as well.) # uname -apKU FreeBSD FBSDUSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r336693M amd64 = amd64 1200075 1200075 (The "M" is mostly for experiments targeting powerpc and powerpc64 via fairly modern toolchains. The poudriere-devel jail uses an install-tree installed from the same buildworld.) # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 476026 Last Changed Rev: 476026 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Aug 2 06:47:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 936EA105AAF6 for ; Thu, 2 Aug 2018 06:47:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1CB0876862 for ; Thu, 2 Aug 2018 06:47:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: pY4Z2VwVM1lMUnWvBALZ9wBx9pTDDRzVGvycWMyZzz.96UckKaqIhmCVCOkEloI y3Q_PXkTmBOEdSDiQwH.RqDdMYMaEhW2nTHQ74vEhlgOCGQzGMrt0Mh_x0RRkGBxMb4cfUqpz1Gx 3p7DEGtLKcnbf0cIoYxelHoVser2p_3QZ.hMMaWc_Lqpb0Nv0vvgy3bqfixy6IiumYHB.GUstyVy nOU5eaQIQ6dNIYCdrQOBFB9g1urBYS48H4O8t.DWI6mbNX6Q16UAbN3V_kDRYS08cIxOtpYHbfdN kRjSqX5Iw2t34WD4xVVj7Cvqs1YN2..Q.Mo3ejQi5bJBZndIdYjOD8WO1PK0qWsQu8iphW6VR48Z .NuBy95paepjVUem4VcyL5mzxXOibViwrpyNBs5BovqWXG9oBH9Tgylt_Xqoqm66Jp2tslPSuure laJh_GUJbQaz3kF3MOvAmSnidbS4O4t9tIXwI8u8gaKdjFJKcWkolRcxOA3Ueixo5RABBRpXGmu7 Z2BRJDEwKg0Ee8.pRQ.iKl7c85exnIk2rnV9pZS5UObV3ErP5qN5pOU9gdSK4qipmgsCPRcGrOIR LBANG6NCFwFjRbXrEVIbY16fmEaXWznKOD5sfFjuffxkNySVDCsZV_XU.W6PeRNgQk8NirHsqXQb UVWu72ojj7xjZy.5EO__dahXQ0r7RIyX_FsEk7nuwXWvNL5_pRtInritzZmnwjkwpQ4Dz2yPObkP J4DNQ1oqu0ifFC0UrhjrmQr2kT9ecEEyNE8vvnylsltBjMwMdzlF5wZBFLjhHkPMHTDeaPz1ykou jCef9Oz27MffYMGQPrkOBveLJI7I4kXQShxe0avSHRpMukojidhZ2ApxV8RXtWgEar.prDkAsVoG Zcnq_Q0tJzM0930PQZmco93De21KPB58ViCuUAt4YVt2CynuzJhfZWBu9b1QXjc.3KBv6nzj6pfc 9AA6RFEORHAruAIhuKvav1gFWqZ2cdrTsZoxGHKlUOSHDlwf2H9BbPT.Ui1wiEYdRdmN81aJjKIP TTBPv5.i57lhOlg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 2 Aug 2018 06:47:03 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp432.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1c53d760c6880523128b91950114326a; Thu, 02 Aug 2018 06:47:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: poudriere-devel build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 failed From: Mark Millard In-Reply-To: Date: Wed, 1 Aug 2018 23:47:02 -0700 Cc: Mark Millard via freebsd-uboot , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4DBB7051-AEC9-4ECA-B645-0A5AF1C7C856@yahoo.com> References: <451D906A-3807-4029-BFFA-1A00AD8FB0F9@yahoo.com> <6D377AEB-C359-4DC3-A95F-2A4A72CBF090@yahoo.com> <20180801095942.91dfc4d5907b75b4fe63c1d0@bidouilliste.com> <20180802060927.72eadf5b1f8fe8bcf8860dc3@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 06:47:05 -0000 [See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230288 .] On 2018-Aug-1, at 10:57 PM, Mark Millard wrote: > On 2018-Aug-1, at 9:09 PM, Emmanuel Vadot = wrote: >=20 >> On Wed, 1 Aug 2018 07:02:08 -0700 >> Mark Millard via freebsd-uboot wrote: >>=20 >>>=20 >>>=20 >>> On 2018-Aug-1, at 12:59 AM, Emmanuel Vadot wrote: >>>=20 >>>> . . . >>>=20 >>> Definitely true that I do not yet know what matters for this = context. >>> I'll continue to try to figure that out. >>=20 >> Well it's a port and you are building via poudriere so just put the >> log file (the full log file) somewhere so we can have a look. >> Also arch, ports tree revision, blah, the usual suspects. >=20 > The build did not get far: the log file is only 747 lines long. I'll > probably submit a bugzilla for the issue at some point. I'll report > the number when I do. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230288 > I suggest looking at: >=20 > = https://lists.freebsd.org/pipermail/freebsd-ports/2018-August/113981.html >=20 > for a recent build failure type that I analyzed (devel/*-gcc = failures). John Baldwin > reduced the history down to the final result for our exchanges and so = it will will not > be a long read. The issue was tied to my use of WITHOUT_BINTUILS for = the buildworld > that was installed and in use but devel/powerpc64-gcc (the master port = for the > devel/*-gcc ports) not listing devel/binutils in BUILD_DEPENDS in = addition to the > historical devel/${PKGNAMEPREFIX}binutils for the cross-build. >=20 > Other gcc-ish ports that cross-build things may have similar issues = with expecting > but missing "builder-architecture" tools from binutils. I'm not = claiming that is > the problem here but it is a fairly new type of problem to be aware = of. >=20 >=20 >=20 > Just FYI for the pine64 u-boot port context: > (To be in the bugzilla submittal as well.) >=20 > # uname -apKU > FreeBSD FBSDUSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r336693M amd64 = amd64 1200075 1200075 >=20 > (The "M" is mostly for experiments targeting powerpc and powerpc64 > via fairly modern toolchains. The poudriere-devel jail uses an > install-tree installed from the same buildworld.) >=20 > # svnlite info /usr/ports/ | grep "Re[plv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 476026 > Last Changed Rev: 476026 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Aug 2 11:10:28 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 292E010630DB for ; Thu, 2 Aug 2018 11:10:28 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh501-vm1.bullet.mail.kks.yahoo.co.jp (nh501-vm1.bullet.mail.kks.yahoo.co.jp [183.79.56.131]) by mx1.freebsd.org (Postfix) with SMTP id 3531483104 for ; Thu, 2 Aug 2018 11:10:26 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.139] by nh501.bullet.mail.kks.yahoo.co.jp with NNFMP; 02 Aug 2018 11:08:42 -0000 Received: from [183.79.100.136] by t502.bullet.mail.kks.yahoo.co.jp with NNFMP; 02 Aug 2018 11:08:42 -0000 Received: from [127.0.0.1] by omp505.mail.kks.yahoo.co.jp with NNFMP; 02 Aug 2018 11:08:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 35140.92638.bm@omp505.mail.kks.yahoo.co.jp Received: (qmail 27389 invoked by uid 60001); 2 Aug 2018 11:08:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1533208121; bh=NnM/Wx839w93sdG0RmP0zCU+qF7XlpFDlkfCQbDPDOA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QeMJD4mL1J9GQ9E+YkdNteQ7gj6z4byQ2+jybrZG5s1xot9QABJ7OO53xxsnSJFF1JQCiWbVI/OHXw9xvyoS2mWPy4xnkndYlDoKI692t97waDPDK6TzWAP9FddKuTS4eccDclvEb2HCJ7/gFbNAfC78gdPau6oVtQmOOuSv6Qk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rSHoYenoHb6IhbgvGHtZflQiy7M0tZmZ/2uVEdvrbkU5+4f7zLWlBiyiClqLJww3uyiGiYP1TfZUWxlQ0OsXrY+LR3wZV+yoY+aF53QXI/mdkUtyYCB8sJ2X2CH976ppBrcjxLmPmNWapiz0yZijZ3ETdmOlMPTIYVHFUGqKgz0=; Message-ID: <683707.5703.qm@web103901.mail.ssk.yahoo.co.jp> X-YMail-OSG: bvD.OQYVM1lD0XDsOR1GJAljP8ap.1Ulyy4e.5dcp48lw11ZXKZPetJIthCKibABniu6QKG23JxP9Q2UCOVBn7ETJqoHpvcWM3fC1tMAG3x6VNbLUlypD_h7vOXjYhWnu7HyC6Dkc4QcCqaEXvgRAxxDCfNgV1ZrS3eFpX0_jBay17R02iLk2ctEpEZp4EOKRE2C_rJWkdFdWeAmzn9Es3o8xD9eQ.XZbEOe_SIzZfoxmt5U.Yx5zFGI3edEFFpHd8GzOslHRR.dMTTE5bR1ffyZ70r3BJ06aOrIvA8gnj0RqfKo9wdRqFAs28eyF1dB.0H.h0YGXIeiOwJsYYDek.0rCL4EEolVrdm7gGgnrDbb0BvCLzPyzvC8XdKHTQEhqomOWX6BRnJpNezUlDOa_GGfgzrJOIDkAfWGkYf2Nd19QjD4KlhY2ruDAlvi0BxarmjYwWT14AEfqTBB4vtla3XDMAaSZdLtu7YLvwxuOUQPzawaw.xIVMNgfI_ubUXxIlmjHUo5p9HOJ6oiZ3UImFpnmCvOss9utlTSrsMKw_AZ2OyJWjx_23eDM5fK_bPDUZeqfO3SrSIHbHP58rN_fMeBcXt1WhDFEP4jrHNLAzcv0LsXCSrniBnfLkCbQDfP Received: from [203.165.91.75] by web103901.mail.ssk.yahoo.co.jp via HTTP; Thu, 02 Aug 2018 20:08:40 JST X-Mailer: YahooMailWebService/0.8.111_74 X-YMail-JAS: fsskkPEVM1lmIz1E_o3B35veEpxZLhoJHqb_YPXuFNgdmUYnT_oxDQd5FAUzYz7jshgioCjb5RdmezkkTuyYZvM0_unRYEfbpNC9aTdqRCoAgP9VffsxZ7cOi1j5SBn6rbab References: <527924.35248.qm@web103919.mail.ssk.yahoo.co.jp> <31342.89059.qm@web103904.mail.ssk.yahoo.co.jp> <92417.57492.qm@web103908.mail.ssk.yahoo.co.jp> <027D94FC-F507-4A64-99DC-B60E03D55D3B@fubar.geek.nz> Date: Thu, 2 Aug 2018 20:08:40 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: One last item: CNS1102 support removal To: Warner Losh , Andrew Turner Cc: "freebsd-arm@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 11:10:28 -0000 Hi=0A=0AI always use ZRouter build system. But I try normal build system.= =0A=0AI use this.=0A=0A=3D=3D=3D=0Aexport MAKEOBJDIRPREFIX=3D/storage/home/= hiroki/armbuild/obj=0A=0Acd /storage/home/hiroki/freebsd=0A=0Amake buildwor= ld TARGET_ARCH=3Darm=0A=0Amake buildkernel TARGET_ARCH=3Darm KERNCONF=3DRT1= 310=0A=3D=3D=3D=0A=0AI do this then my cheap server is endless compile abou= t 2 days.=0A=0AHow do I check RT1310 build ?=0A=0ARegards=0A=0AHiroki Mori= =0A=0A----- Original Message -----=0A>From: Warner Losh =0A= >To: Andrew Turner =0A>Cc: Mori Hiroki ; "freebsd-arm@freebsd.org" =0A>Date: 20= 18/7/20, Fri 01:20=0A>Subject: Re: One last item: CNS1102 support removal= =0A> =0A>=0A>=0A>=0A>=0A>=0A>On Thu, Jul 19, 2018 at 3:25 AM, Andrew Turner= wrote:=0A>=0A>=0A>>> On 18 Jul 2018, at 23:44, Mori= Hiroki wrote:=0A>>> =0A>>> Hi=0A>>> =0A>>> =0A>>> = ----- Original Message -----=0A>>>> From: Warner Losh =0A>>= >> To: Mori Hiroki =0A>>>> Cc: "freebsd-arm@freebsd= .org" =0A>>>> Date: 2018/7/19, Thu 03:01=0A>>>> Su= bject: Re: One last item: CNS1102 support removal=0A>>>> =0A>>>> =0A>>>> = =0A>>>> =0A>>>> =0A>>>> =0A>>>> On Wed, Jul 18, 2018 at 11:41 AM, Mori Hiro= ki wrote:=0A>>>> =0A>>>> Hi=0A>>>>> =0A>>>>> =0A>>>= >> sys/arm/ralink is work fine. Please do not remove this.=0A>>>> =0A>>>> = =0A>>>> OK. Do you have a kernel config file we can commit to the tree? I d= on't even know if it compiles, apart from your dmesg posts. I wasn't sure b= ased on your email, so I thought I'd ask for clarification.=0A>>> =0A>>> Th= is is kernel configure file.=0A>>> =0A>>> https://svnweb.freebsd.org/ base/= head/sys/arm/conf/RT1310? view=3Dmarkup=0A>>=0A>>That config file fails to = build. It's marked with NO_UNIVERSE so it won=E2=80=99t be tested by the un= iverse of tinderbox targets.=0A>>=0A>=0A>=0A>It's missing the machine direc= tive, the cpu directive, the hints file it specifies isn't there and the fv= and rt1310gpio devices specified in it aren't found. Fixing all that gives= :=0A>=0A>=0A>--- rt1310_intc.o ---=0A>/usr/home/imp/git/head/sys/arm/ralink= /rt1310_intc.c:404:7: error: implicit declaration of function 'fdt_is_compa= tible' is invalid in C99 [-Werror,-Wimplicit-function-declaration]=0A>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 if (!fdt_is_compatible(node, "lpc,pic"))=0A>=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^=0A>/usr/home/imp/git/head/sys/a= rm/ralink/rt1310_intc.c:404:7: note: did you mean 'fdt_find_compatible'?=0A= >/usr/home/imp/git/head/sys/dev/fdt/fdt_common.h:85:11: note: 'fdt_find_com= patible' declared here=0A>phandle_t fdt_find_compatible(phandle_t, const ch= ar *, int);=0A>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^=0A>/usr/home/imp/git/he= ad/sys/arm/ralink/rt1310_intc.c:404:7: error: this function declaration is = not a prototype [-Werror,-Wstrict-prototypes]=0A>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 if (!fdt_is_compatible(node, "lpc,pic"))=0A>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0^=0A>2 errors generated.=0A>*** [rt1310_intc.o] Error = code 1=0A>=0A>=0A>make[2]: stopped in /usr/home/imp/obj/usr/home/imp/git/he= ad/arm.arm/sys/RT1310=0A>=0A>=0A>Warner=0A>=0A>=0A> From owner-freebsd-arm@freebsd.org Thu Aug 2 14:35:35 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2667C106910B for ; Thu, 2 Aug 2018 14:35:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 BC5C88B551 for ; Thu, 2 Aug 2018 14:35:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 813E11069107; Thu, 2 Aug 2018 14:35:34 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F8E11069105 for ; Thu, 2 Aug 2018 14:35:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 EB70C8B54D for ; Thu, 2 Aug 2018 14:35:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1flEhF-000LJR-37 for arm@freebsd.org; Thu, 02 Aug 2018 17:35:21 +0300 From: Daniel Braniss Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: booting current from nano-neo/allwinner now failes Message-Id: Date: Thu, 2 Aug 2018 17:35:20 +0300 To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 14:35:35 -0000 Hi, my last working version is from r333513, so im trying the latest, and = with the old u-boot/ubldr I get as far as: U-Boot SPL 2017.09 (Feb 11 2018 - 10:52:39) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2017.09 (Feb 11 2018 - 10:52:39 +0200) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO DRAM: 512 MiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0=20 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 238552 bytes read in 39 ms (5.8 MiB/s) ## Starting application at 0x42000000 ... Consoles: U-Boot console =20 Compatible U-Boot API signature found @0x5bf3f3c0 FreeBSD/armv7 U-Boot loader, Revision 1.2 (Wed Mar 7 13:42:45 IST 2018 danny@pe-44) DRAM: 512MB MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Number of U-Boot devices: 1 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0s2: Loading /boot/defaults/loader.conf /boot/kernel/kernel data=3D0x6fde64+0xa619c = syms=3D[0x4+0x81d80+0x4+0xd41b9] / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x5c1a Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. Kernel entry at 0x42200100... Kernel args: (null) if I update to the latest u-boot/ubldr it failes trying to read from = disk: U-Boot SPL 2018.07 (Aug 01 2018 - 17:37:02 +0300) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2018.07 (Aug 01 2018 - 17:37:02 +0300) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO DRAM: 512 MiB MMC: SUNXI SD/MMC: 0 Loading Environment from FAT... *** Warning - bad CRC, using default = environment Failed (-5) In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0=20 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 199 bytes read in 1 ms (194.3 KiB/s) ## Executing script at 43100000 288084 bytes read in 19 ms (14.5 MiB/s) ## Starting application at 0x42000000 ... Consoles: U-Boot console =20 Compatible U-Boot API signature found @0x5bf524e8 FreeBSD/armv7 U-Boot loader, Revision 1.2 (Wed Aug 1 18:30:42 IDT 2018 danny@dell) DRAM: 512MB Number of U-Boot devices: 1 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=3D0 slice=3D partition=3D... Checking unit=3D1 slice=3D partition=3D... Checking unit=3D2 slice=3D partition=3D... Checking unit=3D3 slice=3D partition=3D... Checking unit=3D4 slice=3D partition=3D... Checking unit=3D5 slice=3D partition=3D... Found U-Boot device: net Booting from net0: net_probe: no network devices found, maybe not enumerated yet..? netboot: couldn't probe uboot_eth0 net_open: netif_open() failed net_probe: no network devices found, maybe not enumerated yet..? netboot: couldn't probe uboot_eth0 net_open: netif_open() failed net_probe: no network devices found, maybe not enumerated yet..? =E2=80=A6 I know that this board is not really supported but it=E2=80=99s listed = in https://wiki.freebsd.org/FreeBSD/arm/Allwinner = in any case I would like to help but things are getting too complicated = :-) thanks, danny From owner-freebsd-arm@freebsd.org Thu Aug 2 14:58:29 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2B531069A19 for ; Thu, 2 Aug 2018 14:58:29 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (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 51C778BF8C; Thu, 2 Aug 2018 14:58:29 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w72EwRxj053497; Thu, 2 Aug 2018 15:58:27 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w72EwRhu053496; Thu, 2 Aug 2018 15:58:27 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201808021458.w72EwRhu053496@donotpassgo.dyslexicfish.net> Date: Thu, 02 Aug 2018 15:58:27 +0100 Organization: Dyslexic Fish To: marklmi@yahoo.com, markj@freebsd.org, fbsd@www.zefox.net Cc: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> In-Reply-To: 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 (donotpassgo.dyslexicfish.net [104.207.135.49]); Thu, 02 Aug 2018 15:58:27 +0100 (BST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 14:58:29 -0000 "Me too" - running with the head src from yesterday, this time with swap on the mmc card, I get: syslog: Aug 2 10:39:57 tiffany kernel: v_free_count: 3221, v_inactive_count: 1 syslog: Aug 2 10:39:59 tiffany kernel: pid 30593 (c++), uid 0, was killed: out of swap space 15 minute output of swapinfo, gstat -abd -I 10s, sysctl vm, and syslog up to the fail at: http://catflap.org/jamie/rpi3/ Look at the end of the file, and scroll up as required! I have it currently running again, using swap only from usb stick, and will post the results there when complete. Hope this helps! By the way, if remote access to the rpi3 would be helpful, you can have it, there's basically nothing on it, but this testing stuff, so anything can be modified/delete/blown up without issue! Cheers, Jamie From owner-freebsd-arm@freebsd.org Thu Aug 2 16:26:42 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB32E106BB99 for ; Thu, 2 Aug 2018 16:26:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 439308F7C6 for ; Thu, 2 Aug 2018 16:26:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 051BB106BB96; Thu, 2 Aug 2018 16:26:42 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEB34106BB95 for ; Thu, 2 Aug 2018 16:26:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 554318F7C5 for ; Thu, 2 Aug 2018 16:26:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id s7-v6so4271811itb.4 for ; Thu, 02 Aug 2018 09:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FxaaSYSHSVz5HghEFVMfFPAjmqk/kcdEPcx8i5Sc2H8=; b=PFznmQZ6WPNnC3wpaydavOK4KC6vAR3XW0pTlekJ7gWHOVuwRvkFlzTFhC7N7oeVst qR9/Ox3+YIm5buLUGCEfFF6pe9F0Yxr370321Df48wuXFL5XxrDdRzPKI6rFW/UL7BNO Y+FoA4iVQDGRCUIaJ0Fn+2wVkgf1Ldc/XhuK8HSh5zZ5C2hQbZD1JlGxnm+Ak5BxS0zB 8GQllpk/2vdbraDw0CK5bGkV2U3uHl6dQp7am/8NXUUqx2JyFDJxcx7XoT6MhVPbU4As RYj7m7wJFJ0ly66RH/GPybiTLeGywcJi6bNv9TD199O205zoOyU6qXqn8saa6MS1zPU7 GyMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FxaaSYSHSVz5HghEFVMfFPAjmqk/kcdEPcx8i5Sc2H8=; b=YFlkrKgb3VxtKGTjtsBVXrUO/YJ6g5s5nFVEvpQQ2XFqJzLMPBj7hXd9j7KtqYZ4tz oESbzZ7BY2ETs7se420HnOH8bLdyiWgeT+0pJ2OKO01yCqDHnjlFVudQ62gdWgcIM/Fr 7Q8puPMmD6eGB6XK+J/bBnyv4PBgA2aruExGBBjndKvJwdwzz6ghr1QRslf8Fcuvk7U+ JYy41VQHIvvsssqJ+rFCDCkLWMBNEu/0NcNvr7FHv6NOmsqx1Qp3+y+xSNOXFKI4PKEt QXv9Mu32V4ZTfnEHMf3u4sX1Pqu+lxbg2knG/T8SDyX1koiiIaVmOt+RUriis7CTqjqn A+jw== X-Gm-Message-State: AOUpUlHxx4nVXTCE304L2kxLxRm1gPSdyNjBqMh7yFUrz8XxE38FV6Uf HHmF5VqRrlQSKMZcNgoSDGxKeo7r2hh/wFw3N9QlkA== X-Google-Smtp-Source: AAOMgpf2yhuw1gW7hWQqAmKCfo0zwi9izyI39O9J69SlsJVnuBT2F6m2+5zTXYbqRuYE/UETL9xIWt51HBxEdf8xE54= X-Received: by 2002:a02:bb04:: with SMTP id y4-v6mr180562jan.5.1533227200652; Thu, 02 Aug 2018 09:26:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 2 Aug 2018 17:26:29 +0100 Message-ID: Subject: Re: booting current from nano-neo/allwinner now failes To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 16:26:43 -0000 Try the latest ubldr There was a change in the last day that should fix this.. Warner On Thu, Aug 2, 2018, 3:36 PM Daniel Braniss wrote: > Hi, > my last working version is from r333513, so im trying the latest, and wit= h > the old u-boot/ubldr I > get as far as: > > U-Boot SPL 2017.09 (Feb 11 2018 - 10:52:39) > DRAM: 512 MiB > Trying to boot from MMC1 > > > U-Boot 2017.09 (Feb 11 2018 - 10:52:39 +0200) Allwinner Technology > > CPU: Allwinner H3 (SUN8I 1680) > Model: FriendlyARM NanoPi NEO > DRAM: 512 MiB > MMC: SUNXI SD/MMC: 0 > *** Warning - bad CRC, using default environment > > In: serial > Out: serial > Err: serial > Net: phy interface0 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found FreeBSD U-Boot Loader (bin) > reading ubldr.bin > 238552 bytes read in 39 ms (5.8 MiB/s) > ## Starting application at 0x42000000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0x5bf3f3c0 > > FreeBSD/armv7 U-Boot loader, Revision 1.2 > (Wed Mar 7 13:42:45 IST 2018 danny@pe-44) > > DRAM: 512MB > MMC Device 1 not found > MMC Device 2 not found > MMC Device 3 not found > Number of U-Boot devices: 1 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=3D0 slice=3D partition=3D... good. > Booting from disk0s2: > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=3D0x6fde64+0xa619c syms=3D[0x4+0x81d80+0x4+0xd41= b9] > / > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x5c1a > Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. > Kernel entry at 0x42200100... > Kernel args: (null) > > > if I update to the latest u-boot/ubldr it failes trying to read from disk= : > > U-Boot SPL 2018.07 (Aug 01 2018 - 17:37:02 +0300) > DRAM: 512 MiB > Trying to boot from MMC1 > > > U-Boot 2018.07 (Aug 01 2018 - 17:37:02 +0300) Allwinner Technology > > CPU: Allwinner H3 (SUN8I 1680) > Model: FriendlyARM NanoPi NEO > DRAM: 512 MiB > MMC: SUNXI SD/MMC: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > Failed (-5) > In: serial > Out: serial > Err: serial > Net: phy interface0 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found U-Boot script /boot.scr > 199 bytes read in 1 ms (194.3 KiB/s) > ## Executing script at 43100000 > 288084 bytes read in 19 ms (14.5 MiB/s) > ## Starting application at 0x42000000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0x5bf524e8 > > FreeBSD/armv7 U-Boot loader, Revision 1.2 > (Wed Aug 1 18:30:42 IDT 2018 danny@dell) > > DRAM: 512MB > Number of U-Boot devices: 1 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=3D0 slice=3D partition=3D... > Checking unit=3D1 slice=3D partition=3D... > Checking unit=3D2 slice=3D partition=3D... > Checking unit=3D3 slice=3D partition=3D... > Checking unit=3D4 slice=3D partition=3D... > Checking unit=3D5 slice=3D partition=3D... > Found U-Boot device: net > Booting from net0: > net_probe: no network devices found, maybe not enumerated yet..? > netboot: couldn't probe uboot_eth0 > net_open: netif_open() failed > net_probe: no network devices found, maybe not enumerated yet..? > netboot: couldn't probe uboot_eth0 > net_open: netif_open() failed > > net_probe: no network devices found, maybe not enumerated yet..? > =E2=80=A6 > > > I know that this board is not really supported but it=E2=80=99s listed in > https://wiki.freebsd.org/FreeBSD/arm/Allwinner < > https://wiki.freebsd.org/FreeBSD/arm/Allwinner> > in any case I would like to help but things are getting too complicated > :-) > > > thanks, > danny > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Aug 2 16:31:42 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B4AB106BDFA for ; Thu, 2 Aug 2018 16:31:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 EAA6A8FB4D for ; Thu, 2 Aug 2018 16:31:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id AFFD3106BDF9; Thu, 2 Aug 2018 16:31:41 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D93D106BDF8 for ; Thu, 2 Aug 2018 16:31:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 EF2008FB46 for ; Thu, 2 Aug 2018 16:31:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1flGVj-0000qS-96; Thu, 02 Aug 2018 19:31:35 +0300 From: Daniel Braniss Message-Id: <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: booting current from nano-neo/allwinner now failes Date: Thu, 2 Aug 2018 19:31:35 +0300 In-Reply-To: Cc: "freebsd-arm@freebsd.org" To: Warner Losh References: X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 16:31:42 -0000 > On 2 Aug 2018, at 19:26, Warner Losh wrote: >=20 > Try the latest ubldr > There was a change in the last day that should fix this.. >=20 I thought I had the latest, will try again. BTW, I only updated the u-boot, and now it=E2=80=99s trying to boot via = the net!, and the ether is actually working, i=E2=80=99ll compile a kernel with nfs root support =E2=80=A6 thanks, danny > Warner >=20 > On Thu, Aug 2, 2018, 3:36 PM Daniel Braniss > wrote: > Hi, > my last working version is from r333513, so im trying the latest, and = with the old u-boot/ubldr I > get as far as: >=20 > U-Boot SPL 2017.09 (Feb 11 2018 - 10:52:39) > DRAM: 512 MiB > Trying to boot from MMC1 >=20 >=20 > U-Boot 2017.09 (Feb 11 2018 - 10:52:39 +0200) Allwinner Technology >=20 > CPU: Allwinner H3 (SUN8I 1680) > Model: FriendlyARM NanoPi NEO > DRAM: 512 MiB > MMC: SUNXI SD/MMC: 0 > *** Warning - bad CRC, using default environment >=20 > In: serial > Out: serial > Err: serial > Net: phy interface0 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0=20 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found FreeBSD U-Boot Loader (bin) > reading ubldr.bin > 238552 bytes read in 39 ms (5.8 MiB/s) > ## Starting application at 0x42000000 ... > Consoles: U-Boot console =20 > Compatible U-Boot API signature found @0x5bf3f3c0 >=20 > FreeBSD/armv7 U-Boot loader, Revision 1.2 > (Wed Mar 7 13:42:45 IST 2018 danny@pe-44) >=20 > DRAM: 512MB > MMC Device 1 not found > MMC Device 2 not found > MMC Device 3 not found > Number of U-Boot devices: 1 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=3D0 slice=3D partition=3D... good. > Booting from disk0s2: > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=3D0x6fde64+0xa619c = syms=3D[0x4+0x81d80+0x4+0xd41b9] > / > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x5c1a > Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. > Kernel entry at 0x42200100... > Kernel args: (null) >=20 >=20 > if I update to the latest u-boot/ubldr it failes trying to read from = disk: >=20 > U-Boot SPL 2018.07 (Aug 01 2018 - 17:37:02 +0300) > DRAM: 512 MiB > Trying to boot from MMC1 >=20 >=20 > U-Boot 2018.07 (Aug 01 2018 - 17:37:02 +0300) Allwinner Technology >=20 > CPU: Allwinner H3 (SUN8I 1680) > Model: FriendlyARM NanoPi NEO > DRAM: 512 MiB > MMC: SUNXI SD/MMC: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default = environment >=20 > Failed (-5) > In: serial > Out: serial > Err: serial > Net: phy interface0 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0=20 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found U-Boot script /boot.scr > 199 bytes read in 1 ms (194.3 KiB/s) > ## Executing script at 43100000 > 288084 bytes read in 19 ms (14.5 MiB/s) > ## Starting application at 0x42000000 ... > Consoles: U-Boot console =20 > Compatible U-Boot API signature found @0x5bf524e8 >=20 > FreeBSD/armv7 U-Boot loader, Revision 1.2 > (Wed Aug 1 18:30:42 IDT 2018 danny@dell) >=20 > DRAM: 512MB > Number of U-Boot devices: 1 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=3D0 slice=3D partition=3D... > Checking unit=3D1 slice=3D partition=3D... > Checking unit=3D2 slice=3D partition=3D... > Checking unit=3D3 slice=3D partition=3D... > Checking unit=3D4 slice=3D partition=3D... > Checking unit=3D5 slice=3D partition=3D... > Found U-Boot device: net > Booting from net0: > net_probe: no network devices found, maybe not enumerated yet..? > netboot: couldn't probe uboot_eth0 > net_open: netif_open() failed > net_probe: no network devices found, maybe not enumerated yet..? > netboot: couldn't probe uboot_eth0 > net_open: netif_open() failed >=20 > net_probe: no network devices found, maybe not enumerated yet..? > =E2=80=A6 >=20 >=20 > I know that this board is not really supported but it=E2=80=99s listed = in https://wiki.freebsd.org/FreeBSD/arm/Allwinner = = > > in any case I would like to help but things are getting too = complicated :-) >=20 >=20 > thanks, > danny >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Thu Aug 2 16:39:16 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82A9E106C187 for ; Thu, 2 Aug 2018 16:39:16 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 136D67010E for ; Thu, 2 Aug 2018 16:39:16 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id CC73B106C185; Thu, 2 Aug 2018 16:39:15 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 908AF106C184 for ; Thu, 2 Aug 2018 16:39:15 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 1A9E07010B for ; Thu, 2 Aug 2018 16:39:14 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 918c71ca-9672-11e8-904b-1d2e466b3c59 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 918c71ca-9672-11e8-904b-1d2e466b3c59; Thu, 02 Aug 2018 16:39:06 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w72Gd4aJ040897; Thu, 2 Aug 2018 10:39:04 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1533227944.1369.37.camel@freebsd.org> Subject: Re: booting current from nano-neo/allwinner now failes From: Ian Lepore To: Daniel Braniss , Warner Losh Cc: "freebsd-arm@freebsd.org" Date: Thu, 02 Aug 2018 10:39:04 -0600 In-Reply-To: <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> References: <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 16:39:16 -0000 On Thu, 2018-08-02 at 19:31 +0300, Daniel Braniss wrote: > > > > > On 2 Aug 2018, at 19:26, Warner Losh wrote: > > > > Try the latest ubldr > >  There was a change in the last day that should fix this.. > > > I thought I had the latest, will try again. > BTW, I only updated the u-boot, and now it’s trying to boot via the > net!, and the ether is actually working, > i’ll compile a kernel with nfs root support … > > thanks, > danny > Well, no, it's failing to boot via net, and if it's modern uboot, it will always fail. There is a "net device" in ubldr, but when it tries to probe, uboot fails to respond, because CONFIG_API no longer supports network devices in modern uboot that uses DM (Device Manager). The only way to netboot with modern uboot is via UEFI. Unfortunately, you don't get the kind of local control that ubldr provided; the boot parameters (where to find the root filesystem, etc) must come from the dhcp/bootp server. That's a bit of a showstopper for many folks who don't have that level of control over the dhcp server config. -- Ian > > > > > Warner > > > > On Thu, Aug 2, 2018, 3:36 PM Daniel Braniss > > wrote: > > Hi, > > my last working version is from r333513, so im trying the latest, > > and with the old u-boot/ubldr I > > get as far as: > > > > U-Boot SPL 2017.09 (Feb 11 2018 - 10:52:39) > > DRAM: 512 MiB > > Trying to boot from MMC1 > > > > > > U-Boot 2017.09 (Feb 11 2018 - 10:52:39 +0200) Allwinner Technology > > > > CPU:   Allwinner H3 (SUN8I 1680) > > Model: FriendlyARM NanoPi NEO > > DRAM:  512 MiB > > MMC:   SUNXI SD/MMC: 0 > > *** Warning - bad CRC, using default environment > > > > In:    serial > > Out:   serial > > Err:   serial > > Net:   phy interface0 > > eth0: ethernet@1c30000 > > starting USB... > > USB0:   USB EHCI 1.00 > > USB1:   USB OHCI 1.0 > > scanning bus 0 for devices... 1 USB Device(s) found > >       scanning usb for storage devices... 0 Storage Device(s) found > > Hit any key to stop autoboot:  0  > > switch to partitions #0, OK > > mmc0 is current device > > Scanning mmc 0:1... > > Found FreeBSD U-Boot Loader (bin) > > reading ubldr.bin > > 238552 bytes read in 39 ms (5.8 MiB/s) > > ## Starting application at 0x42000000 ... > > Consoles: U-Boot console   > > Compatible U-Boot API signature found @0x5bf3f3c0 > > > > FreeBSD/armv7 U-Boot loader, Revision 1.2 > > (Wed Mar  7 13:42:45 IST 2018 danny@pe-44) > > > > DRAM: 512MB > > MMC Device 1 not found > > MMC Device 2 not found > > MMC Device 3 not found > > Number of U-Boot devices: 1 > > U-Boot env: loaderdev not set, will probe all devices. > > Found U-Boot device: disk > >  Probing all disk devices... > >  Checking unit=0 slice= partition=... good. > > Booting from disk0s2: > > Loading /boot/defaults/loader.conf > > /boot/kernel/kernel data=0x6fde64+0xa619c > > syms=[0x4+0x81d80+0x4+0xd41b9] > > / > > Hit [Enter] to boot immediately, or any other key for command > > prompt. > > Booting [/boot/kernel/kernel]...                > > /boot/dtb/sun8i-h3-nanopi-neo.dtb size=0x5c1a > > Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. > > Kernel entry at 0x42200100... > > Kernel args: (null) > > > > > > if I update to the latest u-boot/ubldr it failes trying to read > > from disk: > > > > U-Boot SPL 2018.07 (Aug 01 2018 - 17:37:02 +0300) > > DRAM: 512 MiB > > Trying to boot from MMC1 > > > > > > U-Boot 2018.07 (Aug 01 2018 - 17:37:02 +0300) Allwinner Technology > > > > CPU:   Allwinner H3 (SUN8I 1680) > > Model: FriendlyARM NanoPi NEO > > DRAM:  512 MiB > > MMC:   SUNXI SD/MMC: 0 > > Loading Environment from FAT... *** Warning - bad CRC, using > > default environment > > > > Failed (-5) > > In:    serial > > Out:   serial > > Err:   serial > > Net:   phy interface0 > > eth0: ethernet@1c30000 > > starting USB... > > USB0:   USB EHCI 1.00 > > USB1:   USB OHCI 1.0 > > scanning bus 0 for devices... 1 USB Device(s) found > >       scanning usb for storage devices... 0 Storage Device(s) found > > Hit any key to stop autoboot:  0  > > switch to partitions #0, OK > > mmc0 is current device > > Scanning mmc 0:1... > > Found U-Boot script /boot.scr > > 199 bytes read in 1 ms (194.3 KiB/s) > > ## Executing script at 43100000 > > 288084 bytes read in 19 ms (14.5 MiB/s) > > ## Starting application at 0x42000000 ... > > Consoles: U-Boot console   > > Compatible U-Boot API signature found @0x5bf524e8 > > > > FreeBSD/armv7 U-Boot loader, Revision 1.2 > > (Wed Aug  1 18:30:42 IDT 2018 danny@dell) > > > > DRAM: 512MB > > Number of U-Boot devices: 1 > > U-Boot env: loaderdev not set, will probe all devices. > > Found U-Boot device: disk > >  Probing all disk devices... > >  Checking unit=0 slice= partition=... > >  Checking unit=1 slice= partition=... > >  Checking unit=2 slice= partition=... > >  Checking unit=3 slice= partition=... > >  Checking unit=4 slice= partition=... > >  Checking unit=5 slice= partition=... > > Found U-Boot device: net > > Booting from net0: > > net_probe: no network devices found, maybe not enumerated yet..? > > netboot: couldn't probe uboot_eth0 > > net_open: netif_open() failed > > net_probe: no network devices found, maybe not enumerated yet..? > > netboot: couldn't probe uboot_eth0 > > net_open: netif_open() failed > > > > net_probe: no network devices found, maybe not enumerated yet..? > > … > > > > > > I know that this board is not really supported but it’s listed in h > > ttps://wiki.freebsd.org/FreeBSD/arm/Allwinner > > > > > > > > in any case I would like to help  but things are getting too > > complicated :-) > > > > > > thanks, > >         danny > > > > > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing > > list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.o > > rg " > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org > " > From owner-freebsd-arm@freebsd.org Thu Aug 2 17:29:54 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22069106D4B2 for ; Thu, 2 Aug 2018 17:29:54 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B32C871D75 for ; Thu, 2 Aug 2018 17:29:53 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1533230986; bh=12/86UjYBrwDsLsa5WTYrotavDHyOYB/qBHY6sU51ss=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=nCUgG1Dw1lx//V8FjI2JdJ8UCEmFjytgmtVKiJEzHwm8yQZ6u6trdtqPI78RCAkDo Lxpgb1mw5ux41PhKKK9TCr6/OJwF+Dt5MjuPRjS6sh16rtNCRGE0UsnbypmEkEuGs5 UgXnx0D9d4c/4O6PNVodBKKPzX3pvpEzXNQmCO1I= Subject: Re: rpi3 and Adafruit GPS Hat To: Diane Bruce Cc: freebsd-arm@freebsd.org References: <47f49a55-66b0-1c02-4530-4701a3bd0c43@nethead.se> <20180718170157.GA40221@night.db.net> From: Per olof Ljungmark Message-ID: <69777450-a532-3f00-c2ed-426d20a6bf0e@nethead.se> Date: Thu, 2 Aug 2018 19:29:44 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180718170157.GA40221@night.db.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 17:29:54 -0000 On 7/18/18 7:01 PM, Diane Bruce wrote: > On Wed, Jul 18, 2018 at 05:10:16PM +0200, Per olof Ljungmark wrote: >> Being a complete newbie to arm I thought a nice project would be to >> build a NTP server with the parts in the subject line. >> >> Unfortunately I have almost no idea where to start, it seems FreeBSD for >> arm have shifted around quite a bit, almost none of the googled pages I >> find has relevance, and to add insult to injury, the Pi project >> apparently shifted the serial ports around for the Pi3. >> >> What I need to achieve, >> >> - Stop the kernel to use the uart for console output (I have ethernet >> and HDMI connected) > > No need. > > change your config.txt > > #dtoverlay=pi3-disable-bt > device_tree_address=0x4000 > kernel=u-boot.bin > enable_uart=1 > > This moves the console port to the less capable micro uart port > this will free up the good uart (the pl011 device) as /dev/ttyu0 > > Remove the pi3-disable-dt in config.txt > enable_uart=1 is needed. But would this move uart0 to pin 14 & 15? It moves the serial console to uart1 which is fine bit if I want to talk to the hat I need uart0 on pins 14 and 15. From owner-freebsd-arm@freebsd.org Thu Aug 2 17:55:22 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF70E106E167 for ; Thu, 2 Aug 2018 17:55:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3BE73B7C for ; Thu, 2 Aug 2018 17:55:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 140E2106E166; Thu, 2 Aug 2018 17:55:22 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5DDF106E165 for ; Thu, 2 Aug 2018 17:55:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C04A73B79 for ; Thu, 2 Aug 2018 17:55:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id o22-v6so2749601ioh.6 for ; Thu, 02 Aug 2018 10:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EZnVzuuvH94FxjH3c0CK9EtkQEzcb8V9nNzk2zSEDQ4=; b=fujlEmTLgw76PmBoQ4ZIJygnU4NfQsQa5NQ3VmIRtCnSjDEyqFo6eCoJ+JE3DyPipk JvqUdWkUBz3gHWob4RbekgBbhwNymp7bayjiCvz9As2x/vwFUiCHtqTqLtujm2XGmN0v WGzCO0N/SuzVLWJO8xQNeBbtvxoWkrUJ+CIOlngFMy918JbK6YDomFqUD7KFjZk0HtFn YOHbYA8xn4u6KdOwLOEQT/bAvd6is7a2eC5MDxDpmtYp2gZ5iPnjlwYFaHaoPEC0/QDr Xf3BMGE1eYA9+WerC2CG8OoQPP2n1GkvuSgFOJXcBwYULo1bAkS1zztjMZ+2iRz4JqSq Xjew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EZnVzuuvH94FxjH3c0CK9EtkQEzcb8V9nNzk2zSEDQ4=; b=OWaGZPrDUJu766+gErbLdJoWbLmM318N2GZtffLyES115rNQXlCYfsxbXp3aH9jRZN QF41Au+u+2+AOPOSJO8eQWzqK+Zd87+pU6K7daXuvJ/tuhkVs7o4d71mFTCy3pwWDX/y RRGfus47zbcieYkfeGGCVxCVvyqqZcQXg3wPPqYJAdQgq+NKJ9T9LtbhjZzFfuUXGdyd J6Bk5Ue6uQvIasTHWrxSX1Isuck3Up7/LtgX5OYu9538Io9sc4hFYwCoEU1VLhTxoPMm BHcM+VpeGOei6jIOCQ7EGEQQKZVEE4sNFL19ltVghDEar6EJMusTaiH75gyuInj0me1e WGSg== X-Gm-Message-State: AOUpUlFZX/7oIokbxmR9xUrwng2pweX3ONv1H13LZiGC7x5LyBrvIyZP TqRbh6rpTEBv8u2fwil8kB528h21gbM5BPmUwEYuwlLv920= X-Google-Smtp-Source: AA+uWPwmFfSo9bD5beQFw9Irj6+CqUOEdXN+kLlcm5gqDZaY3v8PuUp1XwzaNkVNnJaxLyNbaDXNDKV4aMrXQj0r2ew= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr3337316ioa.168.1533232520639; Thu, 02 Aug 2018 10:55:20 -0700 (PDT) MIME-Version: 1.0 References: <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> <1533227944.1369.37.camel@freebsd.org> In-Reply-To: <1533227944.1369.37.camel@freebsd.org> From: Warner Losh Date: Thu, 2 Aug 2018 18:55:04 +0100 Message-ID: Subject: Re: booting current from nano-neo/allwinner now failes To: Ian Lepore Cc: Daniel Braniss , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 17:55:23 -0000 On Thu, Aug 2, 2018, 5:39 PM Ian Lepore wrote: > On Thu, 2018-08-02 at 19:31 +0300, Daniel Braniss wrote: > > > > > > > > On 2 Aug 2018, at 19:26, Warner Losh wrote: > > > > > > Try the latest ubldr > > > There was a change in the last day that should fix this.. > > > > > I thought I had the latest, will try again. > > BTW, I only updated the u-boot, and now it=E2=80=99s trying to boot via= the > > net!, and the ether is actually working, > > i=E2=80=99ll compile a kernel with nfs root support =E2=80=A6 > > > > thanks, > > danny > > > > Well, no, it's failing to boot via net, and if it's modern uboot, it > will always fail. There is a "net device" in ubldr, but when it tries > to probe, uboot fails to respond, because CONFIG_API no longer supports > network devices in modern uboot that uses DM (Device Manager). > > The only way to netboot with modern uboot is via UEFI. Unfortunately, > you don't get the kind of local control that ubldr provided; the boot > parameters (where to find the root filesystem, etc) must come from the > dhcp/bootp server. That's a bit of a showstopper for many folks who > don't have that level of control over the dhcp server config. > Is that a UEFI issue. Or our loader.efi needs X, Y or Z? Warner -- Ian > > > > > > > > > Warner > > > > > > On Thu, Aug 2, 2018, 3:36 PM Daniel Braniss > > > wrote: > > > Hi, > > > my last working version is from r333513, so im trying the latest, > > > and with the old u-boot/ubldr I > > > get as far as: > > > > > > U-Boot SPL 2017.09 (Feb 11 2018 - 10:52:39) > > > DRAM: 512 MiB > > > Trying to boot from MMC1 > > > > > > > > > U-Boot 2017.09 (Feb 11 2018 - 10:52:39 +0200) Allwinner Technology > > > > > > CPU: Allwinner H3 (SUN8I 1680) > > > Model: FriendlyARM NanoPi NEO > > > DRAM: 512 MiB > > > MMC: SUNXI SD/MMC: 0 > > > *** Warning - bad CRC, using default environment > > > > > > In: serial > > > Out: serial > > > Err: serial > > > Net: phy interface0 > > > eth0: ethernet@1c30000 > > > starting USB... > > > USB0: USB EHCI 1.00 > > > USB1: USB OHCI 1.0 > > > scanning bus 0 for devices... 1 USB Device(s) found > > > scanning usb for storage devices... 0 Storage Device(s) found > > > Hit any key to stop autoboot: 0 > > > switch to partitions #0, OK > > > mmc0 is current device > > > Scanning mmc 0:1... > > > Found FreeBSD U-Boot Loader (bin) > > > reading ubldr.bin > > > 238552 bytes read in 39 ms (5.8 MiB/s) > > > ## Starting application at 0x42000000 ... > > > Consoles: U-Boot console > > > Compatible U-Boot API signature found @0x5bf3f3c0 > > > > > > FreeBSD/armv7 U-Boot loader, Revision 1.2 > > > (Wed Mar 7 13:42:45 IST 2018 danny@pe-44) > > > > > > DRAM: 512MB > > > MMC Device 1 not found > > > MMC Device 2 not found > > > MMC Device 3 not found > > > Number of U-Boot devices: 1 > > > U-Boot env: loaderdev not set, will probe all devices. > > > Found U-Boot device: disk > > > Probing all disk devices... > > > Checking unit=3D0 slice=3D partition=3D... good. > > > Booting from disk0s2: > > > Loading /boot/defaults/loader.conf > > > /boot/kernel/kernel data=3D0x6fde64+0xa619c > > > syms=3D[0x4+0x81d80+0x4+0xd41b9] > > > / > > > Hit [Enter] to boot immediately, or any other key for command > > > prompt. > > > Booting [/boot/kernel/kernel]... > > > /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x5c1a > > > Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. > > > Kernel entry at 0x42200100... > > > Kernel args: (null) > > > > > > > > > if I update to the latest u-boot/ubldr it failes trying to read > > > from disk: > > > > > > U-Boot SPL 2018.07 (Aug 01 2018 - 17:37:02 +0300) > > > DRAM: 512 MiB > > > Trying to boot from MMC1 > > > > > > > > > U-Boot 2018.07 (Aug 01 2018 - 17:37:02 +0300) Allwinner Technology > > > > > > CPU: Allwinner H3 (SUN8I 1680) > > > Model: FriendlyARM NanoPi NEO > > > DRAM: 512 MiB > > > MMC: SUNXI SD/MMC: 0 > > > Loading Environment from FAT... *** Warning - bad CRC, using > > > default environment > > > > > > Failed (-5) > > > In: serial > > > Out: serial > > > Err: serial > > > Net: phy interface0 > > > eth0: ethernet@1c30000 > > > starting USB... > > > USB0: USB EHCI 1.00 > > > USB1: USB OHCI 1.0 > > > scanning bus 0 for devices... 1 USB Device(s) found > > > scanning usb for storage devices... 0 Storage Device(s) found > > > Hit any key to stop autoboot: 0 > > > switch to partitions #0, OK > > > mmc0 is current device > > > Scanning mmc 0:1... > > > Found U-Boot script /boot.scr > > > 199 bytes read in 1 ms (194.3 KiB/s) > > > ## Executing script at 43100000 > > > 288084 bytes read in 19 ms (14.5 MiB/s) > > > ## Starting application at 0x42000000 ... > > > Consoles: U-Boot console > > > Compatible U-Boot API signature found @0x5bf524e8 > > > > > > FreeBSD/armv7 U-Boot loader, Revision 1.2 > > > (Wed Aug 1 18:30:42 IDT 2018 danny@dell) > > > > > > DRAM: 512MB > > > Number of U-Boot devices: 1 > > > U-Boot env: loaderdev not set, will probe all devices. > > > Found U-Boot device: disk > > > Probing all disk devices... > > > Checking unit=3D0 slice=3D partition=3D... > > > Checking unit=3D1 slice=3D partition=3D... > > > Checking unit=3D2 slice=3D partition=3D... > > > Checking unit=3D3 slice=3D partition=3D... > > > Checking unit=3D4 slice=3D partition=3D... > > > Checking unit=3D5 slice=3D partition=3D... > > > Found U-Boot device: net > > > Booting from net0: > > > net_probe: no network devices found, maybe not enumerated yet..? > > > netboot: couldn't probe uboot_eth0 > > > net_open: netif_open() failed > > > net_probe: no network devices found, maybe not enumerated yet..? > > > netboot: couldn't probe uboot_eth0 > > > net_open: netif_open() failed > > > > > > net_probe: no network devices found, maybe not enumerated yet..? > > > =E2=80=A6 > > > > > > > > > I know that this board is not really supported but it=E2=80=99s liste= d in h > > > ttps://wiki.freebsd.org/FreeBSD/arm/Allwinner > > > > > > > > > > > > in any case I would like to help but things are getting too > > > complicated :-) > > > > > > > > > thanks, > > > danny > > > > > > > > > > > > > > > _______________________________________________ > > > freebsd-arm@freebsd.org mailing > > > list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > > > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.o > > > rg " > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org > > " > > > From owner-freebsd-arm@freebsd.org Thu Aug 2 18:01:34 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 590EA106E38B for ; Thu, 2 Aug 2018 18:01:34 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EAFF4740CD for ; Thu, 2 Aug 2018 18:01:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id AFC53106E38A; Thu, 2 Aug 2018 18:01:33 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EA86106E389 for ; Thu, 2 Aug 2018 18:01:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 2FFA7740CB for ; Thu, 2 Aug 2018 18:01:33 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 15483535-967e-11e8-904b-1d2e466b3c59 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 15483535-967e-11e8-904b-1d2e466b3c59; Thu, 02 Aug 2018 18:01:31 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w72I1Uf2041097; Thu, 2 Aug 2018 12:01:30 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1533232890.1369.49.camel@freebsd.org> Subject: Re: booting current from nano-neo/allwinner now failes From: Ian Lepore To: Warner Losh Cc: Daniel Braniss , "freebsd-arm@freebsd.org" Date: Thu, 02 Aug 2018 12:01:30 -0600 In-Reply-To: References: <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> <1533227944.1369.37.camel@freebsd.org> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 18:01:34 -0000 On Thu, 2018-08-02 at 18:55 +0100, Warner Losh wrote: > On Thu, Aug 2, 2018, 5:39 PM Ian Lepore wrote: > > > > > On Thu, 2018-08-02 at 19:31 +0300, Daniel Braniss wrote: > > > > > > > > > > > > > > > > > > On 2 Aug 2018, at 19:26, Warner Losh wrote: > > > > > > > > Try the latest ubldr > > > >  There was a change in the last day that should fix this.. > > > > > > > I thought I had the latest, will try again. > > > BTW, I only updated the u-boot, and now it’s trying to boot via > > > the > > > net!, and the ether is actually working, > > > i’ll compile a kernel with nfs root support … > > > > > > thanks, > > >       danny > > > > > Well, no, it's failing to boot via net, and if it's modern uboot, > > it > > will always fail. There is a "net device" in ubldr, but when it > > tries > > to probe, uboot fails to respond, because CONFIG_API no longer > > supports > > network devices in modern uboot that uses DM (Device Manager). > > > > The only way to netboot with modern uboot is via UEFI. > > Unfortunately, > > you don't get the kind of local control that ubldr provided; the > > boot > > parameters (where to find the root filesystem, etc) must come from > > the > > dhcp/bootp server. That's a bit of a showstopper for many folks who > > don't have that level of control over the dhcp server config. > > > Is that a UEFI issue. Or our loader.efi needs X, Y or Z? > > Warner With ubldr you set a uboot env var (rootpath) and it gets used instead of anything coming over the wire from the server (it's important that a locally-set value overrides dhcp/bootp values, because the server you can't control may deliver insane values). >From what I've heard, the uboot uefi implementation doesn't give you a way to save persistent efi vars, so right now there's no way to set a local rootpath var. If we had persistent vars, I guess the thing to do would be to define a standard freebsd-specific variable to set the rootpath. -- Ian From owner-freebsd-arm@freebsd.org Thu Aug 2 18:45:42 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AD70104A253 for ; Thu, 2 Aug 2018 18:45:42 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A5C5475BF1 for ; Thu, 2 Aug 2018 18:45:41 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6A25C104A252; Thu, 2 Aug 2018 18:45:41 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F71E104A251 for ; Thu, 2 Aug 2018 18:45:41 +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 97B2975BF0 for ; Thu, 2 Aug 2018 18:45:39 +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 2f333386; Thu, 2 Aug 2018 20:45:37 +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=VrWd0Utejam0pROkfLU1hbguUeE=; b=AiVNvNR7t2ps/tWZTIVmUuz0XZCf xRWS+xO9JNlpfwanEo9It5pbJetAB78NuUxiby0ubvyPYrzd9VOFn+7xZHNhJkbn pUZZe7uKtSjxQUjQcQFpuCMZP27Uw6NHXhDDuE7s+mIVCM8URAcwUJt8SqMkgE0c Jg/4q1YwuQEo2WQ= 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=fTGlZUBLWQ5IRK4I4q33T1WNi5tpW+mqb14CWNDpGhLGvZDmGpisQD5X h7spb2SCznKo1Mm1BfRK+k2t/BoFCzmhOVp/+fTXQPsOEcD8FjHKH/0zpIfDU4mq 63pCQdlQRT+Cx49f3PC2bF9SoyQm75JsI2ao8KgPX5btsSjc6i0= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 7f675b5a TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 2 Aug 2018 20:45:37 +0200 (CEST) Date: Thu, 2 Aug 2018 20:45:37 +0200 From: Emmanuel Vadot To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" Subject: Re: booting current from nano-neo/allwinner now failes Message-Id: <20180802204537.26af888414c4561b624fafd3@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 18:45:42 -0000 On Thu, 2 Aug 2018 17:35:20 +0300 Daniel Braniss wrote: > Hi, > my last working version is from r333513, so im trying the latest, and wit= h the old u-boot/ubldr I > get as far as: >=20 > U-Boot SPL 2017.09 (Feb 11 2018 - 10:52:39) > DRAM: 512 MiB > Trying to boot from MMC1 >=20 >=20 > U-Boot 2017.09 (Feb 11 2018 - 10:52:39 +0200) Allwinner Technology >=20 > CPU: Allwinner H3 (SUN8I 1680) > Model: FriendlyARM NanoPi NEO > DRAM: 512 MiB > MMC: SUNXI SD/MMC: 0 > *** Warning - bad CRC, using default environment >=20 > In: serial > Out: serial > Err: serial > Net: phy interface0 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0=20 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found FreeBSD U-Boot Loader (bin) > reading ubldr.bin > 238552 bytes read in 39 ms (5.8 MiB/s) > ## Starting application at 0x42000000 ... > Consoles: U-Boot console =20 > Compatible U-Boot API signature found @0x5bf3f3c0 >=20 > FreeBSD/armv7 U-Boot loader, Revision 1.2 > (Wed Mar 7 13:42:45 IST 2018 danny@pe-44) >=20 > DRAM: 512MB > MMC Device 1 not found > MMC Device 2 not found > MMC Device 3 not found > Number of U-Boot devices: 1 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=3D0 slice=3D partition=3D... good. > Booting from disk0s2: > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=3D0x6fde64+0xa619c syms=3D[0x4+0x81d80+0x4+0xd41= b9] > / > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x5c1a > Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. > Kernel entry at 0x42200100... > Kernel args: (null) >=20 >=20 > if I update to the latest u-boot/ubldr it failes trying to read from disk: > > U-Boot SPL 2018.07 (Aug 01 2018 - 17:37:02 +0300) > DRAM: 512 MiB > Trying to boot from MMC1 >=20 >=20 > U-Boot 2018.07 (Aug 01 2018 - 17:37:02 +0300) Allwinner Technology >=20 > CPU: Allwinner H3 (SUN8I 1680) > Model: FriendlyARM NanoPi NEO > DRAM: 512 MiB > MMC: SUNXI SD/MMC: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default envi= ronment >=20 > Failed (-5) > In: serial > Out: serial > Err: serial > Net: phy interface0 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0=20 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found U-Boot script /boot.scr > 199 bytes read in 1 ms (194.3 KiB/s) > ## Executing script at 43100000 > 288084 bytes read in 19 ms (14.5 MiB/s) > ## Starting application at 0x42000000 ... > Consoles: U-Boot console =20 > Compatible U-Boot API signature found @0x5bf524e8 >=20 > FreeBSD/armv7 U-Boot loader, Revision 1.2 > (Wed Aug 1 18:30:42 IDT 2018 danny@dell) >=20 > DRAM: 512MB > Number of U-Boot devices: 1 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=3D0 slice=3D partition=3D... > Checking unit=3D1 slice=3D partition=3D... > Checking unit=3D2 slice=3D partition=3D... > Checking unit=3D3 slice=3D partition=3D... > Checking unit=3D4 slice=3D partition=3D... > Checking unit=3D5 slice=3D partition=3D... > Found U-Boot device: net > Booting from net0: > net_probe: no network devices found, maybe not enumerated yet..? > netboot: couldn't probe uboot_eth0 > net_open: netif_open() failed > net_probe: no network devices found, maybe not enumerated yet..? > netboot: couldn't probe uboot_eth0 > net_open: netif_open() failed >=20 > net_probe: no network devices found, maybe not enumerated yet..? > ? >=20 Did you also update ubldr.bin ? (not just ubldr) This is what I have for this board : U-Boot SPL 2018.07 (Jul 24 2018 - 23:24:15 +0000) DRAM: 512 MiB Trying to boot from MMC1 =20 =20 =20 U-Boot 2018.07 (Jul 24 2018 - 23:24:15 +0000) Allwinner Technology =20 CPU: Allwinner H3 (SUN8I 1680) =20 Model: FriendlyARM NanoPi NEO DRAM: 512 MiB MMC: SUNXI SD/MMC: 0 =20 Loading Environment from FAT... *** Warning - bad CRC, using default environment=20 Failed (-5) In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 =20 USB1: USB OHCI 1.0 =20 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 199 bytes read in 1 ms (194.3 KiB/s) ## Executing script at 43100000 288092 bytes read in 14 ms (19.6 MiB/s) ## Starting application at 0x42000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x5bf524e8 FreeBSD/armv7 U-Boot loader, Revision 1.2 (Fri Jul 27 18:07:48 UTC 2018 root@wopr.blih.net) DRAM: 512MB Number of U-Boot devices: 1 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0s2a: Loading /boot/defaults/loader.conf /boot/kernel/kernel data=3D0x8f40a4+0x1dff5c syms=3D[0x4+0xa9940+0x4+0x10e1fa] /boot/entropy size=3D0x1000 /boot/kernel/umodem.ko text=3D0x2e80 data=3D0x2cc+0x8 syms=3D[0x4+0xbd0+0x4+0xc4f] loading required module 'ucom' /boot/kernel/ucom.ko text=3D0x4d44 data=3D0x418+0x83c syms=3D[0x4+0xf90+0x4+0xcdf] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x5c1a Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. Kernel entry at 0x42200100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 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 12.0-CURRENT #0 r336765: Fri Jul 27 18:20:04 UTC 2018 root@wopr.blih.net:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) ... > I know that this board is not really supported but it?s listed in https:/= /wiki.freebsd.org/FreeBSD/arm/Allwinner Don't worry it's supported, it's not because we don't generate an image that it isn't. Also please consider switching to efi boot, just deleting boot.scr and copying loader.efi as EFI/BOOT/bootarm.efi is enough. > in any case I would like to help but things are getting too complicated = :-) >=20 >=20 > thanks, > danny >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Aug 2 18:53:19 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AA14104A60A for ; Thu, 2 Aug 2018 18:53:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7B6876208 for ; Thu, 2 Aug 2018 18:53:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 3FrbMx8VM1ldarww7CmRccu2F6l_fxtWXwhMg0FysntoFTwjWPp58XunbXBfi41 AF1nrFjDZI6y82tCBt1PJF6Cnr1jBxlm41GD8BJE3.vNlzhwy0rFwq_7Xoa00jgEXyNxiNNEAxUx Fb_DBftKdNi29WXvzWdL9ZR.Mc9kvVfNPywWNOMgSUzkhgNM3RWxDkEJpVmY2QxHu_nyt.2DIFt5 NIsr7Ro60GOncUbYsaMwnGmt01FkKRDwF5cYKDYKlvxfILWtGyxISiK4XRgfbZQrYorS4u5f2dTG 6gmE0iA8kC8FkzjrhnqOW9w6iZyOprisGvgfr6cA6R8ENZ8Zc4j_AdmvncBS5et9zgxUJJzYqJr2 8OVvAaeLaIxhdUkpmc3V8eZEtASFhdQJOtvyFUMFrljjxArBsb2EUp.M3Rmo003i_gdjCv4Fj3GU UPjy1zKPr3P5cETOhKxghU1A23fnO.8EH0vvOy0Ut29.Du2MikC4OAT4Z937l_EHxbFKKsJRwOG. kOXH4gfwE3h2HWt.wC2YXE6ABXCTVJEyvstI.549PQVytdhAtlJvZUP0dL9vb6WJvxytasECahbK pE5_RKEovobuiTF6y32lsmoHZpSVf0dnTkvRF7SaJ_MrsyTjS42NHl5fp3VIcZAlkF2LByU8c7pL hI2uJR7wvkF11WTNljtuyC6dsWb4hp8igljYDb1YdR_vgS.Q54Hm7yEuxSirlVcb1Qn54kLPuKay Tw2572l7WdGM9JW0PN7l_IgjPLi6d8s27ooypuKaNqjlqEA.APwc0Il7dTRzlMJu.7IiN5yDDN1K cWZNUceiRTUnEgN18LZ_X1vf1tLujAWknWhDlLDaM2glMl3eMft8tJo62G7.JTeeIExkL5GIGnk0 jAxZtHRLHc6ggF4dc.elB4J16qHuiy1z69Vbr8YfVaM5.Gby0XqP.0Lls0JyxWecpoP2NzJMSYeU KKvEyb0jFGK9f.Mz1kRwicCUON48T91JEcQ0LsXGxYdRqloyHa79Cr3AOo0U3bPU5DvRLSBg9Hpu xMfS6.6qkQZEttg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Thu, 2 Aug 2018 18:53:12 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp403.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 242e16a9824bc74658f56f26638b4f91; Thu, 02 Aug 2018 18:53:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: poudriere-devel build of sysutils/u-boot-pine64 | u-boot-pine64-2018.07_1 failed From: Mark Millard In-Reply-To: <4DBB7051-AEC9-4ECA-B645-0A5AF1C7C856@yahoo.com> Date: Thu, 2 Aug 2018 11:53:10 -0700 Cc: Mark Millard via freebsd-uboot , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <451D906A-3807-4029-BFFA-1A00AD8FB0F9@yahoo.com> <6D377AEB-C359-4DC3-A95F-2A4A72CBF090@yahoo.com> <20180801095942.91dfc4d5907b75b4fe63c1d0@bidouilliste.com> <20180802060927.72eadf5b1f8fe8bcf8860dc3@bidouilliste.com> <4DBB7051-AEC9-4ECA-B645-0A5AF1C7C856@yahoo.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 18:53:19 -0000 [BUILD_DEPENDS+=3D objdump:devel/binutils is sufficient to allow my poudreire-devel context to build u-boot-pine64 .] On 2018-Aug-1, at 11:47 PM, Mark Millard wrote: > [See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230288 .] >=20 > On 2018-Aug-1, at 10:57 PM, Mark Millard wrote: >=20 >> On 2018-Aug-1, at 9:09 PM, Emmanuel Vadot = wrote: >>=20 >>> On Wed, 1 Aug 2018 07:02:08 -0700 >>> Mark Millard via freebsd-uboot wrote: >>>=20 >>>>=20 >>>>=20 >>>> On 2018-Aug-1, at 12:59 AM, Emmanuel Vadot wrote: >>>>=20 >>>>> . . . >>>>=20 >>>> Definitely true that I do not yet know what matters for this = context. >>>> I'll continue to try to figure that out. >>>=20 >>> Well it's a port and you are building via poudriere so just put the >>> log file (the full log file) somewhere so we can have a look. >>> Also arch, ports tree revision, blah, the usual suspects. >>=20 >> The build did not get far: the log file is only 747 lines long. I'll >> probably submit a bugzilla for the issue at some point. I'll report >> the number when I do. >=20 > See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230288 >=20 >> I suggest looking at: >>=20 >> = https://lists.freebsd.org/pipermail/freebsd-ports/2018-August/113981.html >>=20 >> for a recent build failure type that I analyzed (devel/*-gcc = failures). John Baldwin >> reduced the history down to the final result for our exchanges and so = it will will not >> be a long read. The issue was tied to my use of WITHOUT_BINTUILS for = the buildworld >> that was installed and in use but devel/powerpc64-gcc (the master = port for the >> devel/*-gcc ports) not listing devel/binutils in BUILD_DEPENDS in = addition to the >> historical devel/${PKGNAMEPREFIX}binutils for the cross-build. >>=20 >> Other gcc-ish ports that cross-build things may have similar issues = with expecting >> but missing "builder-architecture" tools from binutils. I'm not = claiming that is >> the problem here but it is a fairly new type of problem to be aware = of. >>=20 >>=20 >>=20 >> Just FYI for the pine64 u-boot port context: >> (To be in the bugzilla submittal as well.) >>=20 >> # uname -apKU >> FreeBSD FBSDUSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r336693M amd64 = amd64 1200075 1200075 >>=20 >> (The "M" is mostly for experiments targeting powerpc and powerpc64 >> via fairly modern toolchains. The poudriere-devel jail uses an >> install-tree installed from the same buildworld.) >>=20 >> # svnlite info /usr/ports/ | grep "Re[plv]" >> Relative URL: ^/head >> Repository Root: svn://svn.freebsd.org/ports >> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >> Revision: 476026 >> Last Changed Rev: 476026 I've udpated: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230288 with the following comment: QUOTE The following change to sysutils/u-boot-master/Makefile was sufficient to allow sysutils/u-boot-pine64 to build in my poudriere-devel context that is based on a buildworld that uses WITHOUT_BINTUTILS. (I'm not claiming this is the best form of fix, just noting the behavior of the specific change.) # svnlite diff /usr/ports/sysutils/u-boot-master/Makefile Index: /usr/ports/sysutils/u-boot-master/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/sysutils/u-boot-master/Makefile (revision 476026) +++ /usr/ports/sysutils/u-boot-master/Makefile (working copy) @@ -21,6 +21,7 @@ dtc>=3D1.4.1:sysutils/dtc \ mkimage:sysutils/u-boot-tools BUILD_DEPENDS+=3D ${COMPILER}:devel/${COMPILER} +BUILD_DEPENDS+=3D objdump:devel/binutils =20 USES=3D bison gmake python:2.7,build shebangfix tar:bz2 BINARY_ALIAS=3D bison=3D${LOCALBASE}/bin/bison = dtc=3D${LOCALBASE}/bin/dtc sed=3Dgsed swig=3Dswig3.0 I've not isolated where the builder environment's binutil tool(s) are put to use but this seems to solidly indicate that there is such use for sysutils/u-boot-pine64 . END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Aug 2 19:02:50 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B2B3104AB79 for ; Thu, 2 Aug 2018 19:02:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1386876898 for ; Thu, 2 Aug 2018 19:02:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id CC626104AB77; Thu, 2 Aug 2018 19:02:49 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A88C5104AB76 for ; Thu, 2 Aug 2018 19:02:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D43176893 for ; Thu, 2 Aug 2018 19:02:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id l14-v6so2948384iob.7 for ; Thu, 02 Aug 2018 12:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OZ46a77pJRd8VHzIAXZGngz++bUDZWNhBBEV4aIdL+E=; b=Y/xoptH3m7JVOUF1a/U10LdESuaX+wDoE1WKqwvXC7zjldM850RRL4rxmSwjDyPAfY 8nd0US+FgLW3l3ztz2Se0HR/z1VnV28aOUPigqKa3AG/G4G5jJ3QVGW2iIhCjlYDeqvT chfkb+nZtYmwiFgfkd/ur9cVlc7khhO+iZKUeuP3vFyI7P5brEn+ry95I9qwbGi3StwB rcfuTf+ZBT3VOKkQAyD2b/67iJMOIAVUhqcav4jlE2oJN34hzvdl9jXDyqm8yIAxdaQt cWxwaJKNvbMqAYwncIx5TZPJ3H5K/bwGZk3LtWlIk7oLzwMKqo8bj7BY0127OrYTjUek jRdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OZ46a77pJRd8VHzIAXZGngz++bUDZWNhBBEV4aIdL+E=; b=UC0YkKEw2vtCbOyQJsVW6hbIpIEpQnKH+kSz3BAdIPv9qt3WGzIZQOzhQPFj9GZlOp AfvDjIWJf165NDnt6vq+x0d8DVuiBRNLZlb0ulWQAAN0M86MFVuiuOAicROt+jRGJ4WM 5tcdsy8FqfvaIn3Htcho+VpF4tydOoNuuaufZmardbooaYcLddnbUr32yGPi1WAB1mhQ k2S5UR78NI40kQLaB16ewxk3jRgFM5ABq7ux7tNlbMex+v1eTYflRQdjIJojGtMHXiW8 gWesLs9pz+Ld71FCaNq+nPGBCtawoakUPyMYLAkc87FxQcCUM+KDHLZb3wJ3+p7/zxnX zSsw== X-Gm-Message-State: AOUpUlFvIX2uYnOLhslylKqQInLJYfQLZBfAxYULXY2GDLiqMrnKaZ9V zXfDe4UaG2BIvsGCv20VYc9M4Sa2VimzZL1VmlZxsA== X-Google-Smtp-Source: AA+uWPzCmAebUA1YEp6a+UD0DDLd98YiPKXNq1QsZbzw/8PbweMC+TfVxc/zmjcmS/I3D+ktew9Ze29H/lUBG7JgLFo= X-Received: by 2002:a6b:f719:: with SMTP id k25-v6mr3674419iog.37.1533236568508; Thu, 02 Aug 2018 12:02:48 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:4485:0:0:0:0:0 with HTTP; Thu, 2 Aug 2018 12:02:47 -0700 (PDT) X-Originating-IP: [86.153.210.77] In-Reply-To: <1533232890.1369.49.camel@freebsd.org> References: <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> <1533227944.1369.37.camel@freebsd.org> <1533232890.1369.49.camel@freebsd.org> From: Warner Losh Date: Thu, 2 Aug 2018 13:02:47 -0600 X-Google-Sender-Auth: 77W7UJub0IiAv1xrGy53JYrpkFA Message-ID: Subject: Re: booting current from nano-neo/allwinner now failes To: Ian Lepore Cc: Daniel Braniss , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 19:02:50 -0000 On Thu, Aug 2, 2018 at 12:01 PM, Ian Lepore wrote: > On Thu, 2018-08-02 at 18:55 +0100, Warner Losh wrote: > > On Thu, Aug 2, 2018, 5:39 PM Ian Lepore wrote: > > > > > > > > On Thu, 2018-08-02 at 19:31 +0300, Daniel Braniss wrote: > > > > > > > > > > > > > > > > > > > > > > > On 2 Aug 2018, at 19:26, Warner Losh wrote: > > > > > > > > > > Try the latest ubldr > > > > > There was a change in the last day that should fix this.. > > > > > > > > > I thought I had the latest, will try again. > > > > BTW, I only updated the u-boot, and now it=E2=80=99s trying to boot= via > > > > the > > > > net!, and the ether is actually working, > > > > i=E2=80=99ll compile a kernel with nfs root support =E2=80=A6 > > > > > > > > thanks, > > > > danny > > > > > > > Well, no, it's failing to boot via net, and if it's modern uboot, > > > it > > > will always fail. There is a "net device" in ubldr, but when it > > > tries > > > to probe, uboot fails to respond, because CONFIG_API no longer > > > supports > > > network devices in modern uboot that uses DM (Device Manager). > > > > > > The only way to netboot with modern uboot is via UEFI. > > > Unfortunately, > > > you don't get the kind of local control that ubldr provided; the > > > boot > > > parameters (where to find the root filesystem, etc) must come from > > > the > > > dhcp/bootp server. That's a bit of a showstopper for many folks who > > > don't have that level of control over the dhcp server config. > > > > > Is that a UEFI issue. Or our loader.efi needs X, Y or Z? > > > > Warner > > With ubldr you set a uboot env var (rootpath) and it gets used instead > of anything coming over the wire from the server (it's important that a > locally-set value overrides dhcp/bootp values, because the server you > can't control may deliver insane values). > > From what I've heard, the uboot uefi implementation doesn't give you a > way to save persistent efi vars, so right now there's no way to set a > local rootpath var. If we had persistent vars, I guess the thing to do > would be to define a standard freebsd-specific variable to set the > rootpath. > We currently parse command line options (which gives local users a way). If u-boot doesn't provide a good a way to do that, we can add reading local files to loader.efi . All the work I've done to make it more friendly to UEFI Boot Manager should also make it friendlier to these things. So long as we don't break UEFI boot manager stuff, I'm cool adding more local control. I also now have a bunch of boards that I'd like to have net-boot into the 'next thing' image so we can do CI-like testing at my "Todd Creek FreeBSD Test Labs" so we can do CI-like testing on the dozen or so boards I have. If I could do it via netboot, that would be best and allow me to ping-pong SD cards between netboot and test images from the project snapshots near releases. While I have 100% control over the DHCP env, it's dnsmasq which is a bit of a pain to setup relative to other systems I've used... Warner From owner-freebsd-arm@freebsd.org Thu Aug 2 19:25:34 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 034CC104CDE7 for ; Thu, 2 Aug 2018 19:25:34 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 89A0F77A9B for ; Thu, 2 Aug 2018 19:25:33 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4A986104CDE6; Thu, 2 Aug 2018 19:25:33 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28672104CDE5 for ; Thu, 2 Aug 2018 19:25:33 +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 86E1E77A99; Thu, 2 Aug 2018 19:25:32 +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 503f3bf3; Thu, 2 Aug 2018 21:25:31 +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=AzOBWO5K+NBkm4HSvWeK/Gv/kHY=; b=PD6cCLGxsYVjsseExE3yiRZO/Ibr udLtdSU8Hd6BdX1UfIVl7mSNYGPvljKF/NSF+giZqfRyNdm6ruowIu784p27sEaU Pn9lopw9iXwLQEh0bMjLEvHgNPHRVREwPxE/8VG3y/IL75oAfA2qqRpxFXc9C9Ek wwTNi44YiDYHuN4= 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=AzcD6mElI1G7ju1vKGbQxy8HO/48k2fzVA7x09vBV/cZQGzHNoiy5Tvx 6zqOqLgHaeYj++4mS2r3wfHZDQpYjxegBiM7rdz9W3yY3uLYmUBNoDkFXkPrnIGk 99kGzEH2MQsBuaKBpnGhpXWrHmWvSGd/ed3CclgThnzSkKEb3oc= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 715317b4 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 2 Aug 2018 21:25:30 +0200 (CEST) Date: Thu, 2 Aug 2018 21:25:30 +0200 From: Emmanuel Vadot To: Ian Lepore Cc: Warner Losh , "freebsd-arm@freebsd.org" Subject: Re: booting current from nano-neo/allwinner now failes Message-Id: <20180802212530.e1339aaddf64f316e38f9fe6@bidouilliste.com> In-Reply-To: <1533232890.1369.49.camel@freebsd.org> References: <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> <1533227944.1369.37.camel@freebsd.org> <1533232890.1369.49.camel@freebsd.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 19:25:34 -0000 On Thu, 02 Aug 2018 12:01:30 -0600 Ian Lepore wrote: > On Thu, 2018-08-02 at 18:55 +0100, Warner Losh wrote: > > On Thu, Aug 2, 2018, 5:39 PM Ian Lepore wrote: > >=20 > > >=20 > > > On Thu, 2018-08-02 at 19:31 +0300, Daniel Braniss wrote: > > > >=20 > > > >=20 > > > > >=20 > > > > >=20 > > > > > On 2 Aug 2018, at 19:26, Warner Losh wrote: > > > > >=20 > > > > > Try the latest ubldr > > > > > =A0There was a change in the last day that should fix this.. > > > > >=20 > > > > I thought I had the latest, will try again. > > > > BTW, I only updated the u-boot, and now it?s trying to boot via > > > > the > > > > net!, and the ether is actually working, > > > > i?ll compile a kernel with nfs root support ? > > > >=20 > > > > thanks, > > > > =A0=A0=A0=A0=A0=A0danny > > > >=20 > > > Well, no, it's failing to boot via net, and if it's modern uboot, > > > it > > > will always fail. There is a "net device" in ubldr, but when it > > > tries > > > to probe, uboot fails to respond, because CONFIG_API no longer > > > supports > > > network devices in modern uboot that uses DM (Device Manager). > > >=20 > > > The only way to netboot with modern uboot is via UEFI. > > > Unfortunately, > > > you don't get the kind of local control that ubldr provided; the > > > boot > > > parameters (where to find the root filesystem, etc) must come from > > > the > > > dhcp/bootp server. That's a bit of a showstopper for many folks who > > > don't have that level of control over the dhcp server config. > > >=20 > > Is that a UEFI issue. Or our loader.efi needs X, Y or Z? > >=20 > > Warner >=20 > With ubldr you set a uboot env var (rootpath) and it gets used instead > of anything coming over the wire from the server (it's important that a > locally-set value overrides dhcp/bootp values, because the server you > can't control may deliver insane values). >=20 > From what I've heard, the uboot uefi implementation doesn't give you a > way to save persistent efi vars, so right now there's no way to set a > local rootpath var. If we had persistent vars, I guess the thing to do > would be to define a standard freebsd-specific variable to set the > rootpath. There is no problem with u-boot and persistent var. Quoting u-boot note : * NOTE: with current implementation, no variables are available after * ExitBootServices, and all are persisted (if possible). The problem that I see with loader.efi and u-boot efi is that we use GetNextVariableName a lot and this isn't implemented in u-boot currently. And also something weird is happening : OK efi-show -g cfee69ad-a0de-47a9-93a8-f63106f8ae99 -v LoaderDev cfee69ad-a0de-47a9-93a8-f63106f8ae99 0x6 LoaderDev=3D\x2fVenHw\x28e61d73b9\x2da384\x2d4acc\x2daeab\x2d82e828f3628b\x= 29\x2fMAC\x2802816069b08d\x 2c0x1\x29\x00 OK efi-show -g cfee69ad-a0de-47a9-93a8-f63106f8ae99 -v LoaderDev OK=20 > -- Ian >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Aug 2 19:33:44 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9A5C104D637 for ; Thu, 2 Aug 2018 19:33:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3FED4785B3 for ; Thu, 2 Aug 2018 19:33:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 03BDB104D633; Thu, 2 Aug 2018 19:33:44 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD9CD104D62F for ; Thu, 2 Aug 2018 19:33:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 504FC785AE for ; Thu, 2 Aug 2018 19:33:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id l14-v6so3029797iob.7 for ; Thu, 02 Aug 2018 12:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7XSIcuxhz5G3gqQ43O5y6X3zPiHx9N7wCga8GTTCUIE=; b=pLihvylumFJXPQeV0hho/8ZMaQZgM1ZYWdn3AXAczKqeHFR5OwnQdzg44qdPrNeYeh Kl0wUtwJKlXM6OhA0M7t6IbdHOMhDaHMzOr0EF/yHh5qwqZd4newIXea7AiJ4YiePYKp sZcET155sAgKh+bPHbaZlFFjN3IbIddDzNCTCHvmbPS62SB4ttN74W2BTo6DqV3UBJ5n GRgdyqDRb2zeQGVwC2c/1JtbyNRNitVlRTedn18MYB2kWIifpypjirXJpkV6dR2ChBtL bsz25Cl8yo8chdogdkGdmKgJxB1SS4vV6CxHR5LtnSVHgtO5snR8MCecz1+oiCi1HRzW Z1ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7XSIcuxhz5G3gqQ43O5y6X3zPiHx9N7wCga8GTTCUIE=; b=IGYaXOrn03tPywhjp7acpKf7kFxkF7PY2bp3MhMTp7t2JylDQgf2K/T+gMaK18NqC3 TXB69Hv3qQPrfRBLCZpF/2k0mpORYuYw69OLmCtzEoH/fGAn4F87h/BFf2AKk9Ct1Z78 7XbbyIrcoI8bowu2FjYTrrUUrBZYFtivcpQZC9M9TimFgF97MzDEI8eq3Alc0mUnVB/m Fwl6aLoaYunRHe/5+DIFzJWx5ZR29oKWSQSulk8lXI251zkb9u6ZbOH2pHedxree8jqA JcJz6+pm2+AcWimsQH/ui1riF79mmpUpipxTvSu8ccDuoDHbxLRV3cvUUGUHeBHL6diV ddwg== X-Gm-Message-State: AOUpUlEgJBZ5vgwscgYarMoMJvrMVnJJB5UsFRmE9oUKPMsMbHOzdzaO cTJfiY8a1ZKBeDUr/t+GXuKISOo4hPd3kOxLpIK3nozKTS3FnA== X-Google-Smtp-Source: AA+uWPwfR7K5wvmRURhq+QHT/6SdY2WAOyFmepoG650SKj109zAzuMQq6SB3Jilk6DgSsMnpU0sev1lY1rcSfncbviE= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr3553290ioa.299.1533238422572; Thu, 02 Aug 2018 12:33:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:4485:0:0:0:0:0 with HTTP; Thu, 2 Aug 2018 12:33:41 -0700 (PDT) X-Originating-IP: [86.153.210.77] In-Reply-To: <20180802212530.e1339aaddf64f316e38f9fe6@bidouilliste.com> References: <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> <1533227944.1369.37.camel@freebsd.org> <1533232890.1369.49.camel@freebsd.org> <20180802212530.e1339aaddf64f316e38f9fe6@bidouilliste.com> From: Warner Losh Date: Thu, 2 Aug 2018 13:33:41 -0600 X-Google-Sender-Auth: j0yXykJps0USYR7afA8qhn3bM50 Message-ID: Subject: Re: booting current from nano-neo/allwinner now failes To: Emmanuel Vadot Cc: Ian Lepore , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 19:33:45 -0000 On Thu, Aug 2, 2018 at 1:25 PM, Emmanuel Vadot wrote: > On Thu, 02 Aug 2018 12:01:30 -0600 > Ian Lepore wrote: > > > On Thu, 2018-08-02 at 18:55 +0100, Warner Losh wrote: > > > On Thu, Aug 2, 2018, 5:39 PM Ian Lepore wrote: > > > > > > > > > > > On Thu, 2018-08-02 at 19:31 +0300, Daniel Braniss wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2 Aug 2018, at 19:26, Warner Losh wrote: > > > > > > > > > > > > Try the latest ubldr > > > > > > There was a change in the last day that should fix this.. > > > > > > > > > > > I thought I had the latest, will try again. > > > > > BTW, I only updated the u-boot, and now it?s trying to boot via > > > > > the > > > > > net!, and the ether is actually working, > > > > > i?ll compile a kernel with nfs root support ? > > > > > > > > > > thanks, > > > > > danny > > > > > > > > > Well, no, it's failing to boot via net, and if it's modern uboot, > > > > it > > > > will always fail. There is a "net device" in ubldr, but when it > > > > tries > > > > to probe, uboot fails to respond, because CONFIG_API no longer > > > > supports > > > > network devices in modern uboot that uses DM (Device Manager). > > > > > > > > The only way to netboot with modern uboot is via UEFI. > > > > Unfortunately, > > > > you don't get the kind of local control that ubldr provided; the > > > > boot > > > > parameters (where to find the root filesystem, etc) must come from > > > > the > > > > dhcp/bootp server. That's a bit of a showstopper for many folks who > > > > don't have that level of control over the dhcp server config. > > > > > > > Is that a UEFI issue. Or our loader.efi needs X, Y or Z? > > > > > > Warner > > > > With ubldr you set a uboot env var (rootpath) and it gets used instead > > of anything coming over the wire from the server (it's important that a > > locally-set value overrides dhcp/bootp values, because the server you > > can't control may deliver insane values). > > > > From what I've heard, the uboot uefi implementation doesn't give you a > > way to save persistent efi vars, so right now there's no way to set a > > local rootpath var. If we had persistent vars, I guess the thing to do > > would be to define a standard freebsd-specific variable to set the > > rootpath. > > There is no problem with u-boot and persistent var. > Quoting u-boot note : > * NOTE: with current implementation, no variables are available after > * ExitBootServices, and all are persisted (if possible). > > The problem that I see with loader.efi and u-boot efi is that we use > GetNextVariableName a lot and this isn't implemented in u-boot > currently. > And also something weird is happening : > > OK efi-show -g cfee69ad-a0de-47a9-93a8-f63106f8ae99 -v LoaderDev > cfee69ad-a0de-47a9-93a8-f63106f8ae99 0x6 > LoaderDev=\x2fVenHw\x28e61d73b9\x2da384\x2d4acc\ > x2daeab\x2d82e828f3628b\x29\x2fMAC\x2802816069b08d\x > 2c0x1\x29\x00 > OK efi-show -g cfee69ad-a0de-47a9-93a8-f63106f8ae99 -v > LoaderDev > OK > I'll take a look at this. I know even in normal UEFI land there's issues with efi-show. Warner From owner-freebsd-arm@freebsd.org Fri Aug 3 00:34:32 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDE7D1056B10 for ; Fri, 3 Aug 2018 00:34:32 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (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 7F018874FD; Fri, 3 Aug 2018 00:34:32 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w730YUNx034271; Fri, 3 Aug 2018 01:34:30 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w730YURL034270; Fri, 3 Aug 2018 01:34:30 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> Date: Fri, 03 Aug 2018 01:34:29 +0100 Organization: Dyslexic Fish To: marklmi@yahoo.com, markj@freebsd.org, fbsd@www.zefox.net Cc: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> In-Reply-To: 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 (donotpassgo.dyslexicfish.net [104.207.135.49]); Fri, 03 Aug 2018 01:34:31 +0100 (BST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 00:34:33 -0000 I've now added the log for vm stats for the failure with the usb 3.0 32 gb drive as swap. (3 partitions of 1GB) : 15 minute output of swapinfo, gstat -abd -I 10s, sysctl vm, and syslog up to the fail at: http://catflap.org/jamie/rpi3/ cheers, jamie From owner-freebsd-arm@freebsd.org Fri Aug 3 01:09:24 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C0221057483 for ; Fri, 3 Aug 2018 01:09:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7593D88B59 for ; Fri, 3 Aug 2018 01:09:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w7319WDZ004421 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Aug 2018 18:09:33 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7319WoH004420; Thu, 2 Aug 2018 18:09:32 -0700 (PDT) (envelope-from fbsd) Date: Thu, 2 Aug 2018 18:09:32 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments (insufficient swap) Message-ID: <20180803010932.GA4321@www.zefox.net> References: <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180802015135.GC99523@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 01:09:24 -0000 Just for fun, and to provide an alternate view of OOMA behavior on an RPI3, a j4 buildworld was again run with deliberately insufficient swap. A single 1 GB partition was used, on the microSD card. Having sufficient swap on microSD allows a successful -j4 buildworld. The debris I could collect is on display at http://www.zefox.net/~fbsd/rpi3/swaptests/r336877M/1gbsdflash/ The behavior suggests that OOMA misbehaves in both possible directions: It kills processes when it shouldn't, and does _not_ kill them when it should. The same behavior was observed some weeks ago, but this time it's possible to watch the gstat output. Please note that the messages Aug 1 18:08:13 www kernel: v_free_count: 5439, v_inactive_count: 1 Aug 1 18:08:25 www kernel: pid 93301 (c++), uid 0, was killed: out of swap space are stale, left over from an earlier run with swap on USB flash. There are a couple of core files included in the exhibit. At least the top session crashed with a signal 11, it happened when I was watching and I restarted top, which then ran normally until I left the console. That's a somewhat unusual occurrence, signal 11's haven't been seen on this box any time recently. I did not see what happened to tcsh, but it left one core file. In the end the console carried a stream of what look like hardware errors referencing da0, but all was forgiven after reboot and a couple cycles of fsck -fy. An excerpt is in the readme file. One curiosity is that the system remained responsive to ping. The console wasn't responsive, ssh sessions either disconnected or froze. Power-cycling was the only way to reboot. Thanks for reading, I hope the observations are of some use. bob prohaska From owner-freebsd-arm@freebsd.org Fri Aug 3 05:16:16 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 612A0105D822 for ; Fri, 3 Aug 2018 05:16:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 DD4E270BD7 for ; Fri, 3 Aug 2018 05:16:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 9E4EA105D821; Fri, 3 Aug 2018 05:16:15 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62135105D820 for ; Fri, 3 Aug 2018 05:16:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 DD3F770BD6 for ; Fri, 3 Aug 2018 05:16:14 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1flSRa-0000zw-Ob; Fri, 03 Aug 2018 08:16:06 +0300 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: booting current from nano-neo/allwinner now failes Date: Fri, 3 Aug 2018 08:16:06 +0300 In-Reply-To: <20180802204537.26af888414c4561b624fafd3@bidouilliste.com> Cc: "freebsd-arm@freebsd.org" To: Emmanuel Vadot References: <20180802204537.26af888414c4561b624fafd3@bidouilliste.com> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 05:16:16 -0000 > On 2 Aug 2018, at 21:45, Emmanuel Vadot wrote ... > Did you also update ubldr.bin ? (not just ubldr) I did, and it went straight to net boot, and failed. ... >=20 > Also please consider switching to efi boot, just deleting boot.scr and > copying loader.efi as EFI/BOOT/bootarm.efi is enough. no problem, i=E2=80=99ll try ASAP. Q: this to the FAT partition? my fat did not have the boot.scr, adding it did not change things BTW, iboot.scr has some binary stuff, is that ok? thanks, danny >=20 >> in any case I would like to help but things are getting too = complicated :-) >>=20 >>=20 >> thanks, >> danny >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " >=20 >=20 > --=20 > Emmanuel Vadot > = > From owner-freebsd-arm@freebsd.org Fri Aug 3 05:44:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3EF7105E212 for ; Fri, 3 Aug 2018 05:44:04 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 80EC7718BD for ; Fri, 3 Aug 2018 05:44:04 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 45B4C105E211; Fri, 3 Aug 2018 05:44:04 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 346E1105E210 for ; Fri, 3 Aug 2018 05:44:04 +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 96F11718BC for ; Fri, 3 Aug 2018 05:44:03 +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 96e23c21; Fri, 3 Aug 2018 07:43:55 +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=77nahjpDXJeQtSud9Pqu/8AlQeY=; b=e8X53A6uO8cBZcyoFLDodrPuK5UT cXrCt8VUr4vpqtvnwNb5rOxL3rdSkzzRaa969aJtoVEPjZ+VRuL4pHYyl/IkvQ9B S7WoFICa3x5CDo/9+vm8gJBc+0qUQzQVsjaeF6tzyHq/ZQV4xmsC/Cuy7Fi4W8k3 31SGCwH5c1GhOHA= 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=JgkAoapgJ+EV7OBzGe7btJ6ZHNqKoQmgB3+k2ybuiIOecK39IOHeheQF GpcB1iwK1ydh3VjcGMB/rQ3WdRxruRoxMIhyUJ6N80FHXtght45sev3eLYNhIwj1 nXGlxmZp08PNgMYhGvCv+MEIvtPP3Byyq13JzilNEOrVYU4o7Yg= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 5ba78fe6 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 3 Aug 2018 07:43:55 +0200 (CEST) Date: Fri, 3 Aug 2018 07:43:55 +0200 From: Emmanuel Vadot To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" Subject: Re: booting current from nano-neo/allwinner now failes Message-Id: <20180803074355.cc6feef658039a899aff1841@bidouilliste.com> In-Reply-To: References: <20180802204537.26af888414c4561b624fafd3@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 05:44:05 -0000 On Fri, 3 Aug 2018 08:16:06 +0300 Daniel Braniss wrote: >=20 >=20 > > On 2 Aug 2018, at 21:45, Emmanuel Vadot wrote > ... > > Did you also update ubldr.bin ? (not just ubldr) > I did, and it went straight to net boot, and failed. >=20 > ... > >=20 > > Also please consider switching to efi boot, just deleting boot.scr and > > copying loader.efi as EFI/BOOT/bootarm.efi is enough. >=20 > no problem, i?ll try ASAP. > Q: this to the FAT partition? >=20 > my fat did not have the boot.scr, adding it did not change things Based on your first mail you did have it > BTW, iboot.scr has some binary stuff, is that ok? yes it's supposed to be a binary file. >=20 > thanks, > danny >=20 > >=20 > >> in any case I would like to help but things are getting too complicat= ed :-) > >>=20 > >>=20 > >> thanks, > >> danny > >>=20 > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " > >=20 > >=20 > > --=20 > > Emmanuel Vadot > <= manu@freebsd.org > >=20 --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Aug 3 06:08:16 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3184E105E88F for ; Fri, 3 Aug 2018 06:08:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 BCAE57214E for ; Fri, 3 Aug 2018 06:08:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 80D9A105E88E; Fri, 3 Aug 2018 06:08:15 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E318105E88D for ; Fri, 3 Aug 2018 06:08:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 BF4C57214D for ; Fri, 3 Aug 2018 06:08:14 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1flTFx-0002h1-CA; Fri, 03 Aug 2018 09:08:09 +0300 From: Daniel Braniss Message-Id: <0842173A-A76E-48D7-9B46-3419F5CAB70C@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: booting current from nano-neo/allwinner now failes Date: Fri, 3 Aug 2018 09:08:09 +0300 In-Reply-To: <20180803074355.cc6feef658039a899aff1841@bidouilliste.com> Cc: "freebsd-arm@freebsd.org" To: Emmanuel Vadot References: <20180802204537.26af888414c4561b624fafd3@bidouilliste.com> <20180803074355.cc6feef658039a899aff1841@bidouilliste.com> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 06:08:16 -0000 > On 3 Aug 2018, at 08:43, Emmanuel Vadot wrote: >=20 > On Fri, 3 Aug 2018 08:16:06 +0300 > Daniel Braniss > = wrote: >=20 >>=20 >>=20 >>> On 2 Aug 2018, at 21:45, Emmanuel Vadot = wrote >> ... >>> Did you also update ubldr.bin ? (not just ubldr) >> I did, and it went straight to net boot, and failed. >>=20 >> ... >>>=20 >>> Also please consider switching to efi boot, just deleting boot.scr = and >>> copying loader.efi as EFI/BOOT/bootarm.efi is enough. >>=20 >> no problem, i?ll try ASAP. >> Q: this to the FAT partition? >>=20 >> my fat did not have the boot.scr, adding it did not change things >=20 > Based on your first mail you did have it I was trying to answer too many questions with a one liner :-) I first tried booting an old sd image with latest current but old = u-boot, old FAT stuff, and got stuck. I then upgraded the u-boot, got different results=20 then upgraded ubldr[.bin] different results but no success, adding the boot.scr didn=E2=80=99t = seem to make a=20 difference. In any case I will try efi boot ASAP with latest ubldr. >=20 >> BTW, iboot.scr has some binary stuff, is that ok? >=20 > yes it's supposed to be a binary file. >=20 >>=20 >> thanks, >> danny >>=20 >>>=20 >>>> in any case I would like to help but things are getting too = complicated :-) >>>>=20 >>>>=20 >>>> thanks, >>>> danny >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> freebsd-arm@freebsd.org mailing = list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = >>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org = " >>>=20 >>>=20 >>> --=20 >>> Emmanuel Vadot > > >>=20 >=20 >=20 > --=20 > Emmanuel Vadot > = > From owner-freebsd-arm@freebsd.org Fri Aug 3 07:02:26 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F0AF105F9EC for ; Fri, 3 Aug 2018 07:02:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-30.consmr.mail.ne1.yahoo.com (sonic301-30.consmr.mail.ne1.yahoo.com [66.163.184.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAF2A73C6A for ; Fri, 3 Aug 2018 07:02:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: nW4k5C4VM1mEbrpyiFIx_7SNLFPa_mfjJJ_4vKUS2eHS8TEJZFP2zETiohv7mXd FfcdzkXI7M4ZTpZD1Irorh4DVSpeDwCjU3aVVqGx0B3PMc.9MWlh97HqHINDftkR8sy3aYI71JdN C9ljT.yf5hcXMYZasZq1ML6wpACMbe4OStJ2FjqUWeSQi2UWE6PQrQQC_KSnGIShA8g6icmGLmPk OJveTl2cJaTLKL5pJaz3qYsKn.VJVaCquvRAuebOtVhs5gEE0ekJlQ0wRBMZ9ftZ8S_HAcZUyU3S bnyF.oVaRgXrU21AYnwcNIH6dF2594hf0s2olB0uvkj9tyy9WZU56YbdO8JQE4GMGk_fkuLP.ONS TTbyK16j9NtP2_F2..U.av31D2Xy1GhqnDOuQrzYonbXP0Ha.tMujDelHWKt_JPA78LJWSFNV9gk j7sRFgqGeDIo5U9dDxesda_ba4oLZgfDEXbEaqTlHD7WbBaT.Lh1fqRCw07xGWYdC57uTfiW7RoI IOiS2.OEwEKg8R2g186zU5qIYPrsQntt7vwp4Vxi_1U3mhj1e1KJQOhFT0sDmkPQ9BGGtja6AxgE NIyb5PP5ClkF.r1oS0D4dF8Ux03CR_nLA5xklMZ16fuYZviVZZsahHdyvDsh2v_vJtwQ72JNJaLP v5ZVFsA4u5ADJQK1TnQA0q7TtNYAO.z2JTPWh1Oc58KIS3y8.bR_0WupKxWPrKIlSxktLZWaCdJj ApN3NM5_KM67ESX8fyORHkTgq0kngQ4WZ70xXROSOmccks3ttTEnnh.Um_fNit0nb46wlVYTVnA2 KjNrZtgFPESehP0oXyp1lSlVEV2FSi2mkOT56VrwLwkBQ0dTR8VzDn_bue8x6EwtGKg8D6r57UvF LYNz_W9TgUiLCT6eaZwj4qj75578GLrqnIrauDSpggXPdD0hFitzmQa4P8cnfXvkrwKRT77w79XZ ZIOsW8Wl1d6XHuokNjqpjMCNZ9FSsGkQVZsJhzKVhFiFaRdP8XoLnSdTAR1k_mUywcWOJX5s8gUk pFI1FPON3G9kB Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Fri, 3 Aug 2018 07:02:18 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp427.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ca61e8ff55bceaa14ef998d11f6a35db; Fri, 03 Aug 2018 07:02:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> Date: Fri, 3 Aug 2018 00:02:13 -0700 Cc: markj@freebsd.org, bob prohaska , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> To: Jamie Landeg-Jones X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 07:02:26 -0000 On 2018-Aug-2, at 5:34 PM, Jamie Landeg-Jones = wrote: > I've now added the log for vm stats for the failure with the usb 3.0 = 32 gb drive as swap. (3 partitions of 1GB) : >=20 > 15 minute output of swapinfo, gstat -abd -I 10s, sysctl vm, and syslog = up to the fail at: >=20 > http://catflap.org/jamie/rpi3/ Your examples seem to have the structure of not having much Inactive memory but having lots of swap space and then ending up trying to page out the Inactive memory until only 1 page is left --and then killing a process despite lots of swap space being available. Mem: 564M Active, 2M Inact, 68M Laundry, 162M Wired, 97M Buf, 104M Free Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 4194304 78204 4116100 2% then: syslog: Aug 2 10:39:57 tiffany kernel: v_free_count: 3221, = v_inactive_count: 1 syslog: Aug 2 10:39:59 tiffany kernel: pid 30593 (c++), uid 0, was = killed: out of swap space and . . . Mem: 435M Active, 18M Inact, 81M Laundry, 167M Wired, 97M Buf, 198M Free Device 1K-blocks Used Avail Capacity . . . Total 3145728 182216 2963512 6% then: syslog: Aug 3 01:04:39 tiffany kernel: v_free_count: 2777, = v_inactive_count: 1 syslog: Aug 3 01:04:42 tiffany kernel: pid 31130 (c++), uid 0, was = killed: out of swap space syslog: Aug 3 01:04:42 tiffany kernel: v_free_count: 2775, = v_inactive_count: 1 syslog: Aug 3 01:04:42 tiffany kernel: pid 31225 (c++), uid 0, was = killed: out of swap space If Inact+Laundry+Buf(?)+Free was not enough to provide sufficient additional RAM, I'd would have guessed that some Active Real Memory should then have been paged/swapped out and so RAM would be made available. (This requires the system to have left itself sufficient room in RAM for that guessed activity.) But I'm no expert at the intent or actual operation. Bob P.'s reports (for having sufficient swap space) also indicate the likes of: v_free_count: 5439, v_inactive_count: 1 So all the examples have: "v_inactive_count: 1". (So: vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt=3D=3D1 ) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Aug 3 08:32:35 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8EDD1061DC7 for ; Fri, 3 Aug 2018 08:32:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 3619C76B49 for ; Fri, 3 Aug 2018 08:32:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id ED28F1061DC6; Fri, 3 Aug 2018 08:32:34 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB6341061DC5 for ; Fri, 3 Aug 2018 08:32:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 52EB176B35 for ; Fri, 3 Aug 2018 08:32:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1flVVZ-0008IS-3m; Fri, 03 Aug 2018 11:32:25 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: booting current from nano-neo/allwinner now failes From: Daniel Braniss In-Reply-To: <0842173A-A76E-48D7-9B46-3419F5CAB70C@cs.huji.ac.il> Date: Fri, 3 Aug 2018 11:32:24 +0300 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180802204537.26af888414c4561b624fafd3@bidouilliste.com> <20180803074355.cc6feef658039a899aff1841@bidouilliste.com> <0842173A-A76E-48D7-9B46-3419F5CAB70C@cs.huji.ac.il> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 08:32:36 -0000 some time later - actually several hours - I made a new image and - using latest ubldr and with boot.scr I think my problem is the sd image, it doesn=E2=80=99t like my MBR = because as=20 opposed to you I get: =E2=80=A6 Probing all disk devices=E2=80=A6 Checking unit=3D0 slice=3D partition=3D=E2=80=A6 as opposed tour case where after the =E2=80=A6 you get good. - so switching to EFI it get stuck: U-Boot SPL 2018.07 (Aug 01 2018 - 17:37:02 +0300) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2018.07 (Aug 01 2018 - 17:37:02 +0300) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO DRAM: 512 MiB MMC: SUNXI SD/MMC: 0 Loading Environment from FAT... *** Warning - bad CRC, using default = environment Failed (-5) In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0=20 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootarm.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disks on usb... Disk usb0 not ready Disk usb1 not ready Disk usb2 not ready Disk usb3 not ready Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 3 disks 493860 bytes read in 25 ms (18.8 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 42000000 ... Consoles: EFI console =20 FreeBSD/arm EFI loader, Revision 1.1 (Fri Aug 3 10:00:59 IDT 2018 danny@pe-44) Command line arguments: l EFI version: 2.70 EFI Firmware: Das U-Boot (rev 0.00) Console: efi (0) Load Path: /\efi\boot\bootarm.efi Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0xc0= f,0x1ffe0) Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0xc0= f,0x1ffe0) Setting currdev to disk0p1: Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x20= c2e,0x3df3c2) Setting currdev to disk0p2: ubenv not found Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x6cf66c data=3D0x68938+0x4f048 = syms=3D[0x4+0x807e0+0x4+0xd2a75] efi-autoresizecons: Neither Graphics Output Protocol nor Universal = Graphics Adapter present Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x47ffb000. EHCI failed to shut down host controller. Kernel entry at 0x53000180... Kernel args: (null) modulep: 0xc08e1000 relocation_offset 0 I will now try to build a new MBR/image =E2=80=A6 cheers, danny > On 3 Aug 2018, at 09:08, Daniel Braniss wrote: >=20 >=20 >=20 >> On 3 Aug 2018, at 08:43, Emmanuel Vadot = wrote: >>=20 >> On Fri, 3 Aug 2018 08:16:06 +0300 >> Daniel Braniss > = wrote: >>=20 >>>=20 >>>=20 >>>> On 2 Aug 2018, at 21:45, Emmanuel Vadot = wrote >>> ... >>>> Did you also update ubldr.bin ? (not just ubldr) >>> I did, and it went straight to net boot, and failed. >>>=20 >>> ... >>>>=20 >>>> Also please consider switching to efi boot, just deleting boot.scr = and >>>> copying loader.efi as EFI/BOOT/bootarm.efi is enough. >>>=20 >>> no problem, i?ll try ASAP. >>> Q: this to the FAT partition? >>>=20 >>> my fat did not have the boot.scr, adding it did not change things >>=20 >> Based on your first mail you did have it >=20 > I was trying to answer too many questions with a one liner :-) > I first tried booting an old sd image with latest current but old = u-boot, old FAT stuff, and got stuck. > I then upgraded the u-boot, got different results=20 > then upgraded ubldr[.bin] > different results but no success, adding the boot.scr didn=E2=80=99t = seem to make a=20 > difference. > In any case I will try efi boot ASAP with latest ubldr. >=20 >=20 >>=20 >>> BTW, iboot.scr has some binary stuff, is that ok? >>=20 >> yes it's supposed to be a binary file. >>=20 >>>=20 >>> thanks, >>> danny >>>=20 >>>>=20 >>>>> in any case I would like to help but things are getting too = complicated :-) >>>>>=20 >>>>>=20 >>>>> thanks, >>>>> danny >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing = list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = >>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org = " >>>>=20 >>>>=20 >>>> --=20 >>>> Emmanuel Vadot > > >>>=20 >>=20 >>=20 >> --=20 >> Emmanuel Vadot > = > >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Aug 3 08:45:41 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0A09106250A for ; Fri, 3 Aug 2018 08:45:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 462567739E for ; Fri, 3 Aug 2018 08:45:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 07CD71062509; Fri, 3 Aug 2018 08:45:41 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1AA01062508 for ; Fri, 3 Aug 2018 08:45:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 5472E7739B; Fri, 3 Aug 2018 08:45:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1flViI-0008fM-Ud; Fri, 03 Aug 2018 11:45:34 +0300 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: efi netboot was Re: booting current from nano-neo/allwinner now failes Date: Fri, 3 Aug 2018 11:45:34 +0300 In-Reply-To: <1533232890.1369.49.camel@freebsd.org> Cc: Warner Losh , "freebsd-arm@freebsd.org" To: Ian Lepore References: <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> <1533227944.1369.37.camel@freebsd.org> <1533232890.1369.49.camel@freebsd.org> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 08:45:42 -0000 [=E2=80=A6] >=20 > With ubldr you set a uboot env var (rootpath) and it gets used instead > of anything coming over the wire from the server (it's important that = a > locally-set value overrides dhcp/bootp values, because the server you > can't control may deliver insane values). >=20 >> =46rom what I've heard, the uboot uefi implementation doesn't give = you a > way to save persistent efi vars, so right now there's no way to set a > local rootpath var. If we had persistent vars, I guess the thing to do > would be to define a standard freebsd-specific variable to set the > rootpath. >=20 > -- Ian so now that I=E2=80=99m trying out efiboot, typing bootp seems to do = something, it=E2=80=99s requesting and ip-based.img, is there some iPXE/pxeboot = that I can use instead? and yes, me too has control over the dns/dhcp - sorry Ian :-) danny From owner-freebsd-arm@freebsd.org Fri Aug 3 08:49:59 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51F0B10627AF for ; Fri, 3 Aug 2018 08:49:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D674977750 for ; Fri, 3 Aug 2018 08:49:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id y10-v6so4359008ioa.10 for ; Fri, 03 Aug 2018 01:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BmiM6iVCI4C6R3+rZyFP6h1fZimocCnN0S00mBCZB3Q=; b=YgfYE1q1Hcuwr5wvPY83EKB0PQYvI8zcz5fV2j0NiNPnKno6tBmanln4hRXwQ4FLNF 849I0QCB68blHJswljn2abvEWgKXXDmiJkYA/3PxeVkfDzQvjgK/RUXreqwMmyJGAZO4 NDRZ5MBjH52zFw8jW+E/JwGb0pQJDYqO6StY9u6ZthmSkg42bTQ2DJJ5Qju9KrX/sYcl WV0DvYb+eYeCtPWH1uNtSioEDIzBy1gFtxEu48QL8ugiIXbEppnfGmcEo0i4wccAXmD0 uYdm+Wh0guZzP4ULeT79xZXCH9ESy059cUe/p6CP4kZBGp0GYjQvHARqcckNU7kiDdaB sSEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BmiM6iVCI4C6R3+rZyFP6h1fZimocCnN0S00mBCZB3Q=; b=Mshy0cVkXVym30jKH+uRzp2DcJO3Iy9Vx8kM7uqhHShIiinZj1isHj1msfkbDyE6sA h3J616RgEtdAgcwvMJ0QB+aM26CNgMS7PmaZ3OltoYJ2NCuPQEPWd9vj0vnMdjSrRs/y mX89kmQ7uvubeIj54bLo5fi9F6WgJkgvN3M5JDIM89kU+VU2nYXGZ57Fs1s4kuIAJc91 QpV11nc1GnRjiXw6YdA7xQ91BI7OQAuYBwe2EVhRv2ZpAQXw5ZVvnVWETll0eROdvW0p 4FPtw3iHNUDdgI/0HjVXiGPTPbYE+FGFrE7JeZTufvGDFwVSMRkfiRWOFyuU3iWa8ucT zbxA== X-Gm-Message-State: AOUpUlHJiDtjdCF0Nr3rDuY0727NV2jw3aZnN92YmDLS0iY9iaZcAlF9 VfCpj85/Plmb97VoYOA/mCE1PwVAhx37KuU6dz9p/kvo5NfYpQ== X-Google-Smtp-Source: AA+uWPwy9pLyaBo1rV0toh3JMx3O1DrsoGOaMCEXE4Eal0ab4a8qHJAkuPQi8MDRSu9c3FjhJzL77WMnaLr9f6YxBwM= X-Received: by 2002:a6b:f719:: with SMTP id k25-v6mr5389515iog.37.1533286198103; Fri, 03 Aug 2018 01:49:58 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:4485:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 01:49:57 -0700 (PDT) X-Originating-IP: [86.153.210.77] In-Reply-To: <20180803010932.GA4321@www.zefox.net> References: <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180803010932.GA4321@www.zefox.net> From: Warner Losh Date: Fri, 3 Aug 2018 02:49:57 -0600 X-Google-Sender-Auth: DatMSERSXoneWbAVcgdZhJtYAyY Message-ID: Subject: Re: RPI3 swap experiments (insufficient swap) To: bob prohaska Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 08:49:59 -0000 On Thu, Aug 2, 2018 at 7:09 PM, bob prohaska wrote: > In the end the console carried a stream of what look like hardware errors > referencing > da0, but all was forgiven after reboot and a couple cycles of fsck -fy. An > excerpt > is in the readme file. > Unless the OOM is somehow killing a kernel thread, these errors are the root cause of all the crazy. Something happens along the way and we find that our error recovery to that something is bad and we never complete more I/O to the device (if I read the earlier thread right). No good can come from this. The OOM is then doing weird things, but when the device goes away we're pretty bad at coping right now. The question, though, is how can we improve the USB / umass parts of the stack to do enough error recovery so we can survive whatever glitch that's causing it to stop talking to the device (and/or avoid that glitch in the first place). The disk/ssd isn't really bad, but we have some bug either in the USB host adapter, the USB stack, or in the umass SIM (or some combination). Warner From owner-freebsd-arm@freebsd.org Fri Aug 3 15:27:01 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79C7D106CB0C for ; Fri, 3 Aug 2018 15:27:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 199D2886B6 for ; Fri, 3 Aug 2018 15:27:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 60B64E11B for ; Fri, 3 Aug 2018 15:27:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w73FR0Jr066654 for ; Fri, 3 Aug 2018 15:27:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w73FR0Ma066649 for freebsd-arm@FreeBSD.org; Fri, 3 Aug 2018 15:27:00 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 230331] BEAGLEBONE-20180802-r337160 fails to boot on BBG Date: Fri, 03 Aug 2018 15:27:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 15:27:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230331 Bug ID: 230331 Summary: BEAGLEBONE-20180802-r337160 fails to boot on BBG Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: emaste@freebsd.org BBG: https://beagleboard.org/green Image: FreeBSD-12.0-CURRENT-arm-armv7-BEAGLEBONE-20180802-r337160.img.xz Boot fails ending with "WARNING! Trying to fire up the kernel, but no device tree blob found!" Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 5 disks WARNING: booting without device tree 493828 bytes read in 33 ms (14.3 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC WARNING: booting without device tree ## Starting EFI application at 82000000 ... Consoles: EFI console=20=20 FreeBSD/arm EFI loader, Revision 1.1 (Thu Aug 2 22:26:48 UTC 2018 root@releng3.nyi.freebsd.org) Command line arguments: l EFI version: 2.70 EFI Firmware: Das U-Boot (rev 0.00) Console: efi (0) Load Path: /\efi\boot\bootarm.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x42f= ,0x18fa8) Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x42f= ,0x18fa8) Setting currdev to disk0p1: Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x193= d7,0x5e6c11) Setting currdev to disk0p2: Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x87f1dc data=3D0x910b8+0x1ded48 syms=3D[0x4+0xa9a00+0x4+0x10e4b1] /boot/kernel/umodem.ko text=3D0x1bf4 text=3D0x1320 data=3D0x1080+0xf88 syms=3D[0x4+0x1070+0x4+0xbcd] loading required module 'ucom' /boot/kernel/ucom.ko text=3D0x1f8c text=3D0x2e90 data=3D0x1080+0x17bc syms=3D[0x4+0x14f0+0x4+0xc5d] efi-autoresizecons: Neither Graphics Output Protocol nor Universal Graphics Adapter present Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]...=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! Kernel entry at 0x95000180... Kernel args: (null) modulep: 0xc0cbb000 relocation_offset 0 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Aug 3 15:42:02 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F30ED106D231 for ; Fri, 3 Aug 2018 15:42:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 93BEE89006 for ; Fri, 3 Aug 2018 15:42:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 58710106D230; Fri, 3 Aug 2018 15:42:01 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 366EF106D22F for ; Fri, 3 Aug 2018 15:42:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 BDF0F89004 for ; Fri, 3 Aug 2018 15:42:00 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1flcD6-000NY1-HS; Fri, 03 Aug 2018 18:41:48 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: booting current from nano-neo/allwinner now failes From: Daniel Braniss In-Reply-To: Date: Fri, 3 Aug 2018 18:41:48 +0300 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <511F3AD9-8897-4223-ACD3-59807E7109B4@cs.huji.ac.il> References: <20180802204537.26af888414c4561b624fafd3@bidouilliste.com> <20180803074355.cc6feef658039a899aff1841@bidouilliste.com> <0842173A-A76E-48D7-9B46-3419F5CAB70C@cs.huji.ac.il> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 15:42:02 -0000 > On 3 Aug 2018, at 11:32, Daniel Braniss wrote: >=20 > some time later - actually several hours - I made a new image and >=20 > - using latest ubldr and with boot.scr > I think my problem is the sd image, it doesn=E2=80=99t like my MBR = because as=20 > opposed to you I get: > =E2=80=A6 > Probing all disk devices=E2=80=A6 > Checking unit=3D0 slice=3D partition=3D=E2=80=A6 >=20 > as opposed tour case where after the =E2=80=A6 you get good. >=20 > - so switching to EFI it get stuck: >=20 > U-Boot SPL 2018.07 (Aug 01 2018 - 17:37:02 +0300) > DRAM: 512 MiB > Trying to boot from MMC1 >=20 >=20 > U-Boot 2018.07 (Aug 01 2018 - 17:37:02 +0300) Allwinner Technology >=20 > CPU: Allwinner H3 (SUN8I 1680) > Model: FriendlyARM NanoPi NEO > DRAM: 512 MiB > MMC: SUNXI SD/MMC: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default = environment >=20 > Failed (-5) > In: serial > Out: serial > Err: serial > Net: phy interface0 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0=20 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found EFI removable media binary efi/boot/bootarm.efi > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Scanning disks on usb... > Disk usb0 not ready > Disk usb1 not ready > Disk usb2 not ready > Disk usb3 not ready > Scanning disks on mmc... > MMC Device 1 not found > MMC Device 2 not found > MMC Device 3 not found > Found 3 disks > 493860 bytes read in 25 ms (18.8 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > ## Starting EFI application at 42000000 ... > Consoles: EFI console =20 > FreeBSD/arm EFI loader, Revision 1.1 > (Fri Aug 3 10:00:59 IDT 2018 danny@pe-44) >=20 > Command line arguments: l > EFI version: 2.70 > EFI Firmware: Das U-Boot (rev 0.00) > Console: efi (0) > Load Path: /\efi\boot\bootarm.efi > Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0xc0= f,0x1ffe0) > Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0xc0= f,0x1ffe0) > Setting currdev to disk0p1: > Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x20= c2e,0x3df3c2) > Setting currdev to disk0p2: > ubenv not found > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=3D0x6cf66c data=3D0x68938+0x4f048 = syms=3D[0x4+0x807e0+0x4+0xd2a75] > efi-autoresizecons: Neither Graphics Output Protocol nor Universal = Graphics Adapter present >=20 > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by EFI at 0x47ffb000. > EHCI failed to shut down host controller. > Kernel entry at 0x53000180... > Kernel args: (null) > modulep: 0xc08e1000 > relocation_offset 0 >=20 >=20 >=20 > I will now try to build a new MBR/image =E2=80=A6 the main problem was that I built a kernel using ALLWINNER_UP, so using GENERIC I finally got it to boot! also it seems that the newer version of ubldr/efi are more strict, my = original MBR had the root partition as /dev/mmcsd0s2 (ie type freebsd) and was ignored, rebuilding the image with type freebsd-ufs - = /dev/mmcsd0s2a fixed that. nitpicking: on boot: ... real memory =3D 0 (0MB) avail memory =3D 507469824 (483 MB) danny >=20 > cheers, >=20 > danny >=20 >=20 >=20 >> On 3 Aug 2018, at 09:08, Daniel Braniss wrote: >>=20 >>=20 >>=20 >>> On 3 Aug 2018, at 08:43, Emmanuel Vadot = wrote: >>>=20 >>> On Fri, 3 Aug 2018 08:16:06 +0300 >>> Daniel Braniss > = wrote: >>>=20 >>>>=20 >>>>=20 >>>>> On 2 Aug 2018, at 21:45, Emmanuel Vadot = wrote >>>> ... >>>>> Did you also update ubldr.bin ? (not just ubldr) >>>> I did, and it went straight to net boot, and failed. >>>>=20 >>>> ... >>>>>=20 >>>>> Also please consider switching to efi boot, just deleting boot.scr = and >>>>> copying loader.efi as EFI/BOOT/bootarm.efi is enough. >>>>=20 >>>> no problem, i?ll try ASAP. >>>> Q: this to the FAT partition? >>>>=20 >>>> my fat did not have the boot.scr, adding it did not change things >>>=20 >>> Based on your first mail you did have it >>=20 >> I was trying to answer too many questions with a one liner :-) >> I first tried booting an old sd image with latest current but old = u-boot, old FAT stuff, and got stuck. >> I then upgraded the u-boot, got different results=20 >> then upgraded ubldr[.bin] >> different results but no success, adding the boot.scr didn=E2=80=99t = seem to make a=20 >> difference. >> In any case I will try efi boot ASAP with latest ubldr. >>=20 >>=20 >>>=20 >>>> BTW, iboot.scr has some binary stuff, is that ok? >>>=20 >>> yes it's supposed to be a binary file. >>>=20 >>>>=20 >>>> thanks, >>>> danny >>>>=20 >>>>>=20 >>>>>> in any case I would like to help but things are getting too = complicated :-) >>>>>>=20 >>>>>>=20 >>>>>> thanks, >>>>>> danny >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> freebsd-arm@freebsd.org mailing = list >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = >>>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org = " >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Emmanuel Vadot > > >>>>=20 >>>=20 >>>=20 >>> --=20 >>> Emmanuel Vadot > > >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Aug 3 16:03:09 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48AB6106D9C7 for ; Fri, 3 Aug 2018 16:03:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A826C89EAF for ; Fri, 3 Aug 2018 16:03:08 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w73G3NGG007023 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Aug 2018 09:03:24 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w73G3MhU007022; Fri, 3 Aug 2018 09:03:22 -0700 (PDT) (envelope-from fbsd) Date: Fri, 3 Aug 2018 09:03:22 -0700 From: bob prohaska To: Warner Losh Cc: "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: RPI3 swap experiments (insufficient swap) Message-ID: <20180803160322.GA6825@www.zefox.net> References: <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180803010932.GA4321@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 16:03:09 -0000 On Fri, Aug 03, 2018 at 02:49:57AM -0600, Warner Losh wrote: > On Thu, Aug 2, 2018 at 7:09 PM, bob prohaska wrote: > > > In the end the console carried a stream of what look like hardware errors > > referencing > > da0, but all was forgiven after reboot and a couple cycles of fsck -fy. An > > excerpt > > is in the readme file. > > > > Unless the OOM is somehow killing a kernel thread, these errors are the > root cause of all the crazy. Something happens along the way and we find > that our error recovery to that something is bad and we never complete more > I/O to the device (if I read the earlier thread right). No good can come > from this. Is it not odd that when OOMA acts prematurely no errors associated with da0 make it to the console? > The OOM is then doing weird things, but when the device goes > away we're pretty bad at coping right now. The question, though, is how can > we improve the USB / umass parts of the stack to do enough error recovery > so we can survive whatever glitch that's causing it to stop talking to the > device (and/or avoid that glitch in the first place). The disk/ssd isn't > really bad, but we have some bug either in the USB host adapter, the USB > stack, or in the umass SIM (or some combination). > Can you suggest any experiments a naive user might perform to help identify the culprit? There's also a Pi2 running 11-stable available. Right now it has storage set up like so: bob@www:~ % gpart show da0 => 0 122544516 da0 BSD (58G) 0 4194304 1 freebsd-ufs (2.0G) 4194304 4194304 2 freebsd-swap (2.0G) 8388608 6291456 4 freebsd-ufs (3.0G) 14680064 107864452 5 freebsd-ufs (51G) bob@www:~ % gpart show mmcsd0 => 63 15523777 mmcsd0 MBR (7.4G) 63 102375 1 !12 [active] (50M) 102438 1994714 2 freebsd (974M) 2097152 13426688 - free - (6.4G) It could be given extra swap partitions on mmcsd0 so as to mimic the insufficient swap problem on a 32 bit system. The Pi2 is known to suffer the premature OOMA kill problem, it's never been subjected to a deliberate run-out-of-swap condition. Might there be something in the stress2 test suite that would be more revealing more promptly than -j4 buildworld? Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Fri Aug 3 16:21:45 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 110DE106E1C1 for ; Fri, 3 Aug 2018 16:21:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A44CD8ACB3 for ; Fri, 3 Aug 2018 16:21:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id F1ED5E868 for ; Fri, 3 Aug 2018 16:21:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w73GLhf4099268 for ; Fri, 3 Aug 2018 16:21:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w73GLhOc099267 for freebsd-arm@FreeBSD.org; Fri, 3 Aug 2018 16:21:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 230333] BANANAPI 20180802-r337160 panic on boot Date: Fri, 03 Aug 2018 16:21:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gjb@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 16:21:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230333 Bug ID: 230333 Summary: BANANAPI 20180802-r337160 panic on boot Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: gjb@FreeBSD.org Created attachment 195821 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D195821&action= =3Dedit bananapi console Console output attached. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Aug 3 19:49:09 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A9D0104E0AE for ; Fri, 3 Aug 2018 19:49:09 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DB03E725B9 for ; Fri, 3 Aug 2018 19:49:08 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9F451104E0AD; Fri, 3 Aug 2018 19:49:08 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B7A8104E0AC for ; Fri, 3 Aug 2018 19:49:08 +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 DCFFE725B8 for ; Fri, 3 Aug 2018 19:49:07 +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 eba689d2; Fri, 3 Aug 2018 21:49:05 +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=cL2dAQH9uytOOp5z5SBR7oNQMNs=; b=J7x9UDvEW4mvvbdRNkRU1L1qn69h kwpsBSD72e8PnOrcTAARNMjyolUt1ayCC48nXaHJBpxpX23lgSUZjcmibZ3hfIc3 6msbAT4Ir1CsSZeSqnxSdzTLqVifmlEQeVPaci4czK+6XnVmqiUB3odUH5Yu/Jfi GjmF7UYzJvO0R5g= 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=Scq5V7ygDYWXaK8HxAMwR9mugSED+exs/KykmVbhbsJlrU4Jyp0YaeE2 h31jePOqDFhRDAnH0KOVcoLfF9RT50RsfMnYnBu1j0Xw7zSfewyz80iAyFdn2nvr 2umhfQep0cvzS87PsJ4bHKf5z/kzZsKt3k7hZ4bEugDMK5n42RY= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id fd3c6c6e TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 3 Aug 2018 21:49:05 +0200 (CEST) Date: Fri, 3 Aug 2018 21:49:05 +0200 From: Emmanuel Vadot To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" Subject: Re: booting current from nano-neo/allwinner now failes Message-Id: <20180803214905.73b1b6351209f7fa69ea2036@bidouilliste.com> In-Reply-To: <511F3AD9-8897-4223-ACD3-59807E7109B4@cs.huji.ac.il> References: <20180802204537.26af888414c4561b624fafd3@bidouilliste.com> <20180803074355.cc6feef658039a899aff1841@bidouilliste.com> <0842173A-A76E-48D7-9B46-3419F5CAB70C@cs.huji.ac.il> <511F3AD9-8897-4223-ACD3-59807E7109B4@cs.huji.ac.il> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 19:49:09 -0000 On Fri, 3 Aug 2018 18:41:48 +0300 Daniel Braniss wrote: >=20 >=20 > > On 3 Aug 2018, at 11:32, Daniel Braniss wrote: > >=20 > > some time later - actually several hours - I made a new image and > >=20 > > - using latest ubldr and with boot.scr > > I think my problem is the sd image, it doesn?t like my MBR because as= =20 > > opposed to you I get: > > ? > > Probing all disk devices? > > Checking unit=3D0 slice=3D partition=3D? > >=20 > > as opposed tour case where after the ? you get good. > >=20 > > - so switching to EFI it get stuck: > >=20 > > U-Boot SPL 2018.07 (Aug 01 2018 - 17:37:02 +0300) > > DRAM: 512 MiB > > Trying to boot from MMC1 > >=20 > >=20 > > U-Boot 2018.07 (Aug 01 2018 - 17:37:02 +0300) Allwinner Technology > >=20 > > CPU: Allwinner H3 (SUN8I 1680) > > Model: FriendlyARM NanoPi NEO > > DRAM: 512 MiB > > MMC: SUNXI SD/MMC: 0 > > Loading Environment from FAT... *** Warning - bad CRC, using default en= vironment > >=20 > > Failed (-5) > > In: serial > > Out: serial > > Err: serial > > Net: phy interface0 > > eth0: ethernet@1c30000 > > starting USB... > > USB0: USB EHCI 1.00 > > USB1: USB OHCI 1.0 > > scanning bus 0 for devices... 1 USB Device(s) found > > scanning usb for storage devices... 0 Storage Device(s) found > > Hit any key to stop autoboot: 0=20 > > switch to partitions #0, OK > > mmc0 is current device > > Scanning mmc 0:1... > > Found EFI removable media binary efi/boot/bootarm.efi > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > > Scanning disks on usb... > > Disk usb0 not ready > > Disk usb1 not ready > > Disk usb2 not ready > > Disk usb3 not ready > > Scanning disks on mmc... > > MMC Device 1 not found > > MMC Device 2 not found > > MMC Device 3 not found > > Found 3 disks > > 493860 bytes read in 25 ms (18.8 MiB/s) > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > > ## Starting EFI application at 42000000 ... > > Consoles: EFI console =20 > > FreeBSD/arm EFI loader, Revision 1.1 > > (Fri Aug 3 10:00:59 IDT 2018 danny@pe-44) > >=20 > > Command line arguments: l > > EFI version: 2.70 > > EFI Firmware: Das U-Boot (rev 0.00) > > Console: efi (0) > > Load Path: /\efi\boot\bootarm.efi > > Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)= /HD(1,0x01,0,0xc0f,0x1ffe0) > > Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/H= D(1,0x01,0,0xc0f,0x1ffe0) > > Setting currdev to disk0p1: > > Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,= 0x01,0,0x20c2e,0x3df3c2) > > Setting currdev to disk0p2: > > ubenv not found > > Loading /boot/defaults/loader.conf > > /boot/kernel/kernel text=3D0x6cf66c data=3D0x68938+0x4f048 syms=3D[0x4+= 0x807e0+0x4+0xd2a75] > > efi-autoresizecons: Neither Graphics Output Protocol nor Universal Grap= hics Adapter present > >=20 > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... =20 > > Using DTB provided by EFI at 0x47ffb000. > > EHCI failed to shut down host controller. > > Kernel entry at 0x53000180... > > Kernel args: (null) > > modulep: 0xc08e1000 > > relocation_offset 0 > >=20 > >=20 > >=20 > > I will now try to build a new MBR/image ? >=20 > the main problem was that I built a kernel using ALLWINNER_UP, so > using GENERIC I finally got it to boot! Thanks for reminding me that I needed to delete this kernel config file :) > also it seems that the newer version of ubldr/efi are more strict, my ori= ginal MBR > had the root partition as /dev/mmcsd0s2 (ie type freebsd) > and was ignored, rebuilding the image with type freebsd-ufs - /dev/mmcsd0= s2a fixed that. I think this is normal. > nitpicking: on boot: > ... > real memory =3D 0 (0MB) > avail memory =3D 507469824 (483 MB) I've seen that but never looked at how the kernel find those values. >=20 > danny >=20 >=20 >=20 > >=20 > > cheers, > >=20 > > danny > >=20 > >=20 > >=20 > >> On 3 Aug 2018, at 09:08, Daniel Braniss wrote: > >>=20 > >>=20 > >>=20 > >>> On 3 Aug 2018, at 08:43, Emmanuel Vadot wrote: > >>>=20 > >>> On Fri, 3 Aug 2018 08:16:06 +0300 > >>> Daniel Braniss > wro= te: > >>>=20 > >>>>=20 > >>>>=20 > >>>>> On 2 Aug 2018, at 21:45, Emmanuel Vadot wro= te > >>>> ... > >>>>> Did you also update ubldr.bin ? (not just ubldr) > >>>> I did, and it went straight to net boot, and failed. > >>>>=20 > >>>> ... > >>>>>=20 > >>>>> Also please consider switching to efi boot, just deleting boot.scr = and > >>>>> copying loader.efi as EFI/BOOT/bootarm.efi is enough. > >>>>=20 > >>>> no problem, i?ll try ASAP. > >>>> Q: this to the FAT partition? > >>>>=20 > >>>> my fat did not have the boot.scr, adding it did not change things > >>>=20 > >>> Based on your first mail you did have it > >>=20 > >> I was trying to answer too many questions with a one liner :-) > >> I first tried booting an old sd image with latest current but old u-bo= ot, old FAT stuff, and got stuck. > >> I then upgraded the u-boot, got different results=20 > >> then upgraded ubldr[.bin] > >> different results but no success, adding the boot.scr didn?t seem to m= ake a=20 > >> difference. > >> In any case I will try efi boot ASAP with latest ubldr. > >>=20 > >>=20 > >>>=20 > >>>> BTW, iboot.scr has some binary stuff, is that ok? > >>>=20 > >>> yes it's supposed to be a binary file. > >>>=20 > >>>>=20 > >>>> thanks, > >>>> danny > >>>>=20 > >>>>>=20 > >>>>>> in any case I would like to help but things are getting too compl= icated :-) > >>>>>>=20 > >>>>>>=20 > >>>>>> thanks, > >>>>>> danny > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>> _______________________________________________ > >>>>>> freebsd-arm@freebsd.org mailing l= ist > >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >>>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.= org " > >>>>>=20 > >>>>>=20 > >>>>> --=20 > >>>>> Emmanuel Vadot > > > >>>>=20 > >>>=20 > >>>=20 > >>> --=20 > >>> Emmanuel Vadot >= > > >>=20 > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >=20 > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Aug 3 22:09:03 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E7DF1052D32 for ; Fri, 3 Aug 2018 22:09:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 822267794D for ; Fri, 3 Aug 2018 22:09:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w73M9Fl3008027 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Aug 2018 15:09:16 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w73M9FaH008026; Fri, 3 Aug 2018 15:09:15 -0700 (PDT) (envelope-from fbsd) Date: Fri, 3 Aug 2018 15:09:14 -0700 From: bob prohaska To: Jamie Landeg-Jones Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments (insufficient swap) Message-ID: <20180803220914.GA7991@www.zefox.net> References: <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180803010932.GA4321@www.zefox.net> <201808031719.w73HJhNM093116@donotpassgo.dyslexicfish.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201808031719.w73HJhNM093116@donotpassgo.dyslexicfish.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 22:09:03 -0000 On Fri, Aug 03, 2018 at 06:19:43PM +0100, Jamie Landeg-Jones wrote: > > Unfortunately/Fortunately, I've experienced the same OOM issues, easily replicable, > on the rpi3, but without any disk errors reported (when using swap only on > microsd and when only on usb) That matches my usual experience. The "disk errors" show up under duress, as when the machine is deliberately run out of swap. Much more rarely, they turn up on a reboot, seemingly about the time the system mounts the filesystems. At one point a series of reboots failed consecutively. Simply going to single user first, then exiting the shell, allowed a successful startup. Does anything special happen on the very first reference to a storage device during startup? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sat Aug 4 03:51:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E92BA105C78E for ; Sat, 4 Aug 2018 03:51:04 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (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 8CF7B82FCD for ; Sat, 4 Aug 2018 03:51:04 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w743p3gN086199; Sat, 4 Aug 2018 04:51:03 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w743p25Z086198; Sat, 4 Aug 2018 04:51:02 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201808040351.w743p25Z086198@donotpassgo.dyslexicfish.net> Date: Sat, 04 Aug 2018 04:51:01 +0100 Organization: Dyslexic Fish To: jamie@catflap.org, fbsd@www.zefox.net Cc: freebsd-arm@freebsd.org, fbsd@www.zefox.net Subject: Re: RPI3 swap experiments (insufficient swap) References: <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180803010932.GA4321@www.zefox.net> <201808031719.w73HJhNM093116@donotpassgo.dyslexicfish.net> <20180803220914.GA7991@www.zefox.net> In-Reply-To: <20180803220914.GA7991@www.zefox.net> 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 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sat, 04 Aug 2018 04:51:03 +0100 (BST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 03:51:05 -0000 bob prohaska wrote: > That matches my usual experience. The "disk errors" show up under duress, > as when the machine is deliberately run out of swap. Much more rarely, they > turn up on a reboot, seemingly about the time the system mounts the filesystems. > > At one point a series of reboots failed consecutively. Simply going to single > user first, then exiting the shell, allowed a successful startup. > > Does anything special happen on the very first reference to a storage device > during startup? I haven't seen anything like that, but then, you've most likely done more rebooting and testing than I have. No idea on your question, sorry... cheers, Jamie From owner-freebsd-arm@freebsd.org Sat Aug 4 03:55:26 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4381105CACD for ; Sat, 4 Aug 2018 03:55:25 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (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 91442832FD; Sat, 4 Aug 2018 03:55:25 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id w743tPW2039730; Sat, 4 Aug 2018 04:55:25 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id w743tPsF039729; Sat, 4 Aug 2018 04:55:25 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> Date: Sat, 04 Aug 2018 04:55:25 +0100 Organization: Dyslexic Fish To: marklmi@yahoo.com, jamie@catflap.org Cc: markj@freebsd.org, freebsd-arm@freebsd.org, fbsd@www.zefox.net Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> In-Reply-To: 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 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sat, 04 Aug 2018 04:55:25 +0100 (BST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 03:55:26 -0000 Mark Millard wrote: > If Inact+Laundry+Buf(?)+Free was not enough to provide sufficient > additional RAM, I'd would have guessed that some Active Real Memory > should then have been paged/swapped out and so RAM would be made > available. (This requires the system to have left itself sufficient > room in RAM for that guessed activity.) > > But I'm no expert at the intent or actual operation. > > Bob P.'s reports (for having sufficient swap space) > also indicate the likes of: > > v_free_count: 5439, v_inactive_count: 1 > > > So all the examples have: "v_inactive_count: 1". > (So: vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt==1 ) Thanks for the feedback. I'll do a few more runs and other stress tests to see if that result is consistent. I'm open to any other idea too! Cheers, J From owner-freebsd-arm@freebsd.org Sat Aug 4 07:15:02 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE82E106094D for ; Sat, 4 Aug 2018 07:15:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C3FD89240 for ; Sat, 4 Aug 2018 07:15:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: pRfnMs4VM1lozsoavHuQOsomz0ff8C04BLPtJ5woZsczsYFBcq9tUqhYmBQPkSr ZlXHlMD1gNjPI4z95xFwa1HfjbSlO4FWzTdOujB2IBmKOtxLmXsTN6n._zt_ieGavBRmGOSQYeAo DIaYdsrBMNlORjEvFDTS69NiFm06pE8HUPCnb98m9ZaeZHQgvrkpgz9XVBVJQCJRLaLEqwnJ94i7 VOhv2d9yNErhtILUGy9dGKP268gXZKU3uLlsyeu0jtMHKIUdaVd.tZwQMjTXcRcEohTeqtilozPD E3Z839bDSz__lUkpw_B1aVNksSg0W2GVs06PYbXw5L9ivw09Vc3aMp7KP7xTQUZGU.yr2jGrU8wr AGC.uus4QxQgSwWJme7Wu2Aot59w9I8GSxdh_jEvCcRtPGsbrcShy3JBE7E9uRACDSKeOtqdcFRV tear0XvD0uFgPdjiXNoDS3uia3d3H.JV0GuYcdvQEc7.q5gyWpab6h6PWx9Jdht7K62F3L1HK_P3 OuGVinzDyT7z9lB2K3XTS6S6m_CQHXTJL957YIYneFFygQhgPstRX07TAuwY9hKg0vWGrl3w2owS cLoP94IgmWGn8IGkxm3BU8PYJEqNUM3_96IOWP4MRRnd9sz1vAw_MmKM3f_kI5Qi4zVHGZJUfg2F eXSTMTaQezX3rYE6QWcMWzjCjlyHJl0PUJZEFuuH73qtz5WBYwqVokGRsMgUwFEQtqphuOh5ES2G IJ21acnsXWoybg8s_r55b6Gn2472jrqvcXhrDyXTQgd8V4xnUud5c.9Oepb6Xl2IWXZPBzqZ3tsu oXXhuE6nSwl.twyhlgHp._MrtqKxi3i8Rngip.RPWxusD4UUD4lAtWUzcpXBLa0w535xsH9EtXSf d_6sQmvKkXwo8cIa_hOiexoGQY8AbVzAMN2MTWJOz2R56aewhF_DwEmoFBs0pEMvx0r748J2dZvJ mJ4NUxoklRCuPFrQIzDjnDJ96x0EF7FQT_ZWGhRk7MbWN06kqDBi2aCK969FvDatITEm5.4i6SBk ScD2Ry00bJZGKZErQKg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Sat, 4 Aug 2018 07:14:55 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp421.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5e94443bcb52d657513d35267e5c675d; Sat, 04 Aug 2018 07:14:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> Date: Sat, 4 Aug 2018 00:14:52 -0700 Cc: markj@freebsd.org, freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> <20180731191016.GD94742@www.zefox.net> <23793AAA-A339-4DEC-981F-21C7CC4FE440@yahoo.com> <20180731231912.GF94742@www.zefox.net> <2222ABBD-E689-4C3B-A7D3-50AECCC5E7B2@yahoo.com> <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> To: Jamie Landeg-Jones , bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 07:15:02 -0000 On 2018-Aug-3, at 8:55 PM, Jamie Landeg-Jones wrote: > Mark Millard wrote: > >> If Inact+Laundry+Buf(?)+Free was not enough to provide sufficient >> additional RAM, I'd would have guessed that some Active Real Memory >> should then have been paged/swapped out and so RAM would be made >> available. (This requires the system to have left itself sufficient >> room in RAM for that guessed activity.) >> >> But I'm no expert at the intent or actual operation. >> >> Bob P.'s reports (for having sufficient swap space) >> also indicate the likes of: >> >> v_free_count: 5439, v_inactive_count: 1 >> >> >> So all the examples have: "v_inactive_count: 1". >> (So: vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt==1 ) > > Thanks for the feedback. I'll do a few more runs and other stress tests > to see if that result is consistent. I'm open to any other idea too! > The book "The Design and Implementation of the FreeBSD Operating System" (2nd edition, 2014) states (page labeled 296): QUOTE: The FreeBSD swap-out daemon will not select a runnable processes to swap out. So, if the set of runnable processes do not fit in memory, the machine will effectively deadlock. Current machines have enough memory that this condition usually does not arise. If it does, FreeBSD avoids deadlock by killing the largest process. If the condition begins to arise in normal operation, the 4.4BSD algorithm will need to be restored. END QUOTE. As near as I can tell, for the likes of rpi3's and rpi2's, the condition is occurring during buildworld "normal operation" that tries to use the available cores to advantage. (Your context does not have the I/O problems that Bob P.'s have had in at least some of your OOM process kill examples, if I understand right.) (4.4BSD used to swap out the runnable process that had been resident the longest, followed by the processes taking turns being swapped out. I'll not quote the exact text about such.) So I guess the question becomes, is there a reasonable way to enable the 4.4BSD style of "Swapping" for "small" memory machines in order to avoid having to figure out how to not end up with OOM process kills while also not just wasting cores by using -j1 for buildworld? In other words: enable swapping out active RAM when it eats nearly all the non-wired RAM. But it might be discovered that the performance is not better than using fewer cores during buildworld. (Experiments needed and possibly environment specific for the tradeoffs.) Avoiding having to figure out the maximum -j? that avoids OOM process kills but avoids just sticking to -j1 seems and advantage for some rpi3 and rpi2 folks. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Aug 4 13:41:39 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 023EF106BCB8 for ; Sat, 4 Aug 2018 13:41:39 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8323477B58 for ; Sat, 4 Aug 2018 13:41:38 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w74DeFuB074265 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 4 Aug 2018 06:40:15 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w74DeFbv074242 for freebsd-arm@freebsd.org; Sat, 4 Aug 2018 06:40:15 -0700 (PDT) (envelope-from warlock) Date: Sat, 4 Aug 2018 06:40:15 -0700 From: John Kennedy To: freebsd-arm Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180804134015.GA30738@phouka1.phouka.net> References: <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 13:41:39 -0000 On Sat, Aug 04, 2018 at 12:14:52AM -0700, Mark Millard via freebsd-arm wrote: > ... QUOTE: > The FreeBSD swap-out daemon will not select a runnable processes to swap > out. So, if the set of runnable processes do not fit in memory, the > machine will effectively deadlock. Current machines have enough memory > that this condition usually does not arise. If it does, FreeBSD avoids > deadlock by killing the largest process. If the condition begins to arise > in normal operation, the 4.4BSD algorithm will need to be restored. > END QUOTE. > > As near as I can tell, for the likes of rpi3's and rpi2's, the condition > is occurring during buildworld "normal operation" that tries to use the > available cores to advantage. (Your context does not have the I/O > problems that Bob P.'s have had in at least some of your OOM process > kill examples, if I understand right.) ... For what it's worth, when I was first getting my rpi3 up and running, tuning swap and rebuilding world+kernel it really seemed to favor killing off ntpd and then usually a cc during the build (which resulted in a recoverable fail as I had to restart the build process with NO_CLEAN=yes. This was using 12-current kernels. Bumping /tmp (tmpfs) up to 75M (from 50) and having a proper freebsd-swap (vs swap-on-UFS-file) (and perhaps a V30 SD card) fixed all of that. I still have to set TMPDIR=/var/tmp (disk, not tmpfs) during installworld beacuse it tries to strip at least one really big executable during the install and that'll break with <= 75M of /tmp. From owner-freebsd-arm@freebsd.org Sat Aug 4 14:08:43 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D706106C769 for ; Sat, 4 Aug 2018 14:08:43 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8F8A78851; Sat, 4 Aug 2018 14:08:42 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w74E8Gs9083042 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Aug 2018 07:08:16 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w74E8GVQ083041; Sat, 4 Aug 2018 07:08:16 -0700 (PDT) (envelope-from jmg) Date: Sat, 4 Aug 2018 07:08:16 -0700 From: John-Mark Gurney To: Mark Millard Cc: Jamie Landeg-Jones , bob prohaska , freebsd-arm , markj@freebsd.org Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180804140816.GJ2884@funkthat.com> Mail-Followup-To: Mark Millard , Jamie Landeg-Jones , bob prohaska , freebsd-arm , markj@freebsd.org References: <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 04 Aug 2018 07:08:16 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 14:08:43 -0000 Mark Millard via freebsd-arm wrote this message on Sat, Aug 04, 2018 at 00:14 -0700: > On 2018-Aug-3, at 8:55 PM, Jamie Landeg-Jones wrote: > > > Mark Millard wrote: > > > >> If Inact+Laundry+Buf(?)+Free was not enough to provide sufficient > >> additional RAM, I'd would have guessed that some Active Real Memory > >> should then have been paged/swapped out and so RAM would be made > >> available. (This requires the system to have left itself sufficient > >> room in RAM for that guessed activity.) > >> > >> But I'm no expert at the intent or actual operation. > >> > >> Bob P.'s reports (for having sufficient swap space) > >> also indicate the likes of: > >> > >> v_free_count: 5439, v_inactive_count: 1 > >> > >> > >> So all the examples have: "v_inactive_count: 1". > >> (So: vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt==1 ) > > > > Thanks for the feedback. I'll do a few more runs and other stress tests > > to see if that result is consistent. I'm open to any other idea too! > > > > The book "The Design and Implementation of the FreeBSD Operating System" > (2nd edition, 2014) states (page labeled 296): > > QUOTE: > The FreeBSD swap-out daemon will not select a runnable processes to swap > out. So, if the set of runnable processes do not fit in memory, the > machine will effectively deadlock. Current machines have enough memory > that this condition usually does not arise. If it does, FreeBSD avoids > deadlock by killing the largest process. If the condition begins to arise > in normal operation, the 4.4BSD algorithm will need to be restored. > END QUOTE. > > As near as I can tell, for the likes of rpi3's and rpi2's, the condition > is occurring during buildworld "normal operation" that tries to use the > available cores to advantage. (Your context does not have the I/O > problems that Bob P.'s have had in at least some of your OOM process > kill examples, if I understand right.) > > (4.4BSD used to swap out the runnable process that had been resident > the longest, followed by the processes taking turns being swapped out. > I'll not quote the exact text about such.) > > So I guess the question becomes, is there a reasonable way to enable > the 4.4BSD style of "Swapping" for "small" memory machines in order to > avoid having to figure out how to not end up with OOM process kills > while also not just wasting cores by using -j1 for buildworld? > > In other words: enable swapping out active RAM when it eats nearly > all the non-wired RAM. > > But it might be discovered that the performance is not better than > using fewer cores during buildworld. (Experiments needed and > possibly environment specific for the tradeoffs.) Avoiding having > to figure out the maximum -j? that avoids OOM process kills but > avoids just sticking to -j1 seems and advantage for some rpi3 and > rpi2 folks. Interesting observation, maybe playing w/: vm.swap_idle_threshold2: Time before a process will be swapped out vm.swap_idle_threshold1: Guaranteed swapped in time for a process will help thing... lowering 2 will likely make the processes available for swap sooner... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Sat Aug 4 16:09:01 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45D9B106FCC8 for ; Sat, 4 Aug 2018 16:09:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-34.consmr.mail.ne1.yahoo.com (sonic317-34.consmr.mail.ne1.yahoo.com [66.163.184.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF59C7E0BF for ; Sat, 4 Aug 2018 16:09:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: BnOy83IVM1mU.ClszuG6XgfYiRN0iQWMDNlnfcnccchJawk.dj1lw4SvlFYBOV5 y6a7ymeizrbciLsOcszTFE62s4152oR6f7RWcAb7I2hlH50rzEwRDTNCQvIEHdEROpFuPu3Zb_RM aIohwUfbT3I3SwylhlX9dypsCoaNAJ2XM3yddWozt1MatCsgaqm66F11a50io0FNPcM.pUXiwJ7Y HvjThH7ev_Proob_e7vbm7IMthgyzEIJ0Vrs1xdYsl8YErkvarXeHDqyMEf5JTO3qMZhO2gGO.VE twWtBW7F1fj.t.D7zBMTTsEg8.RgsYUisYlKewUydKIZQ2ISO3WKfRfMbp_Rxs4W1VlKsFQhFOnm mEfPG4Z6DgTMpqOOzM8ltCNJhzgFxEFnVr9rkUnJGXcVm50_q4yDLwFQ5tFR7MRzUuMrejvOvG9D dW0cyjeo9rULFGjvclRvtl8H7uk7YjqgZHIufnX_o53Z4gaECOLF_aUxhA5yJUqs70mb2Op.u750 pEETF4_q.ckhKoEjTB4777Cg2X3hxIVOLg39BmILhdRy.5ocW5XMvCzUpF9VIvjYgtJBj7l6wYOG eUDD1jOKAFKiB2fG0JtK_ldPe0wcGG37vbTkhimXebvp7CtiIPA9SnGB8YMHfCV6gKFboMj9y8Xk hZCnVH2ei6TERKR8Pk4bmWc_RIcGa6DFrTF5fITtswd9B75b15Cj0mPiwJ922Eghlg6g9VWmHEUk VZ3BK13g.rjlpzw15gx56UqA7gv_LFH2vbM7KHQqplz6cSKLJpShMlj1ps76IaIQ5sljqPx4Ohr3 AY3qG64BTz4DrXaZueHOytQwOFsE7awzXrrLWicM_mXgUfVQDrGuIZ3F62xEYByg82OCVFwu15eL ke.yfNvw9IoNFdjHPB84S93.0rppph491YTMPQj8zCuhLFjKesW7Cy.QNEKctLEq9T4jINpPI9lG mpqOTfeM026qdc7XuUEzHC6y3f4tUo8mNJjwL5naH7tbTh_ZBtBD4iHPwANQaWHpgnEoI4uUbUev dqV55m4lEllse Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Sat, 4 Aug 2018 16:08:54 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp412.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 272678282d01dead00e1abdbd4f10ee2; Sat, 04 Aug 2018 16:08:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180804140816.GJ2884@funkthat.com> Date: Sat, 4 Aug 2018 09:08:48 -0700 Cc: Jamie Landeg-Jones , bob prohaska , freebsd-arm , markj@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <16ABD9F0-C908-479C-960D-0C1AEDE89053@yahoo.com> References: <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> <20180804140816.GJ2884@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 16:09:01 -0000 On 2018-Aug-4, at 7:08 AM, John-Mark Gurney wrote: > Mark Millard via freebsd-arm wrote this message on Sat, Aug 04, 2018 = at 00:14 -0700: >> On 2018-Aug-3, at 8:55 PM, Jamie Landeg-Jones = wrote: >>=20 >>> Mark Millard wrote: >>>=20 >>>> If Inact+Laundry+Buf(?)+Free was not enough to provide sufficient >>>> additional RAM, I'd would have guessed that some Active Real Memory >>>> should then have been paged/swapped out and so RAM would be made >>>> available. (This requires the system to have left itself sufficient >>>> room in RAM for that guessed activity.) >>>>=20 >>>> But I'm no expert at the intent or actual operation. >>>>=20 >>>> Bob P.'s reports (for having sufficient swap space) >>>> also indicate the likes of: >>>>=20 >>>> v_free_count: 5439, v_inactive_count: 1 >>>>=20 >>>>=20 >>>> So all the examples have: "v_inactive_count: 1". >>>> (So: vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt=3D=3D1 ) >>>=20 >>> Thanks for the feedback. I'll do a few more runs and other stress = tests >>> to see if that result is consistent. I'm open to any other idea too! >>>=20 >>=20 >> The book "The Design and Implementation of the FreeBSD Operating = System" >> (2nd edition, 2014) states (page labeled 296): >>=20 >> QUOTE: >> The FreeBSD swap-out daemon will not select a runnable processes to = swap >> out. So, if the set of runnable processes do not fit in memory, the >> machine will effectively deadlock. Current machines have enough = memory >> that this condition usually does not arise. If it does, FreeBSD = avoids >> deadlock by killing the largest process. If the condition begins to = arise >> in normal operation, the 4.4BSD algorithm will need to be restored. >> END QUOTE. >>=20 >> As near as I can tell, for the likes of rpi3's and rpi2's, the = condition >> is occurring during buildworld "normal operation" that tries to use = the >> available cores to advantage. (Your context does not have the I/O >> problems that Bob P.'s have had in at least some of your OOM process >> kill examples, if I understand right.) >>=20 >> (4.4BSD used to swap out the runnable process that had been resident >> the longest, followed by the processes taking turns being swapped = out. >> I'll not quote the exact text about such.) >>=20 >> So I guess the question becomes, is there a reasonable way to enable >> the 4.4BSD style of "Swapping" for "small" memory machines in order = to >> avoid having to figure out how to not end up with OOM process kills >> while also not just wasting cores by using -j1 for buildworld? >>=20 >> In other words: enable swapping out active RAM when it eats nearly >> all the non-wired RAM. >>=20 >> But it might be discovered that the performance is not better than >> using fewer cores during buildworld. (Experiments needed and >> possibly environment specific for the tradeoffs.) Avoiding having >> to figure out the maximum -j? that avoids OOM process kills but >> avoids just sticking to -j1 seems and advantage for some rpi3 and >> rpi2 folks. >=20 > Interesting observation, maybe playing w/: > vm.swap_idle_threshold2: Time before a process will be swapped out > vm.swap_idle_threshold1: Guaranteed swapped in time for a process >=20 > will help thing... lowering 2 will likely make the processes = available > for swap sooner... Looking up related information: https://www.freebsd.org/doc/handbook/configtuning-disk.html says vm.swap_idle_enabled is also involved with those two. In fact it indicates the two are not even used until vm.swap_idle_enabled=3D1 . QUOTE 11.10.1.4. vm.swap_idle_enabled The vm.swap_idle_enabled sysctl(8) variable is useful in large = multi-user systems with many active login users and lots of idle = processes. Such systems tend to generate continuous pressure on free = memory reserves. Turning this feature on and tweaking the swapout = hysteresis (in idle seconds) via vm.swap_idle_threshold1 and = vm.swap_idle_threshold2 depresses the priority of memory pages = associated with idle processes more quickly then the normal pageout = algorithm. This gives a helping hand to the pageout daemon. Only turn = this option on if needed, because the tradeoff is essentially pre-page = memory sooner rather than later which eats more swap and disk bandwidth. = In a small system this option will have a determinable effect, but in a = large system that is already doing moderate paging, this option allows = the VM system to stage whole processes into and out of memory easily. END QUOTE The defaults seem to be: # sysctl vm.swap_idle_enabled vm.swap_idle_threshold1 = vm.swap_idle_threshold2 vm.swap_idle_enabled: 0 vm.swap_idle_threshold1: 2 vm.swap_idle_threshold2: 10 Quoting the book again: QUOTE If the swapping of idle processes is enabled and the pageout daemon can = find any processes that have been sleeping for more than 10 seconds = (swap_idle_threshold2, the cutoff for considering the time sleeping to be "a long time"), it = will swap them all out. [. . .] if none of these processes are available, the = pageout daemon will swap out all processes that has been sleeping for as briefly = as 2 seconds (swap_idle_threshold1). END QUOTE. I'd not normally expect a compile or link to sleep for such long periods (unless I/O has long delays). Having, say, 4 such processes active at = the same time may be unlikely to have any of them swap out on the default = scale. (Clang is less I/O bound and more memory bound than GCC as I remember = what I've observed. That statement ignores paging/swapping by the system.) Such would likely be true on the scale of any positive integer seconds figures? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Aug 4 18:36:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 026E2104F3DF for ; Sat, 4 Aug 2018 18:36:00 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 713F482C4B for ; Sat, 4 Aug 2018 18:35:59 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1533407757; s=strato-dkim-0002; d=ulrich-grey.de; h=References:In-Reply-To:Message-Id:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=1PHqzzNtcNANZ3aaWFK4UF+brd0fYbCdwIBG1xLsuIA=; b=g0B73/qK+CUGMonCOFiSIp2ug9dosUFP+T0hrwY2aD9lzjUZuqRa3pGuRd6t9RxBDR Nx6sguTJ+GBRsD8kxci3pqaJQKwKICKntLXATWjwOyhVCzsaSHPnX3OlLq7sUVnTONLT tgm2DY5pQqqTVGDx3sEdzMedXPysvCx/3FQACLXhM7rpDLGy+P5Wat0Wme49Vm2A9fbt m2UluAnryhjfWYPQCX9/s0tF2Pcx6Bg8x6fBNe9id05R5SVpAkTll7lBU3RF+t+TsgV4 vhRNLpobRGJ96AzN4xTQuFzNCy+CwnS7nctK8I77HJV+2CcyWfiRw44PqDkcePTKLdrz DAKA== X-RZG-AUTH: ":OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhPcwkcojh9vB3Wa1dWT+c76f0FX5V4KGCpMzTV5pug==" X-RZG-CLASS-ID: mo00 Received: from ap-fbsd by smtp.strato.de (RZmta 43.14 DYNA|AUTH) with ESMTPSA id 405b6du74IZtH8G (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 4 Aug 2018 20:35:55 +0200 (CEST) Date: Sat, 4 Aug 2018 20:35:54 +0200 From: Ulrich Grey To: Emmanuel Vadot Cc: John-Mark Gurney , freebsd-arm@freebsd.org Subject: Re: Booting PINE64-LTS does not work Message-Id: <20180804203554.1143060d0a43f9b7777cba2e@ulrich-grey.de> In-Reply-To: <20180731211925.420d4068a8447c8dcbe8c0f0@bidouilliste.com> References: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> <20180731014832.GH2884@funkthat.com> <20180731211925.420d4068a8447c8dcbe8c0f0@bidouilliste.com> Organization: - X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; i386-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 18:36:00 -0000 Thank you for the hint and the commit. I successfully built an image (12.0-CURRENT r337040) for my board: PINE A64 LTS Version V 1.2 2018-01-29 After booting successfully I realized that one USB 2.0 host on the board does not work. I tried to build FreeBSD 12.0 CURRENT r337282 buildworld on the board, using an external USB HD, connected via a D-Link Hub (DUB-H7). After some hours, the build failed: ## ===> lib/clang/liblldb (all) : jemalloc_arena.c:647: Failed assertion: "nstime_compare(&decay->epoch, &time) <= 0" c++: error: unable to execute command: Abort trap (core dumped) c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) Target: aarch64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.cpp c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.sh c++: note: diagnostic msg: ******************** --- API/SBVariablesOptions.o --- *** [API/SBVariablesOptions.o] Error code 254 ## On the console, I got this: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 693018, size: 4096 pid 47471 (c++), uid 0: exited on signal 6 (core dumped) Please see the build log and the diagnostic messages etc. here: http://ulrich-grey.de/dl/FreeBSD/pineA64ltsErrMsg20180804.tgz -------------------------------------------------------------- On Tue, 31 Jul 2018 21:19:25 +0200 Emmanuel Vadot wrote: > On Mon, 30 Jul 2018 18:48:32 -0700 > John-Mark Gurney wrote: > > > Emmanuel Vadot wrote this message on Mon, Jul 30, 2018 at 20:31 +0200: > > > Best way to use FreeBSD on Pine64-LTS is to download the Pine64 > > > snapshot image and override u-boot with the u-boot-sopine. > > > > I'll second this. It works and is easy to do... the README has > > slightly wrong file names, but it's easy enough to figure out which > > one is correct... > > Fixed in r476018. > > > > Or wait until https://reviews.freebsd.org/D16487 is commited. > > > > Any specific reason that hasn't been yet? besides it being just > > created? > > Commited in r337000. > I always wait for someone from re@ for release/ related patches. > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not." > > > -- > Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Aug 4 20:24:34 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77D8F1051DD6 for ; Sat, 4 Aug 2018 20:24:34 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED273869F9 for ; Sat, 4 Aug 2018 20:24:33 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu (static62133140050.ostnet.pl [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id w74KOT4x037059 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 4 Aug 2018 22:24:29 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1533414269; bh=Uqj7xGWODuA/HPzKnhjNAVY+bYZrd7ovAXWInelSWm8=; h=To:References:From:Subject:Date:In-Reply-To; b=k0841q450av9qBsLPgJQsr+GauEszKAP2/qiGkyXq4sVIuKZDx+0OIXW9e4qL2umI YEwyzUuAlY/M2NE0tjC+CkBzlJC3R7zmT984LJzOE9K1lP4NyMi3P/B+AskK5aVmBl 4UhuquJwq+DYyUAlfyy/f88fNVLZUeHt72qsStkjbuM1UYD5QEo7bACtKuw4btPy0/ aiukBVFboIVqU7TrXL7E6AHaRAMI8XlXtH5dm7p2h6Z6z4Ot91EpNxeyDOzkvi000u VxP0N3sjivACVNoPmTBONMeTS6y3hlSQYfNueTRei4fUgNq1sKZknGx0C+puiee2sY MB4tgRCubQXZA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host static62133140050.ostnet.pl [62.133.140.50] claimed to be fomalhaut.potoki.eu To: freebsd-arm@freebsd.org References: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> <20180731014832.GH2884@funkthat.com> <20180731211925.420d4068a8447c8dcbe8c0f0@bidouilliste.com> <20180804203554.1143060d0a43f9b7777cba2e@ulrich-grey.de> From: Marek Zarychta Openpgp: preference=signencrypt Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; prefer-encrypt=mutual; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNLk1hcmVrIFphcnljaHRhIChQV1NURSkgPHphcnljaHRhQHB3c3RlLmVkdS5wbD7CwHoE EwEIACQCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlfi61cCGQEACgkQHZW8vIFppoKb Qgf+IlZ71gjdVsvBykXUyxF6tZvpdPS0jnPqZBG/+WKIv6D2YfQ1wAQCkApv1CGz3XPdWDhh 0vGmF8ZCN/fKDpMGT4pIJkn5ZZxSmediy44BGUqFBqWSsZaFb6Ub6EbRHDvfBssRQZT9TMB9 abZtF5ZZOXmxlTuDDGL1PMp5XYVSMXfBH6qU8DSv5mBQr3v1IYJyxc6ylyE6lhg52eZ73NAl uxZelDIZX+uTK2GhpP1YWDucTUBUCpquhQjpNd6jw2uhmeF1ZgbS1WiTyK4j1VqT+j1HqiLB zOq9dC52g/wEGZet82Of5EFIpp1+o3PXkAVf9CpSsm3aavp9463QlksxA87ATQRX4t3DAQgA 10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWYhJbA6GK/ LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IYa7gk906r ktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55g3+GQ28F vSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapzamV/bxIsa ZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBfBBgBCAAJ BQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJiv8aogxac QNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3wh1yMCGB l/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+mu4spKnJ/ s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD1r5P0gxz SqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQbsylq/j67 2BHXsdeqf/Ip9V4= Subject: Re: Booting PINE64-LTS does not work Message-ID: <0efaadab-80b1-43bc-4e3b-28c71ffa0136@plan-b.pwste.edu.pl> Date: Sat, 4 Aug 2018 22:24:23 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180804203554.1143060d0a43f9b7777cba2e@ulrich-grey.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8aeuZ9q1Nicf8yf7V7xQ1O16Wg2HiXU8m" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 20:24:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8aeuZ9q1Nicf8yf7V7xQ1O16Wg2HiXU8m Content-Type: multipart/mixed; boundary="J3RCwn2vByn0FTm6pb5mjgtR5MvaywJcK"; protected-headers="v1" From: Marek Zarychta To: freebsd-arm@freebsd.org Message-ID: <0efaadab-80b1-43bc-4e3b-28c71ffa0136@plan-b.pwste.edu.pl> Subject: Re: Booting PINE64-LTS does not work References: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> <20180731014832.GH2884@funkthat.com> <20180731211925.420d4068a8447c8dcbe8c0f0@bidouilliste.com> <20180804203554.1143060d0a43f9b7777cba2e@ulrich-grey.de> In-Reply-To: <20180804203554.1143060d0a43f9b7777cba2e@ulrich-grey.de> --J3RCwn2vByn0FTm6pb5mjgtR5MvaywJcK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB W dniu 04.08.2018 o=C2=A020:35, Ulrich Grey pisze: > Thank you for the hint and the commit. > I successfully built an image (12.0-CURRENT r337040) for my board: > PINE A64 LTS Version V 1.2 2018-01-29 > > After booting successfully I realized that one USB 2.0 host on the boar= d does not work. > > I tried to build FreeBSD 12.0 CURRENT r337282 buildworld on the board, = using an external > USB HD, connected via a D-Link Hub (DUB-H7). > After some hours, the build failed: > ## > =3D=3D=3D> lib/clang/liblldb (all) > : jemalloc_arena.c:647: Failed assertion: "nstime_compare(&de= cay->epoch, &time) > <=3D 0" c++: error: unable to execute command: Abort trap (core dumped)= > c++: error: clang frontend command failed due to signal (use -v to see = invocation) > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on L= LVM 6.0.1) > Target: aarch64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.f= reebsd.org/submit/ > and include the crash backtrace, preprocessed source, and associated ru= n script. c++: > note: diagnostic msg: ******************** > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.cpp > c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.sh > c++: note: diagnostic msg:=20 > > ******************** > --- API/SBVariablesOptions.o --- > *** [API/SBVariablesOptions.o] Error code 254 > ## > > On the console, I got this: > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 693018, size: 409= 6 > pid 47471 (c++), uid 0: exited on signal 6 (core dumped) > > Please see the build log and the diagnostic messages etc. here: > > http://ulrich-grey.de/dl/FreeBSD/pineA64ltsErrMsg20180804.tgz > -------------------------------------------------------------- Since I have subscribed to this list I see peoples' overwhelming desire to build FreeBSD world on small boards consuming 1-3W of power designed primarily for running lightweight embedded systems. I guess all the builders are running make world with -j n >=3D 4 on these boards with 1-2Gb of memory (these processors have usually 4 cores). The build process is running for some time, let's say 24 hours than it fails due to exhaustion of memory/swap or other issues. Running it for the next time will probably lead to the same or different issue. The waste of time is very frustrating, so people complain here. On the other hand, the build process takes about 1-2 hours on not so modern amd64 architecture hardware. So why not cross-build all on the faster amd64 machine? > On Tue, 31 Jul 2018 21:19:25 +0200 > Emmanuel Vadot wrote: > >> On Mon, 30 Jul 2018 18:48:32 -0700 >> John-Mark Gurney wrote: >> >>> Emmanuel Vadot wrote this message on Mon, Jul 30, 2018 at 20:31 +0200= : >>>> Best way to use FreeBSD on Pine64-LTS is to download the Pine64 >>>> snapshot image and override u-boot with the u-boot-sopine. >>> I'll second this. It works and is easy to do... the README has >>> slightly wrong file names, but it's easy enough to figure out which >>> one is correct... >> Fixed in r476018. >> >>>> Or wait until https://reviews.freebsd.org/D16487 is commited. >>> Any specific reason that hasn't been yet? besides it being just >>> created? >> Commited in r337000. >> I always wait for someone from re@ for release/ related patches. >> >>> --=20 >>> John-Mark Gurney Voice: +1 415 225 5579 >>> >>> "All that I will do, has been done, All that I have, has not." >> >> --=20 >> Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Marek Zarychta --J3RCwn2vByn0FTm6pb5mjgtR5MvaywJcK-- --8aeuZ9q1Nicf8yf7V7xQ1O16Wg2HiXU8m Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAltmC3wACgkQdZ/s//1S jSw32wgAuCzsuol8f0KGEecAd/dWuxRtkZxw5UTNjvYap1uuvzGhDY5Gghqqvdae UGnErPEcAHMzrNR1nQza2eKZKmSbWkRCRJjzy1jpmgA7RbxBkgHL/rhx7TImKLla b5mEf/1plCHo/TN1FOJ1+6J92fs39+1QGI2yy42qn3ia7uOewUFKO22/qlHGAYli F1qq8ziTPdq5W2A05uReqQfdFY++aAYZ3Cq8f5ke2IG3HhmycqS/CHquK0Xghrk9 +dTl1GtamigyC4LuON/at7KEBH0VSFQavK03/FJB0aKA2ja6oK3vGi+b7lr1mBp9 6uwFTvfHsYqNz2S5D2n2P0qXQ8Vn+A== =GeuU -----END PGP SIGNATURE----- --8aeuZ9q1Nicf8yf7V7xQ1O16Wg2HiXU8m-- From owner-freebsd-arm@freebsd.org Sat Aug 4 20:38:06 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0058B105278C for ; Sat, 4 Aug 2018 20:38:05 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6883087553 for ; Sat, 4 Aug 2018 20:38:05 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1533415082; s=strato-dkim-0002; d=ulrich-grey.de; h=References:In-Reply-To:Message-Id:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=ODwGX6/5VXrQcpMxv4UBeEa98pjBPO0SxYaREirbdBM=; b=lxXCFz7nD9EVqcBWFoTf3UtLdfO1rqT66YhWDLgeDi6njgnNHuzG7f9nWK7fT4y2Ds IcuiitkFWsTcjkW9BTNTqZPUR9dOPgt8mU7ys+q5jNUSIwYfciSpPCHdVh/Xx+0U5nll NZnhHFeM5MxayHxZ0G9o1TZhx2uQb3crfum8cyiSCyNKiW7z+Fi5jQUS269oDgCeCAwg Em2V89hcXG0ITMJ2qOE/wwfuY95Lx8qpW5aMYcAiLLjqgV3xRAshB6hlufaK+yeo8+yz odDOj5bhEkj/nOcNTu9/aIn4Pa75GC9Fng+ItuLgdAxgk+fw1QmwEyebfm/wOdrJSnhF Zt1A== X-RZG-AUTH: ":OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhPcwkcojh9vB3Wa1dWT+c76f0FX5V4KGCpMzTV5pug==" X-RZG-CLASS-ID: mo00 Received: from ap-fbsd by smtp.strato.de (RZmta 43.14 DYNA|AUTH) with ESMTPSA id 405b6du74Kc2HLE (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 4 Aug 2018 22:38:02 +0200 (CEST) Date: Sat, 4 Aug 2018 22:38:01 +0200 From: Ulrich Grey To: Marek Zarychta Cc: freebsd-arm@freebsd.org Subject: Re: Booting PINE64-LTS does not work Message-Id: <20180804223801.d531334220281a6d491d3b31@ulrich-grey.de> In-Reply-To: <0efaadab-80b1-43bc-4e3b-28c71ffa0136@plan-b.pwste.edu.pl> References: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> <20180731014832.GH2884@funkthat.com> <20180731211925.420d4068a8447c8dcbe8c0f0@bidouilliste.com> <20180804203554.1143060d0a43f9b7777cba2e@ulrich-grey.de> <0efaadab-80b1-43bc-4e3b-28c71ffa0136@plan-b.pwste.edu.pl> Organization: - X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; i386-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 20:38:06 -0000 Hello, I have built world and kernel successfully on a RPI-B, a CUBOX, a Wandboard-Quad using the same periphery (HD, Hub, swap-partition). For me, = it is the laymans system stability test. ------------------------------------------------------- On Sat, 4 Aug 2018 22:24:23 +0200 Marek Zarychta wrote: >=20 > W dniu 04.08.2018 o=A020:35, Ulrich Grey pisze: > > Thank you for the hint and the commit. > > I successfully built an image (12.0-CURRENT r337040) for my board: > > PINE A64 LTS Version V 1.2 2018-01-29 > > > > After booting successfully I realized that one USB 2.0 host on the boar= d does not > > work. > > > > I tried to build FreeBSD 12.0 CURRENT r337282 buildworld on the board, = using an > > external USB HD, connected via a D-Link Hub (DUB-H7). > > After some hours, the build failed: > > ## > > =3D=3D=3D> lib/clang/liblldb (all) > > : jemalloc_arena.c:647: Failed assertion: "nstime_compare(&de= cay->epoch, > > &time) <=3D 0" c++: error: unable to execute command: Abort trap (core = dumped) > > c++: error: clang frontend command failed due to signal (use -v to see = invocation) > > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on L= LVM 6.0.1) > > Target: aarch64-unknown-freebsd12.0 > > Thread model: posix > > InstalledDir: /usr/bin > > c++: note: diagnostic msg: PLEASE submit a bug report to > > https://bugs.freebsd.org/submit/ and include the crash backtrace, prepr= ocessed > > source, and associated run script. c++: note: diagnostic msg: *********= *********** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.cpp > > c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.sh > > c++: note: diagnostic msg:=20 > > > > ******************** > > --- API/SBVariablesOptions.o --- > > *** [API/SBVariablesOptions.o] Error code 254 > > ## > > > > On the console, I got this: > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 693018, size: 4096 > > pid 47471 (c++), uid 0: exited on signal 6 (core dumped) > > > > Please see the build log and the diagnostic messages etc. here: > > > > http://ulrich-grey.de/dl/FreeBSD/pineA64ltsErrMsg20180804.tgz > > -------------------------------------------------------------- >=20 >=20 > Since I have subscribed to this list I see peoples' overwhelming desire > to build FreeBSD world on small boards consuming 1-3W of power designed > primarily for running lightweight embedded systems. I guess all the > builders are running make world with -j n >=3D 4 on these boards with > 1-2Gb of memory (these processors have usually 4 cores). The build > process is running for some time, let's say 24 hours than it fails due > to exhaustion of memory/swap or other issues. Running it for the next > time will probably lead to the same or different issue. >=20 >=20 > The waste of time is very frustrating, so people complain here. On the > other hand, the build process takes about 1-2 hours on not so modern > amd64 architecture hardware. So why not cross-build all on the faster > amd64 machine? >=20 > > On Tue, 31 Jul 2018 21:19:25 +0200 > > Emmanuel Vadot wrote: > > > >> On Mon, 30 Jul 2018 18:48:32 -0700 > >> John-Mark Gurney wrote: > >> > >>> Emmanuel Vadot wrote this message on Mon, Jul 30, 2018 at 20:31 +0200: > >>>> Best way to use FreeBSD on Pine64-LTS is to download the Pine64 > >>>> snapshot image and override u-boot with the u-boot-sopine. > >>> I'll second this. It works and is easy to do... the README has > >>> slightly wrong file names, but it's easy enough to figure out which > >>> one is correct... > >> Fixed in r476018. > >> > >>>> Or wait until https://reviews.freebsd.org/D16487 is commited. > >>> Any specific reason that hasn't been yet? besides it being just > >>> created? > >> Commited in r337000. > >> I always wait for someone from re@ for release/ related patches. > >> > >>> --=20 > >>> John-Mark Gurney Voice: +1 415 225 5579 > >>> > >>> "All that I will do, has been done, All that I have, has not." > >> > >> --=20 > >> Emmanuel Vadot > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 > --=20 > Marek Zarychta >=20 >=20 From owner-freebsd-arm@freebsd.org Sat Aug 4 20:41:58 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EBCC10529B2 for ; Sat, 4 Aug 2018 20:41:58 +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 A75218801C for ; Sat, 4 Aug 2018 20:41:57 +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 14f629da; Sat, 4 Aug 2018 22:41:55 +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=+EDuXWa9IzOKoONEPJOD6Og3HEo=; b=Zov0ob3EuNBRzjbyV5qlU1Hjvitb sFM1ixwC9DD9i0cBfbE/AFxyy1uvdZK/Id6Mx/M1+lJPBsR2i7W85V+VNoDFQJez F06DUeZjMV5aXIOdNUya7muRVXqBQKcyZM3BeWxOhkK1E4tXlML/mrci9PWBkWGG Ee9Pmov9xOlnC9U= 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=WnfNwySRALg02tYBEFs58uEdwJ+2DCi87ZINm5cPbL3kHFMSgSAE5w1L E/tCbHXzSW5aqNf0prcjf4G7zAopQLIenhGgQ0LgC487AIsVh0TaTkePXKk8tSey 3uzA8tikytsloc31JS7Y6/UUie1nQNY+kEM4Hon8IXEHloHcItU= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 23637a38 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 4 Aug 2018 22:41:55 +0200 (CEST) Date: Sat, 4 Aug 2018 22:41:54 +0200 From: Emmanuel Vadot To: Ulrich Grey Cc: John-Mark Gurney , freebsd-arm@freebsd.org Subject: Re: Booting PINE64-LTS does not work Message-Id: <20180804224154.83cc77b14ebaeb0108976097@bidouilliste.com> In-Reply-To: <20180804203554.1143060d0a43f9b7777cba2e@ulrich-grey.de> References: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> <20180731014832.GH2884@funkthat.com> <20180731211925.420d4068a8447c8dcbe8c0f0@bidouilliste.com> <20180804203554.1143060d0a43f9b7777cba2e@ulrich-grey.de> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 20:41:58 -0000 On Sat, 4 Aug 2018 20:35:54 +0200 Ulrich Grey wrote: > Thank you for the hint and the commit. > I successfully built an image (12.0-CURRENT r337040) for my board: > PINE A64 LTS Version V 1.2 2018-01-29 > > After booting successfully I realized that one USB 2.0 host on the board does not work. If I understood correctly this usb port can either be routed to one of the ohci/ehci controller or the otg controller, u-boot configures it as the otg one which we don't support. There is a review https://reviews.freebsd.org/D5881 > I tried to build FreeBSD 12.0 CURRENT r337282 buildworld on the board, using an external > USB HD, connected via a D-Link Hub (DUB-H7). > After some hours, the build failed: > ## > ===> lib/clang/liblldb (all) > : jemalloc_arena.c:647: Failed assertion: "nstime_compare(&decay->epoch, &time) Looks like https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229644 > <= 0" c++: error: unable to execute command: Abort trap (core dumped) > c++: error: clang frontend command failed due to signal (use -v to see invocation) > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) > Target: aarch64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ > and include the crash backtrace, preprocessed source, and associated run script. c++: > note: diagnostic msg: ******************** > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.cpp > c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.sh > c++: note: diagnostic msg: > > ******************** > --- API/SBVariablesOptions.o --- > *** [API/SBVariablesOptions.o] Error code 254 > ## > > On the console, I got this: > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 693018, size: 4096 > pid 47471 (c++), uid 0: exited on signal 6 (core dumped) > > Please see the build log and the diagnostic messages etc. here: > > http://ulrich-grey.de/dl/FreeBSD/pineA64ltsErrMsg20180804.tgz > -------------------------------------------------------------- > On Tue, 31 Jul 2018 21:19:25 +0200 > Emmanuel Vadot wrote: > > > On Mon, 30 Jul 2018 18:48:32 -0700 > > John-Mark Gurney wrote: > > > > > Emmanuel Vadot wrote this message on Mon, Jul 30, 2018 at 20:31 +0200: > > > > Best way to use FreeBSD on Pine64-LTS is to download the Pine64 > > > > snapshot image and override u-boot with the u-boot-sopine. > > > > > > I'll second this. It works and is easy to do... the README has > > > slightly wrong file names, but it's easy enough to figure out which > > > one is correct... > > > > Fixed in r476018. > > > > > > Or wait until https://reviews.freebsd.org/D16487 is commited. > > > > > > Any specific reason that hasn't been yet? besides it being just > > > created? > > > > Commited in r337000. > > I always wait for someone from re@ for release/ related patches. > > > > > -- > > > John-Mark Gurney Voice: +1 415 225 5579 > > > > > > "All that I will do, has been done, All that I have, has not." > > > > > > -- > > Emmanuel Vadot -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Aug 4 21:42:42 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3A111053E1A for ; Sat, 4 Aug 2018 21:42:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CA8489B7D for ; Sat, 4 Aug 2018 21:42:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: mV9fn88VM1krLT_JoVvsP5QSVH5F95PIiDFLkoFunAXL4OWTUJ4efyxGfhcsvhw leMkP5tkdGj8wADK1shT7ehd1vq7M2BdmKJF1yTjV.8O2Yy6lFOI2jG5rTg2I0R4_tW7YMOscDxf ujM9PJqs9WPx89rIYqltgjlXMR.esu3Wk9gSPW_KBOmP1GTsYMQnrjPMyGNk3fDyehlGXdxZBc64 3v8tE9TX81NYqvHaTjsB_Oe2Mbn5bnaZv0wLrakRZ08CP0zl0NtYEfbHwLYhgKG7bGQORfp5pCUd y.jcYmhE6wKnrhlk80tJ.giGA7Ohwm6pZFdNOp5d.cBsSfpadqyrYqrRH6HUALuYJdazyL2MYSe. gpiuKoi5QLCYYMRDW2PXtXQLEUr1E4wbxPY673e8L2PD8jDmrqt5ZTmMueHIr0vNNrumdZ2ylWGC nSHmrO9n9HSGDdcmf3p1L4sNHndaJoL08z5gLGcgkeUJuidD7PCaN3Mjgyu.PavY_k8cdk6VSLuX 5_YgH7O7C0qJIU5eyGkC7bzPT1p0fWlBSsHXf0uwwgBtbyDfzyk4zCo.4nQdHvcA8qBzARbQowME QBeBLFPh7jFdUWd8_u8nVCFeWpf8A22pDv6hq6UvZx0QH6vTQfZpJkz_sM85Zq4kg6nPGnTmdJAB NFMRSIH0KYwyCZcWr2xawbovbmzhKBWe4Qd6.ADp3454geUfR5PXLmJQ0yNuGM.ajxYqosa7MGhi gDopSHz6iRiuxXqhX6Htz3f0GitdOy3LMEE.BSjZ.t5wCCFNIVdNuvwFVrDVzwK4YfqMmcMYYC.O Wj7_mPL9X57d_AkUYv2bqKiYSI00DtoiMHc5fkTcM.QRpetfYdK0f72E54r4lGak7b.f767goa6I fh7CP4qdOOGfh8WrNYZ9xsYvh.Rj7W5fRtSClHYEUdD0rY8dIHYrOVrSv0VouOUoeWggF5EnEcbB J.ExsmHcASDrrolbRFdZRlbHPCqsCmSUWqTr70nZUZ07RtDtTh.eoISL0LAcgVlaFB2rdcmEG3kH iEjy7bps5Cfby58w- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 4 Aug 2018 21:42:34 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp423.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b3af67a9148c366c8f84045c43deeed3; Sat, 04 Aug 2018 21:22:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Booting PINE64-LTS does not work From: Mark Millard In-Reply-To: <0efaadab-80b1-43bc-4e3b-28c71ffa0136@plan-b.pwste.edu.pl> Date: Sat, 4 Aug 2018 14:22:17 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <87BBB736-D555-4D55-9B36-85CB228CC9DC@yahoo.com> References: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> <20180731014832.GH2884@funkthat.com> <20180731211925.420d4068a8447c8dcbe8c0f0@bidouilliste.com> <20180804203554.1143060d0a43f9b7777cba2e@ulrich-grey.de> <0efaadab-80b1-43bc-4e3b-28c71ffa0136@plan-b.pwste.edu.pl> To: Marek Zarychta X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 21:42:42 -0000 On 2018-Aug-4, at 1:24 PM, Marek Zarychta wrote: > W dniu 04.08.2018 o 20:35, Ulrich Grey pisze: >> Thank you for the hint and the commit. >> I successfully built an image (12.0-CURRENT r337040) for my board: >> PINE A64 LTS Version V 1.2 2018-01-29 >>=20 >> After booting successfully I realized that one USB 2.0 host on the = board does not work. >>=20 >> I tried to build FreeBSD 12.0 CURRENT r337282 buildworld on the = board, using an external >> USB HD, connected via a D-Link Hub (DUB-H7). >> After some hours, the build failed: >> ## >> =3D=3D=3D> lib/clang/liblldb (all) >> : jemalloc_arena.c:647: Failed assertion: = "nstime_compare(&decay->epoch, &time) >> <=3D 0" c++: error: unable to execute command: Abort trap (core = dumped) >> c++: error: clang frontend command failed due to signal (use -v to = see invocation) >> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on = LLVM 6.0.1) >> Target: aarch64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> c++: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ >> and include the crash backtrace, preprocessed source, and associated = run script. c++: >> note: diagnostic msg: ******************** >>=20 >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> Preprocessed source(s) and associated run script(s) are located at: >> c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.cpp >> c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.sh >> c++: note: diagnostic msg:=20 >>=20 >> ******************** >> --- API/SBVariablesOptions.o --- >> *** [API/SBVariablesOptions.o] Error code 254 >> ## >>=20 >> On the console, I got this: >>=20 >> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 693018, size: = 4096 >> pid 47471 (c++), uid 0: exited on signal 6 (core dumped) >>=20 >> Please see the build log and the diagnostic messages etc. here: >>=20 >> http://ulrich-grey.de/dl/FreeBSD/pineA64ltsErrMsg20180804.tgz >> -------------------------------------------------------------- >=20 >=20 > Since I have subscribed to this list I see peoples' overwhelming = desire > to build FreeBSD world on small boards consuming 1-3W of power = designed > primarily for running lightweight embedded systems. I guess all the > builders are running make world with -j n >=3D 4 on these boards with > 1-2Gb of memory (these processors have usually 4 cores). The build > process is running for some time, let's say 24 hours than it fails due > to exhaustion of memory/swap or other issues. Running it for the next > time will probably lead to the same or different issue. >=20 >=20 > The waste of time is very frustrating, so people complain here. On the > other hand, the build process takes about 1-2 hours on not so modern > amd64 architecture hardware. So why not cross-build all on the faster > amd64 machine? >=20 >> . . . I do both ways, rebuilding after installing a cross-built version. It is a form of checking for how well things are operating. But I also normally restrict myself to contexts with 512 MiBytes or more per "cpu" put to use for buildworld buildkernel. So, for -j4,=20 2 GiByte board (or more) for buildworld buildkernel tests. UFS, not ZFS. Swap partition, not swap file. "Disks" that are observed to be well behaved. In the report: : jemalloc_arena.c:647: Failed assertion: = "nstime_compare(&decay->epoch, &time) <=3D 0" it is unlikely to be a out of RAM or swap/paging space issue and indicates that the environment is not stable (likely from time jumping backwards). So it is an example of discovering a problem. (Possibly https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229644 .) It may be fairly common that the folks playing with rpi3's and the like, including building FreeBSD on such, are not spending to invest in = "modern amd64 architecture hardware". And, for some, if they did, it might mean then backing off on the use of rpi3's (or whatever). FreeBSD does not really target "self hosted builds" for these smaller-device contexts and so it can take effort to find a combination that works for self hosting (for a time). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Aug 4 23:11:47 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C42D1057003 for ; Sat, 4 Aug 2018 23:11:47 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0B0E8DBF9 for ; Sat, 4 Aug 2018 23:11:45 +0000 (UTC) (envelope-from usenet@ulrich-grey.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1533424303; s=strato-dkim-0002; d=ulrich-grey.de; h=References:In-Reply-To:Message-Id:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=NYhW3eIRGBdIBi32brNCBq9Ft0AfUUtv+FcXeZ5UQpw=; b=nvazxErMkubDh5bvuDF2CN/rS1d7BPm8P6KmbHszV/e5jGlFhmaPPBw+Np7FjOt3/Y BknCPBS4k3nxgchYN7nnOffrBKqnKNKh0IX0kqW7jVzgSN1TNfb7jJOaGBP8h7DJZ4mr mWn8EDhNvYbFydfF1DjFJRcZ7eAqsnuXE4UXs1cgMOmCJ+yGr0OWvFamyOTN2JKBrWMH Dm3Z57nmQoyBVczTvsl2lm/p8/1SPwdMOnik8CfFJnO2BmCwEQoHmZ9NPIdZ3/xi3NPE GWKPyvOiZoOSHnQ1KgB6Tsy8JlDgMJiGEormGXARCJ4u8mXxufrEG0EvneuwO2TaDH5s PLKg== X-RZG-AUTH: ":OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhPcwkcojh9vB3Wa1dWT+c76f0FX5V4KGCpMzTV5pug==" X-RZG-CLASS-ID: mo00 Received: from ap-fbsd by smtp.strato.de (RZmta 43.14 DYNA|AUTH) with ESMTPSA id 405b6du74NBdHYw (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sun, 5 Aug 2018 01:11:39 +0200 (CEST) Date: Sun, 5 Aug 2018 01:11:38 +0200 From: Ulrich Grey To: Mark Millard Cc: Mark Millard via freebsd-arm , Marek Zarychta Subject: Re: Booting PINE64-LTS does not work Message-Id: <20180805011138.45fe945f2c3f79eb6c2fbedd@ulrich-grey.de> In-Reply-To: <87BBB736-D555-4D55-9B36-85CB228CC9DC@yahoo.com> References: <20180730202020.472bbf8a1b785a12699703ed@ulrich-grey.de> <20180730203159.ec4e72ee641f6a13e05174f2@bidouilliste.com> <20180731014832.GH2884@funkthat.com> <20180731211925.420d4068a8447c8dcbe8c0f0@bidouilliste.com> <20180804203554.1143060d0a43f9b7777cba2e@ulrich-grey.de> <0efaadab-80b1-43bc-4e3b-28c71ffa0136@plan-b.pwste.edu.pl> <87BBB736-D555-4D55-9B36-85CB228CC9DC@yahoo.com> Organization: - X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; i386-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 23:11:47 -0000 On Sat, 4 Aug 2018 14:22:17 -0700 Mark Millard via freebsd-arm wrote: > On 2018-Aug-4, at 1:24 PM, Marek Zarychta wrote: > > > W dniu 04.08.2018 o 20:35, Ulrich Grey pisze: > >> Thank you for the hint and the commit. > >> I successfully built an image (12.0-CURRENT r337040) for my board: > >> PINE A64 LTS Version V 1.2 2018-01-29 > >> > >> After booting successfully I realized that one USB 2.0 host on the board does not > >> work. > >> > >> I tried to build FreeBSD 12.0 CURRENT r337282 buildworld on the board, using an > >> external USB HD, connected via a D-Link Hub (DUB-H7). > >> After some hours, the build failed: > >> ## > >> ===> lib/clang/liblldb (all) > >> : jemalloc_arena.c:647: Failed assertion: "nstime_compare(&decay->epoch, > >> &time) <= 0" c++: error: unable to execute command: Abort trap (core dumped) > >> c++: error: clang frontend command failed due to signal (use -v to see invocation) > >> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) > >> Target: aarch64-unknown-freebsd12.0 > >> Thread model: posix > >> InstalledDir: /usr/bin > >> c++: note: diagnostic msg: PLEASE submit a bug report to > >> https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed > >> source, and associated run script. c++: note: diagnostic msg: ******************** > >> > >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > >> Preprocessed source(s) and associated run script(s) are located at: > >> c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.cpp > >> c++: note: diagnostic msg: /tmp/SBVariablesOptions-d0770a.sh > >> c++: note: diagnostic msg: > >> > >> ******************** > >> --- API/SBVariablesOptions.o --- > >> *** [API/SBVariablesOptions.o] Error code 254 > >> ## > >> > >> On the console, I got this: > >> > >> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 693018, size: 4096 > >> pid 47471 (c++), uid 0: exited on signal 6 (core dumped) > >> > >> Please see the build log and the diagnostic messages etc. here: > >> > >> http://ulrich-grey.de/dl/FreeBSD/pineA64ltsErrMsg20180804.tgz > >> -------------------------------------------------------------- > > > > > > Since I have subscribed to this list I see peoples' overwhelming desire > > to build FreeBSD world on small boards consuming 1-3W of power designed > > primarily for running lightweight embedded systems. I guess all the > > builders are running make world with -j n >= 4 on these boards with > > 1-2Gb of memory (these processors have usually 4 cores). The build > > process is running for some time, let's say 24 hours than it fails due > > to exhaustion of memory/swap or other issues. Running it for the next > > time will probably lead to the same or different issue. > > > > > > The waste of time is very frustrating, so people complain here. On the > > other hand, the build process takes about 1-2 hours on not so modern > > amd64 architecture hardware. So why not cross-build all on the faster > > amd64 machine? > > > >> . . . > > I do both ways, rebuilding after installing a cross-built version. > It is a form of checking for how well things are operating. > > But I also normally restrict myself to contexts with 512 MiBytes or > more per "cpu" put to use for buildworld buildkernel. So, for -j4, > 2 GiByte board (or more) for buildworld buildkernel tests. UFS, > not ZFS. Swap partition, not swap file. "Disks" that are observed > to be well behaved. > > In the report: > > : jemalloc_arena.c:647: Failed assertion: "nstime_compare(&decay->epoch, > &time) <= 0" > > it is unlikely to be a out of RAM or swap/paging space issue > and indicates that the environment is not stable (likely from > time jumping backwards). So it is an example of discovering > a problem. (Possibly > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229644 .) It wasn't an out of ram/swap issue. It was the 3rd try, I have eliminated such options (to my best knowledge). It isn't the first time I build world or large ports on an arm board. In the 1970ies I have learned to write programs using the COBOL language. I know how to find and document errors. But I have never worked in IT (EDV in German) realm, so I am a layman. Some errors remain hidden during cross compiling and arise during a native build. My aim is to scrap my PC and use an arm board running FreeBSD (if it is mature) for desktop/surfing. I don't like Linux. > It may be fairly common that the folks playing with rpi3's and the like, > including building FreeBSD on such, are not spending to invest in "modern > amd64 architecture hardware". And, for some, if they did, it might mean > then backing off on the use of rpi3's (or whatever). > > > FreeBSD does not really target "self hosted builds" for these > smaller-device contexts and so it can take effort to find a > combination that works for self hosting (for a time). > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"