From owner-freebsd-arm@freebsd.org Sun Aug 12 00:18: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 E91831057700 for ; Sun, 12 Aug 2018 00:18:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 7F73A96CB4 for ; Sun, 12 Aug 2018 00:18:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id s7-v6so7768168itb.4 for ; Sat, 11 Aug 2018 17:18:38 -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=9TlPHFXHOzJgjN1kcE6VwwJ8RwxzXn4B0zmFQb175gg=; b=2FPTV/QEJYhF9KUd1dJj+uayvQ6dIMCk7hDx5iyQkehZdTTkLOvkygXlb/s7zoKaJt 3KRlA9s6ncPOqtAnj2gEmnGsEIxygw+UZJmHJO/q7HdKETJRfFu4f9bpUEH68FFK+YBY EdqJg9SFnSwpkqpqU1ZrxXITmLxGRACCrreKMq6mxIV7YNFOkgMZtQzYFuF2P7v7JMV4 swTsT0n/6x10wEsLtLo34xyVx+HH6d9AXxfycdWs48XhupyfhpaRj9t5fEqhUWDcpV17 dMpywVho7XXKFM6Y0yyQU8mnazSJz5vLR+9tH2FAZfI4D0x8icWYTNAbcXP8CXyjHZSF sOMA== 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=9TlPHFXHOzJgjN1kcE6VwwJ8RwxzXn4B0zmFQb175gg=; b=Z8mxlShpNp3efsj/4HIozihHQbqW8Nf5iM7b8QLXH+5bMpLOIcQA/RLa8ofJnnQZkR 1YH8Pmp19UO8PvB0q6XaBFZuBGqbH3F7D4yI/DREXjLeAEesKij8vXYLWPQ7O7otlkAk NbdnEzrpRKFfrMm5Teg9Y0xgbz6GRIVRivhwUnaayV53iYX9Fh1bOrzEObjtD3RZSyO+ 2cVJtka2miezLOKPt9zDv7FYYA3cXlUx07EfXSQDMRBjdlIluOl0Bo93vdkoM57JV/iT DYL70KbUtmWeoLI9QUaGdBCycydKGeEkBYz8bGdSrzC+7CyoiTBIl7YZvcM2/pikaFvi 3TuQ== X-Gm-Message-State: AOUpUlGfeu+uo4Rncyo1t/S2SF99G2DHYXyxOjeJYHFUaqr2TFbdiia7 Er1rdJsYHhIipNA3D9RrMDRpOe2KfL52oqCnpE2s17e5kBM= X-Google-Smtp-Source: AA+uWPxWAFSLoNS6QKxWd96lJzdFfAsUcMuZkotBvh4K/6IPGR78fUDw4aU6l4Q0NY5u3fd/e33mfDZLgXnYZZYiFII= X-Received: by 2002:a24:4f52:: with SMTP id c79-v6mr6698472itb.36.1534033117739; Sat, 11 Aug 2018 17:18:37 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Sat, 11 Aug 2018 17:18:37 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <1534007513.31375.9.camel@freebsd.org> From: Warner Losh Date: Sat, 11 Aug 2018 18:18:37 -0600 X-Google-Sender-Auth: -SbSKVgjZgjsMcobkTXargyV298 Message-ID: Subject: Re: Kill old, non-INTRNG code on ARM To: Ian Lepore 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: Sun, 12 Aug 2018 00:18:39 -0000 On Sat, Aug 11, 2018 at 11:40 AM, Warner Losh wrote: > > > On Sat, Aug 11, 2018, 11:11 AM Ian Lepore wrote: > >> On Sat, 2018-08-11 at 08:52 -0600, Warner Losh wrote: >> > One last thing, even though we're in a slush, is to kill the pre- >> > INTRNG >> > code. >> > >> > It's required for armv6 and v7 for some time (only the Amlogic 8726 >> > boards >> > remain broken there). And we're down to two families of chips which >> > support >> > armv5: rt1310 and the Marvel gear. Both of them support INTRNG. >> > >> > I propose we eliminate the INTRNG option and unifdef the code to >> > remove the >> > undefined case. >> > >> > Comments? >> > >> >> Wait a sec, the INTRNG option can't go away, it's used by multiple >> arches these days. What we can do is make it on-by-default for arm* >> arches, and eliminate any #if[n]def INTRNG in arm-specific code. >> > > Yes. That's a better way of saying what I had in mind. GC the code that > will never compile on arm so we don't have to support it on 12. Or rather > trip over it... > OK. I misread things. Marvell still isn't converted to INTRNG. I have a more modest patch that moves things around a little in the config files to help... Warner From owner-freebsd-arm@freebsd.org Sun Aug 12 04:01: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 9E3A110627D0 for ; Sun, 12 Aug 2018 04:01:25 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.de (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 4144D76B16 for ; Sun, 12 Aug 2018 04:01:24 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.de (Postfix) with ESMTPSA id 5333493 for ; Sun, 12 Aug 2018 06:01:23 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 2BA011350F91D for ; Sun, 12 Aug 2018 01:01:19 -0300 (BRT) From: "Dr. Rolf Jansen" 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: BeagleBone Black with a I2C Digital Analog Converter Date: Sun, 12 Aug 2018 01:01:18 -0300 References: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> <1533743140.9860.99.camel@freebsd.org> <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com> <1534020139.31375.16.camel@freebsd.org> To: freebsd-arm@FreeBSD.org In-Reply-To: <1534020139.31375.16.camel@freebsd.org> Message-Id: <74831EA5-1BBD-442A-BD24-6DE1FDBBD575@obsigna.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: Sun, 12 Aug 2018 04:01:25 -0000 > Am 11.08.2018 um 17:42 schrieb Ian Lepore : >=20 > On Sat, 2018-08-11 at 17:30 -0300, Dr. Rolf Jansen wrote: >>>=20 >>> ... >>> , anyway I am >>> stuck at this point. >>=20 >> I got it working. >>=20 >> 1.) The specification of the DAC board which I attached to my BBB was >> wrong in regards to the acceptable Vcc voltage range (2.7 to 5.5 V). >> ...=20 >>=20 >> 2. There is still something wrong with my overlay. I need to hack in >> the same I2C1 changes into the main DT, and then the bus scan by i2c >> -f /dev/iic1 -s gives me the expected output. For my present project >> this is a minor issue, though. My best guess here is, that there is a >> problem with the reference of the I2C1 node to the proposed pinmux >> node. >>=20 >> On Debian/Linux the very overlay does work. >>=20 >=20 > Ah. The board probably does support 2.7-5.5v, but if the i2c bus has > pullups that only pull the lines up to 3.3v, that may be too close to > the VIH transition levels for the DAC chip running at 5v. Even if it's > within the VIH range, if the pulls aren't strong enough the clock > signal may not rise above the 5v VIH fast enough for reliable comms. I was too happy too soon. Now, I updated my system to the 12 snapshot from yesterday, which turned = it from 12-CURRENT to 12-ALPHA1, and with that one, the issue number 2 = above turned from a minor issue to a major problem, in order not to say = a whole new barrier is now blocking all my further efforts. It seems = that in 12-ALPHA1 the DTB is statically compiled into the kernel, and = now I cannot simply hack-in anymore some nodes which don't work by the = way of overlays OK, in the moment I may switch back to 12-CURRENT, however, I am = elaborating this project with 12 now, so I won't have any headaches in = the future. Now I am stuck again. Please may I ask for an advice? May I expect that pinmuxing will work in a not too distant future with = overlays? Am I really supposed to build a custom kernel, only for getting 2 pins = straight? Building a kernel takes forever on the BBB. Shall, I forget 12 and stay with 11 for the next years? BTW: The startup script /etc/rc.d/ntpd got a flaw. The -p option must be = removed from the cmdargs. Best regards Rolf From owner-freebsd-arm@freebsd.org Sun Aug 12 04:46: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 B578C1063BBB for ; Sun, 12 Aug 2018 04:46:49 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.de (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 384D878143 for ; Sun, 12 Aug 2018 04:46:48 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.de (Postfix) with ESMTPSA id 8099055 for ; Sun, 12 Aug 2018 06:46:47 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 022F21350F91D for ; Sun, 12 Aug 2018 01:46:43 -0300 (BRT) From: "Dr. Rolf Jansen" 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: BeagleBone Black with a I2C Digital Analog Converter Date: Sun, 12 Aug 2018 01:46:42 -0300 References: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> <1533743140.9860.99.camel@freebsd.org> <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com> <1534020139.31375.16.camel@freebsd.org> <74831EA5-1BBD-442A-BD24-6DE1FDBBD575@obsigna.com> To: freebsd-arm@FreeBSD.org In-Reply-To: <74831EA5-1BBD-442A-BD24-6DE1FDBBD575@obsigna.com> Message-Id: <2CE2A485-A96E-4DE6-BCEA-BF7A29492A5D@obsigna.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: Sun, 12 Aug 2018 04:46:49 -0000 > Am 12.08.2018 um 01:01 schrieb Dr. Rolf Jansen : >=20 >> Am 11.08.2018 um 17:42 schrieb Ian Lepore : >>=20 >> On Sat, 2018-08-11 at 17:30 -0300, Dr. Rolf Jansen wrote: >>>>=20 >>>> ... >>>> , anyway I am >>>> stuck at this point. >>>=20 >>> I got it working. >>>=20 >>> 1.) The specification of the DAC board which I attached to my BBB = was >>> wrong in regards to the acceptable Vcc voltage range (2.7 to 5.5 V). >>> ...=20 >>>=20 >>> 2. There is still something wrong with my overlay. I need to hack in >>> the same I2C1 changes into the main DT, and then the bus scan by i2c >>> -f /dev/iic1 -s gives me the expected output. For my present = project >>> this is a minor issue, though. My best guess here is, that there is = a >>> problem with the reference of the I2C1 node to the proposed pinmux >>> node. >>>=20 >>> On Debian/Linux the very overlay does work. >>>=20 >>=20 >> Ah. The board probably does support 2.7-5.5v, but if the i2c bus has >> pullups that only pull the lines up to 3.3v, that may be too close to >> the VIH transition levels for the DAC chip running at 5v. Even if = it's >> within the VIH range, if the pulls aren't strong enough the clock >> signal may not rise above the 5v VIH fast enough for reliable comms. >=20 > I was too happy too soon. >=20 > Now, I updated my system to the 12 snapshot from yesterday, which = turned it from 12-CURRENT to 12-ALPHA1, and with that one, the issue = number 2 above turned from a minor issue to a major problem, in order = not to say a whole new barrier is now blocking all my further efforts. = It seems that in 12-ALPHA1 the DTB is statically compiled into the = kernel, and now I cannot simply hack-in anymore some nodes which don't = work by the way of overlays >=20 > OK, in the moment I may switch back to 12-CURRENT, however, I am = elaborating this project with 12 now, so I won't have any headaches in = the future. Now I am stuck again. Please may I ask for an advice? >=20 > May I expect that pinmuxing will work in a not too distant future with = overlays? I found the problem with my overlay. I needed to add a __local_fixups__ = section, and with that in place, it is working on FreeBSD 12-ALPHA1. I = am sorry for the false alert. For future reference, here comes the = source for my working I2C1 overlay: /dts-v1/; /plugin/; / { compatible =3D "ti,am335x-bone-black", "ti,am335x-bone", = "ti,am33xx"; part-number =3D "I2C1"; version =3D "0001"; exclusive-use =3D "P9.17","P9.18","i2c1"; fragment@0 { target =3D <&am33xx_pinmux>; __overlay__ { i2c1_pins: pinmux_i2c1_pins { pinctrl-single,pins =3D <0x158 0x32 = 0x15c 0x32>; }; }; }; fragment@1 { target =3D <&i2c1>; __overlay__ { status =3D "okay"; pinctrl-names =3D "default"; pinctrl-0 =3D <&i2c1_pins>; clock-frequency =3D <400000>; #address-cells =3D <0x1>; #size-cells =3D <0x0>; }; }; __local_fixups__ { fragment@1 { __overlay__ { pinctrl-0 =3D <0x0>; }; }; }; }; Best regards Rolf From owner-freebsd-arm@freebsd.org Sun Aug 12 04:53: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 94AE21063F71 for ; Sun, 12 Aug 2018 04:53:23 +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 DBFCF78483; Sun, 12 Aug 2018 04:53:22 +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 06e3993c; Sun, 12 Aug 2018 06:53:14 +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=N76+2lymA7uyzcHkVtlYdJrx7hY=; b=BNOASG2fF4ziwGbx/Il8NRLofH2i 5eQsTgnowG9YrI6yFhwvKgbq1N456sRrtInsnvJlhe1bEmG85ZedPx442xjGgXH9 ZM9hmo2oTpSOW4JTjryyI4Wu+kyB2ITKaZMAVOyTY79RH5mAAm2D9JIzOFOPx0wr iqhvTBkXXiL+ipo= 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=oLA9GZdaMjCpGBA5OcloZ/exiGus++Bt0SANeDoOSPro1RMGI15/UZJT yVn/c5f3VHcBfxt2MYIqbEEX+z8qSKk9cltp/9nRbiUnqzRyPpk3Hx0kUFlye+mR Zf9VX8NP9JO/PASlcsDHqJ0TKinHeb+KqwjpLQyi/DoMcbIoPsM= 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 1a97b10c TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 12 Aug 2018 06:53:14 +0200 (CEST) Date: Sun, 12 Aug 2018 06:53:14 +0200 From: Emmanuel Vadot To: Daniel Braniss Cc: lyd mc , "freebsd-arm@freebsd.org" , Ian Lepore Subject: Re: Nanopi Neo I2C Message-Id: <20180812065314.ff83dd595460a0fadee77f59@bidouilliste.com> In-Reply-To: <5E1DB0F5-EF98-46A8-8D33-11052834E35C@cs.huji.ac.il> References: <165877705.5351934.1533988165694.ref@mail.yahoo.com> <165877705.5351934.1533988165694@mail.yahoo.com> <1533999888.31375.6.camel@freebsd.org> <2122126425.5355832.1534000914963@mail.yahoo.com> <5E1DB0F5-EF98-46A8-8D33-11052834E35C@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: Sun, 12 Aug 2018 04:53:23 -0000 On Sat, 11 Aug 2018 18:50:18 +0300 Daniel Braniss wrote: >=20 >=20 > > On 11 Aug 2018, at 18:21, lyd mc via freebsd-arm wrote: > >=20 > > Hi Ian, > > The iic bus seem to be working on linux image. I can detect the device = at 0x18. > > root@nanopi-neo:~/prog/I2C # i2c -f /dev/iic0 -s > > Hardware may not support START/STOP scanning; trying less-reliable read= method. > > Scanning I2C devices on /dev/iic0: > >=20 > > some kdump output of above command: 871 i2c CALL ioctl(0x3,I2CR= STCARD,0xbfbfec64) > > 871 i2c RET ioctl 0 > > 871 i2c CALL ioctl(0x3,I2CSTART,0xbfbfec64) > > 871 i2c RET ioctl -1 errno 2 No such file or directory > > 871 i2c CALL ioctl(0x3,I2CSTOP,0xbfbfec64) > > 871 i2c RET ioctl 0 > > . 871 i2c CALL ioctl(0x3,I2CRSTCARD,0xbfbfec64) > > 871 i2c RET ioctl 0 > > 871 i2c CALL ioctl(0x3,I2CRDWR,0xbfbfec50) > > 871 i2c RET ioctl -1 errno 2 No such file or directory > > 871 i2c CALL ioctl(0x3,I2CRSTCARD,0xbfbfec64) > > 871 i2c RET ioctl 0 > > 871 i2c CALL ioctl(0x3,I2CRDWR,0xbfbfec50) > > 871 i2c RET ioctl -1 errno 2 No such file or directory > > Seems I2CRSTCARD and I2CSTOP are the only working ioctl on me. > > I activated i2c0 using below dts code: > > i2c@1c2ac00 { > >=20 > > compatible =3D "allwinner,sun6i-a31-i2c"; > > reg =3D <0x1c2ac00 0x400>; > > interrupts =3D <0x0 0x6 0x4>; > > clocks =3D <0x1d 0x3b>; > > resets =3D <0x1d 0x2e>; > > pinctrl-names =3D "default"; > > pinctrl-0 =3D <0x20>; > > status =3D "okay"; > > #address-cells =3D <0x1>; > > #size-cells =3D <0x0>; > > phandle =3D <0x41>; > >=20 > >=20 > > Regards,Alyd > > On Saturday, August 11, 2018, 11:04:54 PM GMT+8, Ian Lepore wrote: =20 > >=20 > > On Sat, 2018-08-11 at 11:49 +0000, lyd mc via freebsd-arm wrote: > >> Hi List, > >> Can you help me make I2C work in this board? > >> I can detect the controller but cannot access it through iic ioctl.=20 > >>=20 > >> root@nanopi-neo:~/prog/I2C # dmesg |grep iic > >> iichb0: mem 0x1c2ac00- > >> 0x1c2afff irq 34 on simplebus0 > >> iicbus0: on iichb0 > >> iichb1: mem 0x1c2b000- > >> 0x1c2b3ff irq 35 on simplebus0 > >> iicbus1: on iichb1 > >> iichb2: mem 0x1c2b400- > >> 0x1c2b7ff irq 36 on simplebus0 > >> iicbus2: on iichb2 > >> iic0: on iicbus0 > >> iic1: on iicbus1 > >> iic2: on iicbus2 > >>=20 > >> kdump output: > >>=20 > >> 1290 mcp NAMI "/dev/iic0" > >> 1290 mcp RET openat 3 > >> 1290 mcp CALL ioctl(0x3,I2CRDWR,0xbfbfecd4) > >> 1290 mcp RET ioctl -1 errno 2 No such file or directory > >>=20 > >> This seems to work on my RPI. > >>=20 > >=20 > > In this case, I wonder if the "errno 2" is not ENOENT, but > > rather IIC_ENOACK which has not been translated to a proper errno > > before returning. IIC_ENOACK is basically a timeout and can happen if > > the slave address is wrong, or if the pinmux is wrong so that the bus > > is electrically inactive. > >=20 > > Is the bus working in general? Do any devices show up on a scan with > >=20 > > i2c -f /dev/iic0 -s > >=20 > > -- Ian > >=20 >=20 > the driver has timing issues (among others :-). I?m cc?ing the guys I got= a ?working? twsi stuff=20 > to see if I can pass it on. What timing issue and "other issues" are you talking about ? > danny >=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 Sun Aug 12 05:10: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 9178F1064474 for ; Sun, 12 Aug 2018 05:10:26 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh505-vm12.bullet.mail.kks.yahoo.co.jp (nh505-vm12.bullet.mail.kks.yahoo.co.jp [183.79.57.114]) by mx1.freebsd.org (Postfix) with SMTP id 78E4278DD7 for ; Sun, 12 Aug 2018 05:10:25 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.140] by nh505.bullet.mail.kks.yahoo.co.jp with NNFMP; 12 Aug 2018 05:07:42 -0000 Received: from [183.79.100.135] by t503.bullet.mail.kks.yahoo.co.jp with NNFMP; 12 Aug 2018 05:07:42 -0000 Received: from [127.0.0.1] by omp504.mail.kks.yahoo.co.jp with NNFMP; 12 Aug 2018 05:07:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 564964.58469.bm@omp504.mail.kks.yahoo.co.jp Received: (qmail 6067 invoked by uid 60001); 12 Aug 2018 05:07:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1534050462; bh=oQpB2lbWT2sk1vo7Z8ieERIMl2qFsM1ClBnPMimOz8I=; 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=lY/tx011kHCx7FmrdROaOYIau9pjJq6KdURPXjcga3+NF/fq8H5MqXkDv1fJfZoIXJWIm5xNWbeuSH45NI4RdmXNwjdRNp2OdNMHBQU3fZ2oWgRrwnMVZZJK+EcQi3qHE1SunNMVECw1YcByulihO29X+qFegDgl0LKIAmS06sk= 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=p6fwQEBKvF96TKNZh8ACq4O7E68ZfjRbNfrccn4WfTyDkJu8LGGv0lP3EbuXRtd8MwYIcznRHiqEqDk+ve4GVWB1J3soxta1+k4IzkuwN+Gcw7qzWscMYObjxI0rZBKvCujXTN8cLaWXYN0ToM0Ue5CL8N4DIEpk43xxijhjFYE=; Message-ID: <197535.81645.qm@web103907.mail.ssk.yahoo.co.jp> X-YMail-OSG: XfeSAgMVM1lDMxD00zLVw2J8_df0a4tAF8YWph2GTFMxoCWDwgNpryIxoTECubnK3wYb2_Hi.i2ftiJAs.vKY7G1gao_eqbCzYf9z1DqbeJpwe3rRg8WEea83DIlofZP0M7nXOD22fw8Mf8dRLzmNzzVuWHuOGQSgtu0uGWim4MC2GNgYxp6u00n_yL77EYMIbpMghkgUBjX0pKdBVPxkVkQQhFRy.jPpz8y9UWJ2T2o8BJjIUp_Vf2dGnu5W8v8h2utBo2ghSRq3p8xv9FA1KrikBd9fZjnbECGdWhGM_79KZEICKKOnytauGVljOtSJwsV9zUrrhDHHRDzeR5VpsRs9wak50rakf_aD2.YDy2Bz1M._53SC4not20s8ivaqI.M1CuLmGN775Xz2W92b3jJFm6Jgvyai7OeKfSh96Arwr.yKbiP8I_eXe6.Xo4cr6iC9n2o4ihV7okD61kFtlugofQXteEeUeSNa5_gwey51oj5Fi.EZBetd7JoAD.DgVsi9l18RnyGri.ze0Aia2XLpkaV.80257hWtp0Rat6EK4EJF8oL2vq9E_rX.TVD.IZDdxtI4V2Jik4nVVQMP2c_iyeeGgvKOcJQERSuqAj7slkH0pQwwJp4QEkMf50. Received: from [203.165.91.75] by web103907.mail.ssk.yahoo.co.jp via HTTP; Sun, 12 Aug 2018 14:07:40 JST X-Mailer: YahooMailWebService/0.8.111_74 X-YMail-JAS: FpBPHzUVM1nGG_GIO4jq_bZlRh70.s3u6dMGwIaUL.xO4ZxyL1RS_6HVJpUZkqVFDz9ubAVc9iqPzznnVeF7SPxvgdg88GAcF3ytk9i.69DotGhklIaUIkPHPr_6qi8obHXt References: <64850.63077.qm@web101706.mail.ssk.yahoo.co.jp> <387823.67007.qm@web101711.mail.ssk.yahoo.co.jp> <812183.70978.qm@web101705.mail.ssk.yahoo.co.jp> <892631.23713.qm@web101718.mail.ssk.yahoo.co.jp> <408.23467.qm@web101707.mail.ssk.yahoo.co.jp> <920419.9428.qm@web103910.mail.ssk.yahoo.co.jp> Date: Sun, 12 Aug 2018 14:07:40 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: solved Re: still hang up arm/ralink To: Warner Losh Cc: Michael Zhilin , "freebsd-arm@freebsd.org" In-Reply-To: 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: Sun, 12 Aug 2018 05:10:26 -0000 Hi=0A=0ASorry I lost your mail. Because of arm ML is so many mail more than= mips.=0A=0A----- Original Message -----=0A>From: Warner Losh =0A>To: Mori Hiroki =0A>Cc: Michael Zhilin ; "freebsd-arm@freebsd.org" =0A>Date:= 2018/8/12, Sun 04:14=0A>Subject: Re: solved Re: still hang up arm/ralink= =0A> =0A>=0A>=0A>=0A>=0A>=0A>On Sat, Aug 11, 2018 at 9:25 AM, Warner Losh <= imp@bsdimp.com> wrote:=0A>=0A>=0A>>=0A>>=0A>>=0A>>On Thu, Aug 9, 2018 at 11= :52 PM, Mori Hiroki wrote:=0A>>=0A>>Hi.=0A>>>=0A>>>= ----- Original Message -----=0A>>>>From: Warner Losh =0A>>>= >To: Mori Hiroki =0A>>>>Cc: Michael Zhilin ; "freebsd-arm@freebsd.org" =0A>>>>Date:= 2018/8/10, Fri 11:16=0A>>>>Subject: Re: solved Re: still hang up arm/ralin= k=0A>>>> =0A>>>>=0A>>>>Mori-san=0A>>>>=0A>>>>=0A>>>>I took your advice and = bought a Buffalo WZR2-G300N off ebay. It arrived while I was on vacation. S= o, I spent a few minutes with it today. I've installed header for serial po= rt, puzzled out the pins, found your blog that had the pins and the piece I= was missing (the baud rate). I now have added it to my test lab's terminal= server and hope to start building images for it once I get my test lab's C= I infrastructure up and running.=0A>>>>=0A>>>=0A>>>Thanks for your cooperat= ion.=0A>>>=0A>>>>=0A>>>>So, now I'm sitting at the "RT2860-EVB#" prompt fro= m uboot hoping to boot the RT1310 kernel. However, I lack instructions and = can't seem to find all the details in your posts or on your blog. How do I = load/create the RAM disk referenced in the kernel config file "options=A0 = =A0 =A0 =A0 =A0ROOTDEVNAME=3D\"cd9660:/dev/cfi d0s.rootfs.uzip\"" ? what ad= dress do I load the kernel at (0x40800000 is listed in a diagram, but 0x400= 00100 is shown in the dmesg) and which variation of the kernel should I use= ? Thanks for any help you can offer.=0A>>>>=0A>>>=0A>>>I use ZRouter build = system. But I am a suggestion normal build system.=0A>>>=0A>>>I think=A0Buf= falo WZR2-G300N is different u-boot on US and Japan model.=0A>>>Because of = my target prompt is "5VT1310-EVB#".=A0 Be careful operation.=0A>>>You can f= ind some information=A0in printenv at u-boot.=0A>>>=0A>>>Sorry I forget mem= ory address setting in build system. I add this to review.=0A>>>=0A>>>https= ://reviews.freebsd.org/D1 6622=0A>>>=0A>>>In this setting build kernel head= er is this.=0A>>>=0A>>>% readelf -h Buffalo_WZR2-G300N_kernel=0A>>>ELF Head= er:=0A>>>=A0 Magic: =A0 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00=A0= =0A>>>=A0 Class: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EL= F32=0A>>>=A0 Data:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 2's complement, little endian=0A>>>=A0 Version: =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 (current)=0A>>>=A0 OS/ABI:=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 UNIX - FreeBSD=0A>>>=A0 ABI Version= : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0=0A>>>=A0 Type:=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EXEC (Executable file)=0A>>= >=A0 Machine: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ARM=0A>>>= =A0 Version: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x1=0A>>>= =A0 Entry point address: =A0 =A0 =A0 =A0 =A0 =A0 =A0 0xc0000100=0A>>>=A0 St= art of program headers:=A0 =A0 =A0 =A0 =A0 52 (bytes into file)=0A>>>=A0 St= art of section headers:=A0 =A0 =A0 =A0 =A0 3633180 (bytes into file)=0A>>>= =A0 Flags: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x500020= 2, has entry point, Version5 EABI, =0A>>>=A0 Size of this header: = =A0 =A0 =A0 =A0 =A0 =A0 =A0 52 (bytes)=0A>>>=A0 Size of program headers: = =A0 =A0 =A0 =A0 =A0 32 (bytes)=0A>>>=A0 Number of program headers: =A0 =A0 = =A0 =A0 6=0A>>>=A0 Size of section headers: =A0 =A0 =A0 =A0 =A0 40 (bytes)= =0A>>>=A0 Number of section headers: =A0 =A0 =A0 =A0 37=0A>>>=A0 Section he= ader string table index: 34=0A>>>=0A>>>Do opjcopy and compress and make u-b= oot image by load and entry address is=A00x40000100.=0A>>>=0A>>>% file Buff= alo_WZR2-G300N_kernel.kbin .oldlzma.uboot=0A>>>=0A>>>Buffalo_WZR2-G300N_ker= nel.kbin .oldlzma.uboot: u-boot legacy uImage, FreeBSD Kernel Image, Linux/= ARM, OS Kernel Image (lzma), 999004 bytes, Wed Aug=A0 8 22:50:36 2018, Load= Address: 0x40000100, Entry Point: 0x40000100, Header CRC: 0xFEC4D6B9, Data= CRC: 0xE650EDDF=0A>>>=0A>>>It can execute on memory. (not flash)=0A>>>You = need set ipaddr and serverip on u-boot.=0A>>>=0A>>>5VT1310-EVB# tftpboot 00= 800000 Buffalo_WZR2-G300N_kernel.kbin .oldlzma.uboot=0A>>>TFTP from server = 10.10.10.3; our IP address is 10.10.10.190=0A>>>Filename 'Buffalo_WZR2-G300= N_kernel.kbi n.oldlzma.uboot'.=0A>>>Load address: 0x800000=0A>>>Loading: ##= ############################ ############################## #####=0A>>>####= ########################## ############################## #####=0A>>>######= ######################## ############################## #####=0A>>>#=0A>>>d= one=0A>>>Bytes transferred =3D 999068 (f3e9c hex)=0A>>>5VT1310-EVB# bootm= =0A>>>## Booting image at 00800000 ...=0A>>>=A0=A0 Image Name: =A0 FreeBSD = Kernel Image=0A>>>=A0=A0 Image Type: =A0 ARM Linux Kernel Image (lzma compr= essed)=0A>>>=A0=A0 Data Size:=A0 =A0 999004 Bytes =3D 975.6 kB=0A>>>=A0=A0 = Load Address: 40000100=0A>>>=A0=A0 Entry Point:=A0 40000100=0A>>>=A0=A0 Ver= ifying Checksum ... OK=0A>>>=A0=A0 Uncompressing LZMA Kernel Image ........= ...................... ............OK=0A>>>=0A>>>Starting kernel @40000100.= ..=0A>>>=0A>>>KDB: debugger backends: ddb=0A>>>KDB: current backend: ddb=0A= >>>Copyright (c) 1992-2018 The FreeBSD Project.=0A>>>Copyright (c) 1979, 19= 80, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994=0A>>>The Regents of the = University of California. All rights reserved.=0A>>>=0A>>>If you can execut= e kernel then stop at rootfs mount.=0A>>>=0A>>>I think this is first step.= =0A>>>=0A>>=0A>>=0A>>Where do I find oldlzma utility? The current one produ= ces an unbootable image:=0A>>=0A>>=0A>>%=A0objcopy -S -O binary kernel kern= el.kbin=0A>>% lzma kernel.kbin=0A>>% mkimage -A arm -O FreeBSD -T kernel -C= lzma -a 0x40000100 -e 0x40000100 -n rt1310 -d kernel.kbin.lzma kernel.kbin= .lzma.u-boot=0A>>Image Name:=A0 =A0rt1310=0A>>Created:=A0 =A0 =A0 Sat Aug 1= 1 09:06:27 2018=0A>>Image Type:=A0 =A0ARM FreeBSD Kernel Image (lzma compre= ssed)=0A>>Data Size:=A0 =A0 1317305 Bytes =3D 1286.43 KiB =3D 1.26 MiBLoad = Address: 40000100=0A>>Entry Point:=A0 40000100=0A>>% scp kernel.kbin.lzma.u= -boot tftp:tftpboot=0A>>...=0A>>RT2860-EVB# bootm## Booting image at 008000= 00 ...=0A>>=A0 =A0Image Name:=A0 =A0rt1310=0A>>=A0 =A0Image Type:=A0 =A0ARM= Unknown OS Kernel Image (lzma compressed)=0A>>=A0 =A0Data Size:=A0 =A0 131= 7305 Bytes =3D=A0 1.3 MB=A0 =A0Load Address: 40000100=0A>>=A0 =A0Entry Poin= t:=A0 40000100=0A>>=A0 =A0Verifying Checksum ... OK=0A>>=A0 =A0Uncompressin= g Kernel Image ... LZMA ERROR 1 - must RESET board to recover=0A>>OK=0A>>= =0A>>=0A>>I see you have 'oldlzma' and online instructions use an oldlzma c= ommand...=0A>=0A>=0A>I built oldlzma from zrouter and have the same results= ...=0A>=0A>=0A>Warner=0A=0AYou need make small rootfs because of this targe= t flash is too small.=0AZRouter is make cd9660 rootfs image by limited file= s and uzip.=0AAnd 64Kbyte synced kernel image append rootfs uzip.=0A=0A+---= ----------------+------+-----------+=0A|u-boot kernel image|synced|rootfs u= zip|=0A+-------------------+------+-----------+=0A=0AThis is complete image= .=0A=0AAlso you need fixed rootfs address in dts.=0A=0Asys/dts/arm/wzr2-g30= 0n.dts=0A=0AThis is flash u-boot command.=0A=0A5VT1310-EVB#=A0tftpboot 0x00= 800000 Buffalo_WZR2-G300N.zimage=0A=0A5VT1310-EVB#=A0erase 0x1F010000 0x1F3= CFFFF=0A=0A5VT1310-EVB#=A0cp.b 0x00800000 0x1F010000 $(filesize)=0A=0A5VT13= 10-EVB# reset=0A=0A=0A=0AI make auto scan rootfs=A0partition patch at geom_= flashmap.=0A=0Ahttps://reviews.freebsd.org/D13648=0A=0AThis patch scan root= fs in named firmware=A0partition.=0A=0AI have many time stop at mountroot. = This patch is solution this.=0A=0ARegards=0A=0AHiroki Mori=0A=0A>=A0=0A>War= ner=0A>>=A0=0A>>Thanks=0A>>>=0A>>>Hiroki Mori=0A>>>=0A>>>=0A>>>>=0A>>>>Warn= er=0A>>>>=0A>>>>=0A>>>>On Sat, Mar 10, 2018 at 2:31 AM, Mori Hiroki wrote:=0A>>>>=0A>>>>Hi=0A>>>>>=0A>>>>>I do try to todays c= urrent. It' work find on RT1310.=0A>>>>>=0A>>>>>https://gist.github.com/ ya= mori813/ 88224f1c96c9c592fb611b12a15e4a b5=0A>>>>>=0A>>>>>=0A>>>>>Thanks=0A= >>>>>=0A>>>>>Hiroki Mori=0A>>>>>____________________________ __ ___________= ______=0A>>>>>freebsd-arm@freebsd.org mailing list=0A>>>>>https://lists.fre= ebsd.org/ mailman/listinfo/freebsd-arm=0A>>>>>To unsubscribe, send any mail= to "freebsd-arm-unsubscribe@ freebsd.org"=0A>>>>>=0A>>>>=0A>>>>=0A>>>>=0A>= >>=0A>>=0A>=0A>=0A> From owner-freebsd-arm@freebsd.org Sun Aug 12 13:29: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 32210107036C for ; Sun, 12 Aug 2018 13:29:50 +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 C0D22883E6 for ; Sun, 12 Aug 2018 13:29:49 +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 8B2C71ECEE for ; Sun, 12 Aug 2018 13:29:48 +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 w7CDTmak062373 for ; Sun, 12 Aug 2018 13:29:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7CDTm4p062372 for freebsd-arm@FreeBSD.org; Sun, 12 Aug 2018 13:29:48 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 230561] ntpd error: only one pidfile option allowed Date: Sun, 12 Aug 2018 13:29:48 +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: cyclaero@gmail.com 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: Sun, 12 Aug 2018 13:29:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230561 Bug ID: 230561 Summary: ntpd error: only one pidfile option allowed Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: cyclaero@gmail.com FreeBSD 12.0-ALPHA1 (GENERIC) #0 r337557: Fri Aug 10 03:49:58 UTC 2018 During startup of the latest 12-CURRENT snapshot on a BeagleBone Black, I s= ee: ntpd error: only one pidfile option allowed ntpd - NTP daemon program - Ver. 4.2.8p11 Usage: ntpd [ - [] | --[{=3D| }] ]... \ [ ... ] Try 'ntpd --help' for more information. /etc/rc: WARNING: failed to start ntpd As a workaround, I changed line 104 of /etc/rc.d/ntpd ... from: command_args=3D"-p ${pidfile} -c ${ntpd_config} ${driftopt}" to: command_args=3D"-c ${ntpd_config} ${driftopt}" With this change, ntpd starts-up as usual. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sun Aug 12 13:48: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 479381070D88 for ; Sun, 12 Aug 2018 13:48:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2r.ore.mailhop.org (outbound2r.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 AA02189036 for ; Sun, 12 Aug 2018 13:48:03 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 53cb0e83-9e36-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 53cb0e83-9e36-11e8-904b-1d2e466b3c59; Sun, 12 Aug 2018 13:48:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7CDm0Qb066274; Sun, 12 Aug 2018 07:48:00 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1534081680.31375.25.camel@freebsd.org> Subject: Re: BeagleBone Black with a I2C Digital Analog Converter From: Ian Lepore To: "Dr. Rolf Jansen" , freebsd-arm@FreeBSD.org Date: Sun, 12 Aug 2018 07:48:00 -0600 In-Reply-To: <74831EA5-1BBD-442A-BD24-6DE1FDBBD575@obsigna.com> References: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> <1533743140.9860.99.camel@freebsd.org> <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com> <1534020139.31375.16.camel@freebsd.org> <74831EA5-1BBD-442A-BD24-6DE1FDBBD575@obsigna.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 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, 12 Aug 2018 13:48:04 -0000 On Sun, 2018-08-12 at 01:01 -0300, Dr. Rolf Jansen wrote: > > BTW: The startup script /etc/rc.d/ntpd got a flaw. The -p option must > be removed from the cmdargs. No, you must not set that flag in ntpd_flags in your rc.conf. Also, you must run mergemaster or otherwise arrange to update /etc/defaults/rc.conf so that it gets the new (empty) default value for ntpd_flags. -- Ian From owner-freebsd-arm@freebsd.org Sun Aug 12 13:50: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 7C67E1070F46 for ; Sun, 12 Aug 2018 13:50:56 +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 1D9B989119 for ; Sun, 12 Aug 2018 13:50:56 +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 53BA31F0B0 for ; Sun, 12 Aug 2018 13:50:55 +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 w7CDotQn002632 for ; Sun, 12 Aug 2018 13:50:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7CDotCQ002631 for freebsd-arm@FreeBSD.org; Sun, 12 Aug 2018 13:50:55 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 230561] ntpd error: only one pidfile option allowed Date: Sun, 12 Aug 2018 13:50:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution cc bug_status Message-ID: In-Reply-To: References: 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: Sun, 12 Aug 2018 13:50:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230561 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Not A Bug CC| |ian@FreeBSD.org Status|New |Closed --- Comment #1 from Ian Lepore --- The -p flag was removed from ntpd_flags in /etc/defaults/rc.conf, and must = also be removed from your rc.conf if you have overridden ntpd_flags and included that option. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sun Aug 12 14:29: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 065F61071D36 for ; Sun, 12 Aug 2018 14:29:56 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.de (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 9D2278A5BC; Sun, 12 Aug 2018 14:29:54 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.de (Postfix) with ESMTPSA id 28E546B; Sun, 12 Aug 2018 16:29:53 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 1A0151350F91D; Sun, 12 Aug 2018 11:29:48 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: BeagleBone Black with a I2C Digital Analog Converter From: "Dr. Rolf Jansen" In-Reply-To: <1534081680.31375.25.camel@freebsd.org> Date: Sun, 12 Aug 2018 11:29:47 -0300 Cc: freebsd-arm@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <2099FA0C-96FC-4905-9B39-EAAB48EA3A77@obsigna.com> References: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> <1533743140.9860.99.camel@freebsd.org> <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com> <1534020139.31375.16.camel@freebsd.org> <74831EA5-1BBD-442A-BD24-6DE1FDBBD575@obsigna.com> <1534081680.31375.25.camel@freebsd.org> To: Ian Lepore 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: Sun, 12 Aug 2018 14:29:56 -0000 > Am 12.08.2018 um 10:48 schrieb Ian Lepore : >=20 > On Sun, 2018-08-12 at 01:01 -0300, Dr. Rolf Jansen wrote: >>=20 >> BTW: The startup script /etc/rc.d/ntpd got a flaw. The -p option must >> be removed from the cmdargs. >=20 > No, you must not set that flag in ntpd_flags in your rc.conf. Also, = you > must run mergemaster or otherwise arrange to update > /etc/defaults/rc.conf so that it gets the new (empty) default value = for > ntpd_flags. Thank you very much, for looking into this. The problem was really on my = side. In order to facilitate tracking 12-CURRENT, I exclude some files in the = course of the upgrade procedure in /etc from being replaced, principally = /etc/rc.conf. Now I see, that said exclude mechanism collaterally = prevented upgrading /etc/defaults/rc.conf as well, which actually was = not intended. I replaced the old /etc/defaults/rc.conf with the latest = one, and ntpd starts fine now. I corrected the mechanism as well. Please excuse my ignorance. Best regards Rolf= From owner-freebsd-arm@freebsd.org Sun Aug 12 15:07: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 50F121073417 for ; Sun, 12 Aug 2018 15:07:38 +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 9B6BF8BE76; Sun, 12 Aug 2018 15:07:37 +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 w7CF7ZeK032931; Sun, 12 Aug 2018 08:07:35 -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 w7CF7YNN032930; Sun, 12 Aug 2018 08:07:34 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201808121507.w7CF7YNN032930@pdx.rh.CN85.dnsmgr.net> Subject: Re: BeagleBone Black with a I2C Digital Analog Converter In-Reply-To: <1534081680.31375.25.camel@freebsd.org> To: Ian Lepore Date: Sun, 12 Aug 2018 08:07:34 -0700 (PDT) CC: "Dr. Rolf Jansen" , 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: Sun, 12 Aug 2018 15:07:38 -0000 > On Sun, 2018-08-12 at 01:01 -0300, Dr. Rolf Jansen wrote: > > > > BTW: The startup script /etc/rc.d/ntpd got a flaw. The -p option must > > be removed from the cmdargs. > > No, you must not set that flag in ntpd_flags in your rc.conf. That is bad design, a user should be able to over ride any flags of any command that we run from /etc/rc.d scripts. The -p option should be in the /etc/defaults/rc.conf ntpd_flags="" string, and the hard coded -p ripped out, as this submission does, from the /etc/rc.d/ntpd script. > Also, you > must run mergemaster or otherwise arrange to update > /etc/defaults/rc.conf so that it gets the new (empty) default value for > ntpd_flags. > > -- Ian > > _______________________________________________ > 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" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Sun Aug 12 15:11: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 CE27210734F3 for ; Sun, 12 Aug 2018 15:11:42 +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 6545A8C13C for ; Sun, 12 Aug 2018 15:11:42 +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 B3DC41FB55 for ; Sun, 12 Aug 2018 15:11:41 +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 w7CFBf2E099715 for ; Sun, 12 Aug 2018 15:11:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7CFBf3g099707 for freebsd-arm@FreeBSD.org; Sun, 12 Aug 2018 15:11:41 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 230561] ntpd error: only one pidfile option allowed Date: Sun, 12 Aug 2018 15:11:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rgrimes@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution assigned_to bug_severity Message-ID: In-Reply-To: References: 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: Sun, 12 Aug 2018 15:11:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230561 Rodney W. Grimes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Closed |Open CC| |re@FreeBSD.org, | |rgrimes@FreeBSD.org Resolution|Not A Bug |--- Assignee|freebsd-arm@FreeBSD.org |bugs@FreeBSD.org Severity|Affects Only Me |Affects Some People --- Comment #2 from Rodney W. Grimes --- This is a regression, in prior versions of FreeBSD you could specify and override the -p option that came from /etc/defaults/rc.conf. This new /etc/rc.d/ntpd scripts does not allow that. This is force set policy which FreeBSD should not be doing. I am unclear why these user configurable defaults have been hard coded, but= it is bad design. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sun Aug 12 16:27: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 620951075ABC for ; Sun, 12 Aug 2018 16:27:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 CD4198EDD4 for ; Sun, 12 Aug 2018 16:27:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id d16-v6so9337796itj.0 for ; Sun, 12 Aug 2018 09:27:24 -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=8ZyWNFaDJVm/oO+ALW4I9ZKnhZnrwPNS+YL6Pqrjiz0=; b=jpG7A/Dtp0K6JvdfSvY2vJfDC59KkZiji12pcibIaVt+BAmkQ7niPvLX4J+eY0rEfm 63CCGkdudPfvMjWpsyITILefkoLi6tVjmxkGDGShhWCsI15fvC8WMKhZjIEhiNPYDtf1 R2KpcG4u8i80R7yAeZzUGPO8ipNM3kwo1dddHGvuhTo/uGaJWFSyZ0PNuLuMOGyFk+G5 8ts+VUZjcVZq6SnuV1LAvaJn0KV2uJgjqN5ikcsvPp1OxKkUs5OPRK60fo651RFIs8F/ /ZaYBbkCK3rjWGN2h/gZg4gArKqEqvme/ZOw1Nnl6jcSVTiQLYqxbLgRv9DujsmTWxd5 +C0A== 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=8ZyWNFaDJVm/oO+ALW4I9ZKnhZnrwPNS+YL6Pqrjiz0=; b=qd571XGf+8HyzDHFezMPSvW65rndJ2Cg0K8+eBg569lvUolV9wSW5cGJTLtwyFJMhJ iGfXFyX+hQCuZf3KSLfIfBsR7kmOOWb78Ax4aRuDJSEsrGTXkvPpTUIPwXPUB1505eZR cFrnUvUQ49ukKxjxcQxe/zKvJ2oC4S/CCeC6IEpHCU7fffCfppZifonu9+L1VPPyRYOo mdpv49IUQ8Ln4xMHaA4J1MfzizTG+RvZ61COjDRhQSTl9UZtvcQDBO4xEl6CCQ6Ql+Lz OUsrxd73NyA0DQSbBuKs/R3o8LnTp7OEKiMLhgTBP64doGJxwheX6Xz27BCmNFq4nYIR 0Fuw== X-Gm-Message-State: AOUpUlEtKHVFEOT/NlNCWlwV7/cbWYM3rE9wjGeGckFu327xs8c2Sei/ zN4Z1EUFdHhghxZ3wLdgAclaAXhEsTO6M3jsLy3CiQ== X-Google-Smtp-Source: AA+uWPwBqsemklSJd544NhOPm6q6HQ74i/1Z3z07O2nbnaT5bQxp4DRtw5kuV1flfkijtvx1VxywCIYZTbHBfnfQ46g= X-Received: by 2002:a02:3344:: with SMTP id k4-v6mr12760079jak.45.1534091243876; Sun, 12 Aug 2018 09:27:23 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Sun, 12 Aug 2018 09:27:23 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <197535.81645.qm@web103907.mail.ssk.yahoo.co.jp> References: <64850.63077.qm@web101706.mail.ssk.yahoo.co.jp> <387823.67007.qm@web101711.mail.ssk.yahoo.co.jp> <812183.70978.qm@web101705.mail.ssk.yahoo.co.jp> <892631.23713.qm@web101718.mail.ssk.yahoo.co.jp> <408.23467.qm@web101707.mail.ssk.yahoo.co.jp> <920419.9428.qm@web103910.mail.ssk.yahoo.co.jp> <197535.81645.qm@web103907.mail.ssk.yahoo.co.jp> From: Warner Losh Date: Sun, 12 Aug 2018 10:27:23 -0600 X-Google-Sender-Auth: 0MVbEUPdas0OD3Q8HdTq_le6ZaU Message-ID: Subject: Re: solved Re: still hang up arm/ralink To: Mori Hiroki Cc: Michael Zhilin , "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: Sun, 12 Aug 2018 16:27:25 -0000 On Sat, Aug 11, 2018 at 11:07 PM, Mori Hiroki wrote: > Hi > > Sorry I lost your mail. Because of arm ML is so many mail more than mips. > > ----- Original Message ----- > >From: Warner Losh > >To: Mori Hiroki > >Cc: Michael Zhilin ; "freebsd-arm@freebsd.org" < > freebsd-arm@freebsd.org> > >Date: 2018/8/12, Sun 04:14 > >Subject: Re: solved Re: still hang up arm/ralink > > > > > > > > > > > > > >On Sat, Aug 11, 2018 at 9:25 AM, Warner Losh wrote: > > > > > >> > >> > >> > >>On Thu, Aug 9, 2018 at 11:52 PM, Mori Hiroki > wrote: > >> > >>Hi. > >>> > >>>----- Original Message ----- > >>>>From: Warner Losh > >>>>To: Mori Hiroki > >>>>Cc: Michael Zhilin ; "freebsd-arm@freebsd.org" < > freebsd-arm@freebsd.org> > >>>>Date: 2018/8/10, Fri 11:16 > >>>>Subject: Re: solved Re: still hang up arm/ralink > >>>> > >>>> > >>>>Mori-san > >>>> > >>>> > >>>>I took your advice and bought a Buffalo WZR2-G300N off ebay. It > arrived while I was on vacation. So, I spent a few minutes with it today. > I've installed header for serial port, puzzled out the pins, found your > blog that had the pins and the piece I was missing (the baud rate). I now > have added it to my test lab's terminal server and hope to start building > images for it once I get my test lab's CI infrastructure up and running. > >>>> > >>> > >>>Thanks for your cooperation. > >>> > >>>> > >>>>So, now I'm sitting at the "RT2860-EVB#" prompt from uboot hoping to > boot the RT1310 kernel. However, I lack instructions and can't seem to find > all the details in your posts or on your blog. How do I load/create the RAM > disk referenced in the kernel config file "options > ROOTDEVNAME=\"cd9660:/dev/cfi d0s.rootfs.uzip\"" ? what address do I load > the kernel at (0x40800000 is listed in a diagram, but 0x40000100 is shown > in the dmesg) and which variation of the kernel should I use? Thanks for > any help you can offer. > >>>> > >>> > >>>I use ZRouter build system. But I am a suggestion normal build system. > >>> > >>>I think Buffalo WZR2-G300N is different u-boot on US and Japan model. > >>>Because of my target prompt is "5VT1310-EVB#". Be careful operation. > >>>You can find some information in printenv at u-boot. > >>> > >>>Sorry I forget memory address setting in build system. I add this to > review. > >>> > >>>https://reviews.freebsd.org/D1 6622 > >>> > >>>In this setting build kernel header is this. > >>> > >>>% readelf -h Buffalo_WZR2-G300N_kernel > >>>ELF Header: > >>> Magic: 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 > >>> Class: ELF32 > >>> Data: 2's complement, little endian > >>> Version: 1 (current) > >>> OS/ABI: UNIX - FreeBSD > >>> ABI Version: 0 > >>> Type: EXEC (Executable file) > >>> Machine: ARM > >>> Version: 0x1 > >>> Entry point address: 0xc0000100 > >>> Start of program headers: 52 (bytes into file) > >>> Start of section headers: 3633180 (bytes into file) > >>> Flags: 0x5000202, has entry point, > Version5 EABI, > >>> Size of this header: 52 (bytes) > >>> Size of program headers: 32 (bytes) > >>> Number of program headers: 6 > >>> Size of section headers: 40 (bytes) > >>> Number of section headers: 37 > >>> Section header string table index: 34 > >>> > >>>Do opjcopy and compress and make u-boot image by load and entry address > is 0x40000100. > >>> > >>>% file Buffalo_WZR2-G300N_kernel.kbin .oldlzma.uboot > >>> > >>>Buffalo_WZR2-G300N_kernel.kbin .oldlzma.uboot: u-boot legacy uImage, > FreeBSD Kernel Image, Linux/ARM, OS Kernel Image (lzma), 999004 bytes, Wed > Aug 8 22:50:36 2018, Load Address: 0x40000100, Entry Point: 0x40000100, > Header CRC: 0xFEC4D6B9, Data CRC: 0xE650EDDF > >>> > >>>It can execute on memory. (not flash) > >>>You need set ipaddr and serverip on u-boot. > >>> > >>>5VT1310-EVB# tftpboot 00800000 Buffalo_WZR2-G300N_kernel.kbin > .oldlzma.uboot > >>>TFTP from server 10.10.10.3; our IP address is 10.10.10.190 > >>>Filename 'Buffalo_WZR2-G300N_kernel.kbi n.oldlzma.uboot'. > >>>Load address: 0x800000 > >>>Loading: ############################## ############################## > ##### > >>>############################## ############################## ##### > >>>############################## ############################## ##### > >>># > >>>done > >>>Bytes transferred = 999068 (f3e9c hex) > >>>5VT1310-EVB# bootm > >>>## Booting image at 00800000 ... > >>> Image Name: FreeBSD Kernel Image > >>> Image Type: ARM Linux Kernel Image (lzma compressed) > >>> Data Size: 999004 Bytes = 975.6 kB > >>> Load Address: 40000100 > >>> Entry Point: 40000100 > >>> Verifying Checksum ... OK > >>> Uncompressing LZMA Kernel Image .............................. > ............OK > >>> > >>>Starting kernel @40000100... > >>> > >>>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. > >>> > >>>If you can execute kernel then stop at rootfs mount. > >>> > >>>I think this is first step. > >>> > >> > >> > >>Where do I find oldlzma utility? The current one produces an unbootable > image: > >> > >> > >>% objcopy -S -O binary kernel kernel.kbin > >>% lzma kernel.kbin > >>% mkimage -A arm -O FreeBSD -T kernel -C lzma -a 0x40000100 -e > 0x40000100 -n rt1310 -d kernel.kbin.lzma kernel.kbin.lzma.u-boot > >>Image Name: rt1310 > >>Created: Sat Aug 11 09:06:27 2018 > >>Image Type: ARM FreeBSD Kernel Image (lzma compressed) > >>Data Size: 1317305 Bytes = 1286.43 KiB = 1.26 MiBLoad Address: > 40000100 > >>Entry Point: 40000100 > >>% scp kernel.kbin.lzma.u-boot tftp:tftpboot > >>... > >>RT2860-EVB# bootm## Booting image at 00800000 ... > >> Image Name: rt1310 > >> Image Type: ARM Unknown OS Kernel Image (lzma compressed) > >> Data Size: 1317305 Bytes = 1.3 MB Load Address: 40000100 > >> Entry Point: 40000100 > >> Verifying Checksum ... OK > >> Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to > recover > >>OK > >> > >> > >>I see you have 'oldlzma' and online instructions use an oldlzma > command... > > > > > >I built oldlzma from zrouter and have the same results... > > > > > >Warner > > You need make small rootfs because of this target flash is too small. > ZRouter is make cd9660 rootfs image by limited files and uzip. > And 64Kbyte synced kernel image append rootfs uzip. > > +-------------------+------+-----------+ > |u-boot kernel image|synced|rootfs uzip| > +-------------------+------+-----------+ > > This is complete image. > > Also you need fixed rootfs address in dts. > > sys/dts/arm/wzr2-g300n.dts > > This is flash u-boot command. > > 5VT1310-EVB# tftpboot 0x00800000 Buffalo_WZR2-G300N.zimage > > 5VT1310-EVB# erase 0x1F010000 0x1F3CFFFF > > 5VT1310-EVB# cp.b 0x00800000 0x1F010000 $(filesize) > > 5VT1310-EVB# reset > Do I need it to successfully uncompress the kernel? So far I can't get a kernel to uncompress w/o the LZMA ERROR 1 message. I have no doubt I'll need it eventually, but right now I can't even get the kernel to start.... Warner > I make auto scan rootfs partition patch at geom_flashmap. > > https://reviews.freebsd.org/D13648 > > This patch scan rootfs in named firmware partition. > > I have many time stop at mountroot. This patch is solution this. > > Regards > > Hiroki Mori > > > > >Warner > >> > >>Thanks > >>> > >>>Hiroki Mori > >>> > >>> > >>>> > >>>>Warner > >>>> > >>>> > >>>>On Sat, Mar 10, 2018 at 2:31 AM, Mori Hiroki > wrote: > >>>> > >>>>Hi > >>>>> > >>>>>I do try to todays current. It' work find on RT1310. > >>>>> > >>>>>https://gist.github.com/ yamori813/ 88224f1c96c9c592fb611b12a15e4a b5 > >>>>> > >>>>> > >>>>>Thanks > >>>>> > >>>>>Hiroki Mori > >>>>>____________________________ __ _________________ > >>>>>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 Aug 12 17:15:31 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 85DB21076BCE for ; Sun, 12 Aug 2018 17:15:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-9.consmr.mail.gq1.yahoo.com (sonic307-9.consmr.mail.gq1.yahoo.com [98.137.64.33]) (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 F1BE070AA7 for ; Sun, 12 Aug 2018 17:15:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: gOr84X4VM1k6lDzKO94jPrtCrSUncgscEFyfF6edQ9kdhf0i8o4lMOMVIYLgngQ aWW6xD2cElSRC6rsqMeXnKuCfbFIEKhw0LpGf8tDgkErMYmxxB716L7SXZNXTnfUdEzMsC0tBvAG V70rJz6ZhxlYLoEdU0THv_C2h6zDW_KYxynfYknsHWiyOQCYcaExrVHL100H2ne9ZPzl2ez3ULEG Klr3obgKvwqGyYcxJjs1yi_BninlMXPfcu_2q9KenohkUYEmCsS35iiP82YSu88PWkAyNE4CiV5W uxv8_YDvZKPw4tTYIevDPIjpf6qchmdf1NWUw4ugb4Jyp6TNYO6iSf1YsahzhsCL1maqHK6PC0j0 HMsBOK7Oc4sJL64l5k7orMNKzlQAQoM__lyG1xWekRiYJSODK.Fi.ISGlkrJ.vbbIyuBLWoB.nHS NGBX8vxm6JSFji6s3KgCl0l00vc3R5jb_hdK.UXCOit8K5huNV.U_46b3GGcB0u4TKZU2KJkqIdI JonW56o6YxbEJQIlvnB8gwNogEoyhXEu_FyAfH.RKJ6qyHbc7mohYknkGblDMM9rGJBZNzR3yaxl PNCuD7YWygH7roSJkfE4snqbYIOVHzte0rvo4uePV8m4DAeHsk_9HQ2CyOksWnFdc3CrEEjReEwo VLYE8w1mPEZ6_cgfHm88YJeWbUzbHW_BkJCufG6Xz8VQH_OJXDa_MKONFxQ7xdOXqs_kWoV5NKz_ eZqOuEP4HWnzgWWIvZcC00BgPw4zPjnD24EEMsowJx2dxv2G0oV3YMIio_BiC5UzZhQW02Z7yV5M DdPgMTMyI5EKFVWMXuoc7fUaxDXjdcvLe0C5VBfOKn99peeCYwimqebI5Z4HLc9hb8rcbogtThpR HSIgJmJXvd8PGRcr5ZYTBRTU2zZZDbLW55sBmwZqAFIqSeX.X4hHpGJoCujiILuf9WQyShPvSN0f wo7qjbKXdyZ.k8KJMGnoUnKARK94y4_sK7viM4YKLLOqOn1IVhZfJ.yU83LqQOY2r5dk7aRK4gA_ sM6zatrLv3TzTqznUPIESGysD Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Aug 2018 17:15:24 +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 c4dbbba95c7daf1ca19611335d7b457d; Sun, 12 Aug 2018 17:15: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: RPI3 swap experiments [a failure for a Pine64+ 2GB at head -r337400 without vm.pageout_oom_seq or #define adjustment, no I/O latency problem reported] From: Mark Millard In-Reply-To: <64798536-4ba5-24e9-304b-30cfb5b702d0@sentry.org> Date: Sun, 12 Aug 2018 10:15:18 -0700 Cc: Trev , bob prohaska , John Kennedy , Jamie Landeg-Jones , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> <20180809153710.GC30347@www.zefox.net> <20180810044426.GB32974@www.zefox.net> <20180811163209.GA38922@www.zefox.net> <64798536-4ba5-24e9-304b-30cfb5b702d0@sentry.org> To: Mark Johnston , Warner Losh 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: Sun, 12 Aug 2018 17:15:31 -0000 Based on having all Mark Johnston's reporting-patches but not adjusting vm.pageout_oom_seq or the #define I got an OOM kill during buildworld on a Pine64+ 2GB (so 2 GiByte of RAM). I'll give other environment characteristic later. But that no I/O latency problems were reported by the patches is not a surprise: the device with the root file system and swap partition has not historically shown latency problems and is not of a type usually used with such a system (better than normal). I expect that this case shows that the problem does not require I/O latency problems to be involved. The only console message was: Aug 12 09:30:13 pine64 kernel: v_free_count: 7773, v_inactive_count: 1 Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: out = of swap space The build had been started at: 01:44:59 so the failure was around 7 hours 45 minutes into the build. The build log shows: Building = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/lib= clang/Sema/SemaDeclAttr.o Building = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/lib= clang/Sema/SemaDeclCXX.o Building = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/lib= clang/Sema/SemaDeclObjC.o --- Sema/SemaDecl.o --- c++: error: unable to execute command: Killed 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/SemaDecl-44b104.cpp c++: note: diagnostic msg: /tmp/SemaDecl-44b104.sh c++: note: diagnostic msg:=20 ******************** *** [Sema/SemaDecl.o] Error code 254 Description of the context . . . I have access to a Pine64+ 2GB (that was updated to -r337400 via a cross build) and had it doing a self-hosted rebuild of -r337400 via -j4. (This was a jump from its last update over 10 months ago. I've not historically had OOM kill problems.) The root file system is on a USB3.0-capable 240 GB SSD plugged in the lower slot, where it gets the 480Mbps USB 2.0 classification. The kernel was loaded from a microSDHC card that also supplied a /etc/fstab that redirects to the USB root file system. (With an edit of that /etc/fstab the microSDHC can boot standalone: I keep it tracking.) # usbconfig ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH= (480Mbps) pwr=3DSAVE (0mA) ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL = (12Mbps) pwr=3DSAVE (0mA) ugen0.2: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH = (480Mbps) pwr=3DON (0mA) Historically I've not observed latency problems for the USB SSD. None were reported by Mark Johnston's reporting patches, unlike for Bob P.'s context. In top I'd seem over 1400 Mem Active, well over the amount of RAM in a rpi3 or rpi2. (Of course with more memory the relative timings of what is running will be different from what rpi3's/rpi2's get. That is not the only source of variation.) Swap had been used, I've seen 19M Used shown (of 3 GiByte in the swap partition in use). (I do not have in place my prior changes to record and report the maximum observed swap used: I reverted to the normal version of top during top's development activity.) I'm unlikely to have observed approximate the maximums for Mem Active or Swap Used. These are things I wish there were normally available for inspection from FreeBSD. I did not have a parallel loop showing gstat output or other such, relying on Mark Johnston's patches for reporting any that are a problem for the subsystem(s) involved. (It is also less I/O to not be running the extra logs.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Aug 12 17:34:13 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 BB46A10775F7 for ; Sun, 12 Aug 2018 17:34:13 +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 383A472041 for ; Sun, 12 Aug 2018 17:34:12 +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 w7CHWmIT005945 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Aug 2018 10:32:48 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w7CHWmxE005944; Sun, 12 Aug 2018 10:32:48 -0700 (PDT) (envelope-from warlock) Date: Sun, 12 Aug 2018 10:32:48 -0700 From: John Kennedy To: bob prohaska Cc: freebsd-arm Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180812173248.GA81324@phouka1.phouka.net> References: <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180809175802.GA32974@www.zefox.net> 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: Sun, 12 Aug 2018 17:34:14 -0000 On Thu, Aug 09, 2018 at 10:58:02AM -0700, bob prohaska wrote: > ... I've gathered up what I've been given and put it in > http://www.zefox.net/~fbsd/rpi3/swaptests/tools/ > in hopes it'll be useful. ... Bob, are you doing anything clever to track/graph resources over time? I've got my box patched up to 12.0-ALPHA1 (r337589+2a27f5c34b07) + patches, and haven't seen any logged output (assuming it'll end up in /var/log/messages) although I'm certainly exercising things. I typically beat things up with a buildworld-then-buildkernel. Patches I've applied: http://www.zefox.net/~fbsd/rpi3/swaptests/tools/pageout.patch http://www.zefox.net/~fbsd/rpi3/swaptests/tools/slow_swap.patch I haven't used the CAM_IOSCHED_DYNAMIC option or adjusted vm.pageout_oom_seq. Just using top isn't really going to help me go back in time and diagnose it after the fact and capturing it's output (and all the screen codes) over an extended period of time seems pretty ugly. I can see why my ntpd tends to get whacked. At ~18M, it's almost always in the top 5 of memory-using processes. Load seems lower than it normally does (~4 for a -j4) and it seems a bit more swappy than I remember it being (r337443). I added a vfs.zfs.arc_max="450M" to /boot/loader.conf, but it didn't seen to be anywhere near that originally and doesn't seem to have taken effect: [sysctl vfs.zfs.arc_max] vfs.zfs.arc_max: 195873280 AFAIK, that would take up more "wired" space, but wired is only ~197M and ARC claims to only be ~50M so ZFS doesn't see to be too piggy. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [top -IatP -o res] last pid: 75860; load averages: 1.38, 1.72, 1.95 up 0+13:42:25 10:04:05 65 processes: 65 sleeping CPU 0: 1.6% user, 0.0% nice, 5.1% system, 13.7% interrupt, 79.7% idle CPU 1: 6.6% user, 0.0% nice, 9.0% system, 0.0% interrupt, 84.4% idle CPU 2: 2.7% user, 0.0% nice, 9.0% system, 2.7% interrupt, 85.5% idle CPU 3: 16.0% user, 0.0% nice, 7.0% system, 0.4% interrupt, 76.6% idle Mem: 596M Active, 31M Inact, 51M Laundry, 197M Wired, 32K Buf, 19M Free ARC: 50M Total, 14M MFU, 16M MRU, 2758K Anon, 558K Header, 17M Other 6757K Compressed, 26M Uncompressed, 3.99:1 Ratio Swap: 3584M Total, 820M Used, 2764M Free, 22% Inuse, 3736K In, 5568K Out PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 75841 root 1 35 0 373M 55M swread 2 2:27 14.35% /usr/bin/c++ -cc1 -triple aarch64-unknown- 75844 root 1 39 0 423M 46M swread 3 2:45 21.76% /usr/bin/c++ -cc1 -triple aarch64-unknown- 821 ntpd 1 20 0 18M 18M select 3 0:16 0.02% /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c 75811 root 1 22 0 346M 14M swread 1 2:41 2.05% /usr/bin/c++ -cc1 -triple aarch64-unknown- 75815 root 1 21 0 389M 7252K swread 1 3:09 1.86% /usr/bin/c++ -cc1 -triple aarch64-unknown- 2308 warlock 1 20 0 14M 2748K select 2 7:30 0.78% top -IatP -o cpu 75749 warlock 1 20 0 14M 2744K select 2 0:18 0.79% top -IatP -o cpu 2515 root 1 20 0 11M 1828K kqread 0 0:27 0.06% tail -F /var/log/messages 930 warlock 1 20 0 20M 1460K select 2 16:36 0.07% sshd: warlock@pts/0 (sshd) 935 warlock 1 20 0 19M 1288K select 3 46:14 0.38% screen From owner-freebsd-arm@freebsd.org Sun Aug 12 17:55: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 6C5661078568 for ; Sun, 12 Aug 2018 17:55:49 +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 EBFDF73BB2 for ; Sun, 12 Aug 2018 17:55:48 +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 w7CHsVCt005997 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Aug 2018 10:54:31 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w7CHsVjP005996; Sun, 12 Aug 2018 10:54:31 -0700 (PDT) (envelope-from warlock) Date: Sun, 12 Aug 2018 10:54:31 -0700 From: John Kennedy To: bob prohaska Cc: freebsd-arm Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180812175431.GB81324@phouka1.phouka.net> References: <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180812173248.GA81324@phouka1.phouka.net> 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: Sun, 12 Aug 2018 17:55:49 -0000 On Sun, Aug 12, 2018 at 10:32:48AM -0700, John Kennedy wrote: > ... Bob, are you doing anything clever to track/graph resources over time? > ... Load seems lower than it normally does (~4 > for a -j4) and it seems a > bit more swappy than I remember it being (r337443). ... Clever, *lightweight* tracking. Looking at what is actively resident and the size of some of my monitoring tools, chopping out some monitoring (even at ~20M a pop) makes the system much more productive. A "watched pot never boils" type of situation. From owner-freebsd-arm@freebsd.org Sun Aug 12 18:10: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 93A431078A09 for ; Sun, 12 Aug 2018 18:10:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (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 2B68074106 for ; Sun, 12 Aug 2018 18:10:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: mA6aPOUVM1lZjEv1xx.s69v03ynkzBD29QRnlTz_XGlmpvv6ZoLB1uR3AOpx8ft ScINetOCThH8l91Or2YNWWiEckczKcoJuRpUBf7ehHdOoFPjkhDs0kx0EJXv7DHHpKEn7PVNelhK _KSZFYV5e2lBW3Eu2IftH0Io8Dl080kyvZbWdB6nre480cU8D1PXCdeQylzkj7eW9KvwlxjO4xaS sho0VYpFoH6Wpf1wCUpVGVOFb1lFpbDnIo4mrHF6UDcWLSmEPYEDqphOlvFhkmwy8WSespAcvgVb .GesGLXke2JAmbTGr2.6pn5ZENQeawmaSKM5lI0o3onJJkpwsXrcMUEy9WjWWE2Nyrrn5uJCBjHJ hNDvw8xWGG0IUKQdSbI5BBMpbeeqZzY_rmZhpHFEXkyckpPazJSjgfDqaw3GrRkFd_du8I6rLeIa itRMa8WDJM3SwGX.BxoHh7IFlfkeYERlTxhJh9G47Qs821La0lWNe85k7J2Hypj5VWWcAIw0E6vW cjzjc97xQEqXamAz02nOEqg4_DFGNbX_xYuYkmRJBHNzoYDEOs35azIBfHU7OXpfysss88j9XLxH .iDvUqXjYhy6eEFC2WDNSta8LFf1fko1Qw7IN_zBXE8AN5RlqlanK9mA2KtIdnENvBF8YpcdcQXo RwBVGmBcFgiW5cda5MnWdIQ5.y7ZMR_V7yf8I4aDzhJkpHOT_TLtZjoCJvzDE.vTyiQ7.v0zARBD 04A3BnVqxkn0gckJvYdvUF_tb6iLMtjVgB.0J2GpkbbOM_iSflg0YrIVA6VxFF1B0aQ7UoqD4l_N twUUYLkwihRIUF6i9UqRS8sEIMPuiF.d1I9ExMZU40dtZ5uNiAPnStEdkeaCS33RRqJMXTcRJOWZ BeyumwqLRkDlx7Q_t6kUmWW3uRVKtEwapEj6gwjrLOGNo702xSEoeHpYiSaWr81cooiMyNABztqP AE8nuQV0bXGI._JLqOq2pU_qWHzC.vojZ9P8F1vnySzMnPN3JiYW7wXLSHH6018c7mKZ3UWqKhM9 s.IvFdtMhDXRLfW0ddggPp2uUeQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Sun, 12 Aug 2018 18:10:01 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 793bb8f2e0a27775956cfc8c533bbc7d; Sun, 12 Aug 2018 17:59: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 [a failure for a Pine64+ 2GB at head -r337400 without vm.pageout_oom_seq or #define adjustment, no I/O latency problem reported] From: Mark Millard In-Reply-To: Date: Sun, 12 Aug 2018 10:59:48 -0700 Cc: Trev , bob prohaska , John Kennedy , Jamie Landeg-Jones , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <507FC6E0-6EDB-4A0D-A9A6-DD03B50A1DA3@yahoo.com> References: <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> <20180809153710.GC30347@www.zefox.net> <20180810044426.GB32974@www.zefox.net> <20180811163209.GA38922@www.zefox.net> <64798536-4ba5-24e9-304b-30cfb5b702d0@sentry.org> To: Mark Johnston , Warner Losh 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: Sun, 12 Aug 2018 18:10:08 -0000 [Quick top post: Possibly related bugzilla's for this area are: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227609 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230402 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230454 .] On 2018-Aug-12, at 10:15 AM, Mark Millard wrote: > Based on having all Mark Johnston's reporting-patches but > not adjusting vm.pageout_oom_seq or the #define I got > an OOM kill during buildworld on a Pine64+ 2GB (so 2 GiByte > of RAM). >=20 > I'll give other environment characteristic later. > But that no I/O latency problems were reported by the > patches is not a surprise: the device with the root file > system and swap partition has not historically shown > latency problems and is not of a type usually used with > such a system (better than normal). >=20 > I expect that this case shows that the problem does not > require I/O latency problems to be involved. >=20 > The only console message was: >=20 > Aug 12 09:30:13 pine64 kernel: v_free_count: 7773, v_inactive_count: 1 > Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: out = of swap space >=20 > The build had been started at: 01:44:59 so the failure > was around 7 hours 45 minutes into the build. >=20 > The build log shows: >=20 > Building = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/lib= clang/Sema/SemaDeclAttr.o > Building = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/lib= clang/Sema/SemaDeclCXX.o > Building = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/lib= clang/Sema/SemaDeclObjC.o > --- Sema/SemaDecl.o --- > c++: error: unable to execute command: Killed > 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 > ******************** >=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/SemaDecl-44b104.cpp > c++: note: diagnostic msg: /tmp/SemaDecl-44b104.sh > c++: note: diagnostic msg:=20 >=20 > ******************** > *** [Sema/SemaDecl.o] Error code 254 >=20 >=20 > Description of the context . . . >=20 > I have access to a Pine64+ 2GB (that was updated to -r337400 > via a cross build) and had it doing a self-hosted rebuild of > -r337400 via -j4. (This was a jump from its last update over > 10 months ago. I've not historically had OOM kill problems.) >=20 > The root file system is on a USB3.0-capable 240 GB SSD > plugged in the lower slot, where it gets the 480Mbps > USB 2.0 classification. The kernel was loaded from a > microSDHC card that also supplied a /etc/fstab that > redirects to the USB root file system. >=20 > (With an edit of that /etc/fstab the microSDHC can boot > standalone: I keep it tracking.) >=20 > # usbconfig > ugen0.1: at usbus0, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DSAVE (0mA) > ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL= (12Mbps) pwr=3DSAVE (0mA) > ugen0.2: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH = (480Mbps) pwr=3DON (0mA) >=20 > Historically I've not observed latency problems for > the USB SSD. None were reported by Mark Johnston's > reporting patches, unlike for Bob P.'s context. >=20 > In top I'd seem over 1400 Mem Active, well over the amount > of RAM in a rpi3 or rpi2. (Of course with more memory the > relative timings of what is running will be different > from what rpi3's/rpi2's get. That is not the only source of > variation.) >=20 > Swap had been used, I've seen 19M Used shown (of 3 GiByte > in the swap partition in use). (I do not have in place my > prior changes to record and report the maximum observed > swap used: I reverted to the normal version of top during > top's development activity.) >=20 > I'm unlikely to have observed approximate the maximums for > Mem Active or Swap Used. These are things I wish there were > normally available for inspection from FreeBSD. >=20 > I did not have a parallel loop showing gstat output > or other such, relying on Mark Johnston's patches > for reporting any that are a problem for the subsystem(s) > involved. (It is also less I/O to not be running the > extra logs.) >=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 Sun Aug 12 22:40:14 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 882DC1055F53 for ; Sun, 12 Aug 2018 22:40:14 +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 E45EE7D535 for ; Sun, 12 Aug 2018 22:40:13 +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 w7CMeMIc046486 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Aug 2018 15:40:23 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7CMeMki046485; Sun, 12 Aug 2018 15:40:22 -0700 (PDT) (envelope-from fbsd) Date: Sun, 12 Aug 2018 15:40:21 -0700 From: bob prohaska To: John Kennedy Cc: freebsd-arm , fbssd@www.zefox.net Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180812224021.GA46372@www.zefox.net> References: <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180812173248.GA81324@phouka1.phouka.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: Sun, 12 Aug 2018 22:40:14 -0000 On Sun, Aug 12, 2018 at 10:32:48AM -0700, John Kennedy wrote: > On Thu, Aug 09, 2018 at 10:58:02AM -0700, bob prohaska wrote: > > ... I've gathered up what I've been given and put it in > > http://www.zefox.net/~fbsd/rpi3/swaptests/tools/ > > in hopes it'll be useful. ... > > Bob, are you doing anything clever to track/graph resources over time? > The closest thing to clever is the logging script, started by Mark M., containing now #!/bin/sh while true do gstat -abd -I 10s ; date ; swapinfo ; tail -n 2 /var/log/messages done Output goes to a file, and sort can we used to sift out values of interest, for example sort -n -u -k 5 swapscript.log > readdelay.sort will push the biggest ms/read values to the end of the file, where they can be examined. Things like total swap can be fished out in a similar way, with some cruft in the output. Then the values of interest can be located in the original file using a browser's find feature, to see them in context. Error messages can be found the same way, though the presistence of stale messages can clutter the view signficantly. Timestamps, if present, are usually a better way to match console errors to the log file. The script surely isn't "lightweight", but in my case the crashes came before the script and haven't changed much since it arrived. Still, you make a good point and I should do a test occasionally to see if the script contributes to the crashes. I don't think the script has ever been killed by OOMA. > I've got my box patched up to 12.0-ALPHA1 (r337589+2a27f5c34b07) + patches, and > haven't seen any logged output (assuming it'll end up in /var/log/messages) > although I'm certainly exercising things. I typically beat things up with > a buildworld-then-buildkernel. > > Patches I've applied: > http://www.zefox.net/~fbsd/rpi3/swaptests/tools/pageout.patch > http://www.zefox.net/~fbsd/rpi3/swaptests/tools/slow_swap.patch > > I haven't used the CAM_IOSCHED_DYNAMIC option or adjusted vm.pageout_oom_seq. > Setting vm.pageout_oom_seq to 120 made a decisive improvement, almost allowing buildworld to finish. By the time I tried CAM_IOSCHED_DYNAMIC buildworld was getting only about half as far, so it seems the patches were harmful to a degree. Changes were applied in the order pageout batchqueue slow_swap iosched My RPI3 is now updating to 337688 with no patches/config changes. I'll start the sequence over and would be grateful if anybody could suggest a better sequence. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sun Aug 12 23:23: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 D2F6C105972D for ; Sun, 12 Aug 2018 23:23:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-4.consmr.mail.bf2.yahoo.com (sonic303-4.consmr.mail.bf2.yahoo.com [74.6.131.43]) (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 5A19D7F542 for ; Sun, 12 Aug 2018 23:23:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: aFij67IVM1noXKJV_XrywKJxBwMuRR.eCixeNkaUp91DGaO1_ZZLfZUqbQIjwwm rD4VoUja2qMUHBI3HXYtbIMEc5FSBFV5KGaiSsOIHcub4MUqv7zEJuE.t0WAhnsiBJxIbIL_Fuy6 YECIO91MabTxUQnEmHuO7.JJymBzj_3N_H7tIOMkGK7Aj9Lp0GFK1lwFOn_538wban8kevoOZL3V gyDY4aGmaEkB3MCCbwjij58tmwbMJOCaxf215u26i4l5LAbuQZVcCgCsppFhuYOSHWcW.7OzdC1u JVH9ZQtyah_7cBTg99LZFWDThIpV5avRoeRMa3sN.spGQwTtZYoNwQPqkRmf39U.wKSaRhx6oq1o 2GTy85zP1mnHDrzFEV6.CDFGRaxapBYea4cJBBHaZiKIBo6bzjEYcG9wzQ7y2Bsz6ycCIpgBG7o5 fCMveap6jmhb.za1SCXEeskrGP240U4YdIYEWVAj9haQcwNxY6pZ0jBxO50CuUJxvxc9GISZ3RNA wdpfJDL6Rk9EB2EHIrBC2EkZavYM7W9hLfW.7n_cBjcmp0U5RrK2iybrQpa_ZcyqKMroHXPG9N_u Q0_3_TDRLSxRQW.vbl_fVasKZTiIsiE400WmV5KJNS5chWYm_dD75NUqOwQfmgzIgyPGhclNOLKm zxMdY88s1p.I0DnNWrC.IhdHlOSm40gP7Ch5I_yBFR.OOSJo1UZinbI5AgP.8deNwYgzNh_IH4ud A5.AeVPbaUfQA728GpBlyRw4qluFZpCsUQc1whRxd3ZDcYr8KIPyndcCyY.sxBgaIL6YNTMwT8Ft cFbcw2RHn_PrVZspVbtGK_HHwARz2yLau8qa38MXmWnDqlx6kfxR56tMm2rTCsWB531n4jk4sCga 7KwJeoDEcEwavpN0hFaxBHkWKzQEKpvPS.kY5ZOuH_.KRpoBU3HfMCWxUsdb8mqC9zGSvQHQdPcH 9vbiDDxwbeIt3Hs4_0T6w.ikA6icBtRALixNPdubdFFAEO2zc7ozujMb_jiUXq.LFY0RsjvTc.Oi lSA1xq94ZxXmZ90hvRLh8ug-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Sun, 12 Aug 2018 23:23:45 +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 215759bf1a45537ff59cbaf59bc7e6c5; Sun, 12 Aug 2018 23:23:40 +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: <20180812224021.GA46372@www.zefox.net> Date: Sun, 12 Aug 2018 16:23:31 -0700 Cc: John Kennedy , freebsd-arm , fbssd@www.zefox.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@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: Sun, 12 Aug 2018 23:23:52 -0000 On 2018-Aug-12, at 3:40 PM, bob prohaska wrote: > On Sun, Aug 12, 2018 at 10:32:48AM -0700, John Kennedy wrote: >> . . . > Setting vm.pageout_oom_seq to 120 made a decisive improvement, almost = allowing > buildworld to finish. By the time I tried CAM_IOSCHED_DYNAMIC = buildworld was > getting only about half as far, so it seems the patches were harmful = to a degree. > Changes were applied in the order=20 You could experiment with figures bigger than 120 for vm.pageout_oom_seq . I'll note that the creation of this mechanism seems to be shown for -r290920 at: = https://lists.freebsd.org/pipermail/svn-src-head/2015-November/078968.html= In part is says: . . . only raise OOM when pagedaemon is unable to produce a free page in several back-to-back passes. Track the failed passes per pagedaemon thread. =20 The number of passes to trigger OOM was selected empirically and tested both on small (32M-64M i386 VM) and large (32G amd64) configurations. If the specifics of the load require tuning, sysctl vm.pageout_oom_seq sets the number of back-to-back passes which must fail before OOM is raised. Each pass takes 1/2 of seconds. Less the value, more sensible the pagedaemon is to the page shortage. The code shows: int vmd_oom_seq and it looks like fairly large values would be tolerated. You may be able to scale beyond the problem showing up in your context. > pageout=20 > batchqueue > slow_swap > iosched For my new Pine64+ 2GB experiments I've only applied the Mark J. reporting patches, not the #define one. Nor have I involved CAM_IOSCHED_DYNAMIC. But with 2 GiBytes of RAM and the default 12 for vm.pageout_oom_seq I got: v_free_count: 7773, v_inactive_count: 1 Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: out = of swap space with no other reports from Mark Johnston's reporting patches. It appears that long I/O latencies as seen by the subsystem are not necessary to ending up with OOM kills, even if they can contribute when they occur. (7773 * 4 KiBytes =3D 31,838,298 Bytes, by the way.) > My RPI3 is now updating to 337688 with no patches/config changes. I'll = start the > sequence over and would be grateful if anybody could suggest a better = sequence. Side note: more text from -r290920 : In future, some heuristic to calculate the value of the tunable might be designed based on the system configuration and load. But before it can be done, the i/o system must be fixed to reliably time-out pagedaemon writes, even if waiting for the memory to proceed. Then, code can account for the in-flight page-outs and postpone OOM until all of them finished, which should reduce the need in tuning. Right now, ignoring the in-flight writes and the counter allows to break deadlocks due to write path doing sleepable memory allocations. I've no clue if this ever progressed after -r290920 . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Aug 13 02:12:12 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 178CE106207B for ; Mon, 13 Aug 2018 02:12:12 +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 8D9E1849AD; Mon, 13 Aug 2018 02:12:11 +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 w7D2CRmE047118 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Aug 2018 19:12:28 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7D2CQDn047117; Sun, 12 Aug 2018 19:12:26 -0700 (PDT) (envelope-from fbsd) Date: Sun, 12 Aug 2018 19:12:26 -0700 From: bob prohaska To: Mark Millard Cc: Mark Johnston , John Kennedy , freebsd-arm , bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180813021226.GA46750@www.zefox.net> References: <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@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: Mon, 13 Aug 2018 02:12:12 -0000 On Sun, Aug 12, 2018 at 04:23:31PM -0700, Mark Millard wrote: > On 2018-Aug-12, at 3:40 PM, bob prohaska wrote: > > > On Sun, Aug 12, 2018 at 10:32:48AM -0700, John Kennedy wrote: > >> . . . > > Setting vm.pageout_oom_seq to 120 made a decisive improvement, almost allowing > > buildworld to finish. By the time I tried CAM_IOSCHED_DYNAMIC buildworld was > > getting only about half as far, so it seems the patches were harmful to a degree. > > Changes were applied in the order > > You could experiment with figures bigger than 120 for > vm.pageout_oom_seq . > Could anybody hazard a guess as to how much? The leap from 12 to 120 rather startled me, I thought a factor of two a big adjustment. Maybe go to 240, or is that insignificant? > I'll note that the creation of this mechanism seems > to be shown for -r290920 at: > > https://lists.freebsd.org/pipermail/svn-src-head/2015-November/078968.html > > In part is says: > > . . . only raise OOM when pagedaemon is unable to produce a free > page in several back-to-back passes. Track the failed passes per > pagedaemon thread. > > The number of passes to trigger OOM was selected empirically and > tested both on small (32M-64M i386 VM) and large (32G amd64) > configurations. If the specifics of the load require tuning, sysctl > vm.pageout_oom_seq sets the number of back-to-back passes which must > fail before OOM is raised. Each pass takes 1/2 of seconds. Less the > value, more sensible the pagedaemon is to the page shortage. > > The code shows: > > int vmd_oom_seq > > and it looks like fairly large values would be > tolerated. You may be able to scale beyond > the problem showing up in your context. Would 1024 be enough to turn OOMA off completely? That's what I originally wanted to try. > > > pageout > > batchqueue > > slow_swap > > iosched > > For my new Pine64+ 2GB experiments I've only applied > the Mark J. reporting patches, not the #define one. > Nor have I involved CAM_IOSCHED_DYNAMIC. > > But with 2 GiBytes of RAM and the default 12 for > vm.pageout_oom_seq I got: > > v_free_count: 7773, v_inactive_count: 1 > Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: out of swap space > > with no other reports from Mark Johnston's reporting > patches. > > It appears that long I/O latencies as seen by the > subsystem are not necessary to ending up with OOM > kills, even if they can contribute when they occur. > It has seemed to me in the past that OOMA kills aren't closely-tied to busy swap. They do seem closely-related to busy storage (swap and disk). > (7773 * 4 KiBytes = 31,838,298 Bytes, by the way.) > The RPI3 seems to start adding to swap use when free memory drops below about 20 MB, Does that seem consistent with your observations? > > My RPI3 is now updating to 337688 with no patches/config changes. I'll start the > > sequence over and would be grateful if anybody could suggest a better sequence. > It seems rather clear that turning up vm.pageout_oom_seq is the first thing to try. The question is how much: 240 (double Mark J.'s number), 1024 (small for an int on a 64 bit machine)? If in fact the reporting patches do increase the load on the machine, is the slow swap patch the next thing to try, or the iosched option? Maybe something else altogether? There's no immediate expectation of fixing things; just to shed a little light. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Mon Aug 13 03:06: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 9153210633FE for ; Mon, 13 Aug 2018 03:06:24 +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 268E686241 for ; Mon, 13 Aug 2018 03:06:24 +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 w7D356GZ007115 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Aug 2018 20:05:06 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w7D356Fq007114; Sun, 12 Aug 2018 20:05:06 -0700 (PDT) (envelope-from warlock) Date: Sun, 12 Aug 2018 20:05:06 -0700 From: John Kennedy To: bob prohaska Cc: freebsd-arm Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180813030506.GC81324@phouka1.phouka.net> References: <20180802015135.GC99523@www.zefox.net> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180812224021.GA46372@www.zefox.net> 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: Mon, 13 Aug 2018 03:06:24 -0000 On Sun, Aug 12, 2018 at 03:40:21PM -0700, bob prohaska wrote: > The closest thing to clever is the logging script, started by Mark M., ... I was thinking more of the heavily distilled contents of top. > The script surely isn't "lightweight", but in my case the crashes came before the script > and haven't changed much since it arrived. Still, you make a good point and I should do > a test occasionally to see if the script contributes to the crashes. I don't think the > script has ever been killed by OOMA. I think we're probably chasing this the wrong way around. Going OOM is to be expected in some types of situations. I think we're mostly saying that the buildworld/buildkernel process shouldn't be one of those places, and for most of us (at least the verbal ones) it presumably isn't. Bob P has an interesting situation that triggers it when it arguably shouldn't, that perhaps reveals a problem. OOMing when swap is unresponsive? And then we need to decide what is reasonably responsive (with possibly a "tweak this tunable knob" note if you have some hardware that isn't tall enough to ride the rollercoaster. In my case, I didn't have my normal resources available, so I was basically watching it swap a lot more than run. If I was having issues and my swap wasn't fast enough (assuming swap-speed issue), that might be helpful and I should have left it as-is. To that end, I've applied the patches that tell me more about what was going on when things were going OOM, but not necessarily trying to avoid it. Once I can get things to fail reliably, figuring out to fix it reliably starts. So for my part, can I guarantee that some arbitrary process kicked off on my box during build*, used up all swap and kicked off an OOM massacre. The solution there is to not do it (or re-engineer it). The build* process seems like a pretty constant load, but I bet you that if you looked at it from the scheduler or swap, it isn't. For you, CAM_IOSCHED_DYNAMIC seems to hurt. That looks like it might tweak the number of read-vs-write traffic. They were worrying about SSDs, I can only imagine how much worse SD cards or USB2 devices much seem. I guess if you're cutting corners on price, you might fine-tune the suck that far down the line. Tuning vm.pageout_oom_seq increases the number of back-to-back passes the pagedaemon (?) makes while waiting for usable pages. That sounds like it lets us dig a deeper hole, which is fine as long as we can dig ourselves out of it. You might just be (un)lucky, which isn't reproduced reliably. (https://lists.freebsd.org/pipermail/svn-src-head/2015-November/078968.html) I'm not sure what Bob's ultimate problem is. My gut feeling is a slow disk, but I had the impression that he's tried similar hardware. I've got a RPI3B+ in a 77-degree-F room, a Sandisk Extreme Plus (V30-rated) SD card with the swap on it and a heatsink + pi-fan case-mod to keep my system cool. That would seem easy enough to reproduce. Counterfeit hardware? Bad sectors that cause unpredictable delays when they get wear-balanced over them? Dodgy hardware doing the same? Thermal throttle that gets him closer to some invisible performance dropoff? How do divide and conquer this problem? What can we do to split this problem in half so we can figure out which of the two halves has the problem (and then rinse-n-repeat). From owner-freebsd-arm@freebsd.org Mon Aug 13 04:02: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 EDDE41064A89 for ; Mon, 13 Aug 2018 04:02:53 +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 84547886DC for ; Mon, 13 Aug 2018 04:02:53 +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 w7D41aBk007245 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Aug 2018 21:01:36 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w7D41aTT007244; Sun, 12 Aug 2018 21:01:36 -0700 (PDT) (envelope-from warlock) Date: Sun, 12 Aug 2018 21:01:36 -0700 From: John Kennedy To: bob prohaska Cc: freebsd-arm Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180813040136.GD81324@phouka1.phouka.net> References: <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813030506.GC81324@phouka1.phouka.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180813030506.GC81324@phouka1.phouka.net> 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: Mon, 13 Aug 2018 04:02:54 -0000 On Sun, Aug 12, 2018 at 08:05:06PM -0700, John Kennedy wrote: > I was thinking more of the heavily distilled contents of top. Perhaps some version of this. Takes ~3M running, drops a timestamp in every minute. May have to tweak to make sure the disks you care about show up. while :; do date; vmstat -h -w5 -c20; don I don't know how to make the page free value make sense to me. The pages in/out seems Ok (not swapping much at that instant, ~1% used). The da0 disk is where /usr/src and /usr/obj are (swap on mm0). Sun Aug 12 20:41:35 PDT 2018 procs memory page disks faults cpu r b w avm fre flt re pi po fr sr mm0 da0 in sy cs us sy id 5 0 19 1.2G 271M 5424 90 61 82 2259 14109 0 0 17593 1647 8519 68 19 13 4 0 19 1.2G 271M 5699 0 1 1 3494 60 1 29 11869 4716 3046 63 37 0 4 0 19 1.1G 321M 6399 0 0 0 6484 46 0 30 12481 4959 2853 63 37 0 0 19 1.2G 296M 6742 0 2 1 3428 42 0 48 13397 5178 3230 62 37 1 4 0 19 1.2G 271M 4105 0 0 0 1577 53 0 28 14246 2513 2039 80 20 0 6 0 19 1.2G 268M 5834 0 3 1 3640 57 1 29 12392 4749 3256 62 38 0 6 0 19 1.2G 259M 6187 0 0 0 3615 60 0 29 12916 4518 2673 65 34 1 4 0 19 1.2G 247M 4813 0 0 0 2594 67 0 30 13449 3173 2255 74 25 0 4 0 19 1.2G 225M 4873 0 1 0 2175 70 0 27 13292 3127 2091 76 24 0 4 0 19 1.2G 231M 3512 0 0 0 2773 79 0 44 15339 2438 2410 79 21 0 4 0 19 1.2G 219M 3677 0 0 0 1914 82 0 43 15959 2132 2375 81 19 0 4 0 19 1.2G 210M 3622 0 0 0 2029 80 0 46 15267 2524 2351 79 21 0 5 0 19 1.2G 220M 5000 0 0 0 3555 78 0 27 12782 3525 2098 74 26 0 4 0 19 1.2G 215M 3730 0 0 0 2016 77 0 25 13425 2750 2142 77 23 0 6 0 19 1.2G 231M 4009 0 7 1 3315 81 0 27 13676 2797 2346 79 21 0 4 0 19 1.1G 304M 5477 0 1 0 7360 50 0 39 13346 4513 2862 64 35 0 4 0 19 1.1G 291M 2809 0 0 0 1508 48 0 52 15650 1639 2352 85 15 0 4 0 19 1.2G 276M 6818 0 3 1 3864 48 0 28 11419 5130 3224 61 39 0 4 0 19 1.2G 276M 2742 0 0 0 2012 58 0 32 14525 1508 1925 86 14 0 4 0 19 1.2G 253M 5533 0 2 1 2857 61 0 28 13042 3758 2715 71 29 0 From owner-freebsd-arm@freebsd.org Mon Aug 13 04:36: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 597EE1065207 for ; Mon, 13 Aug 2018 04:36:54 +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 D40D98900A for ; Mon, 13 Aug 2018 04:36:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Bi1Qnc8VM1narJrqMkWZX7hL3OyPtUBJqim0KguonyLUdAMaZ2nqRSvIg0T6AT7 I_dhi5MqbvceI8XmZ6zdxTDpmBCuRpdA_bKd4wcmgAvy1J8uLPLpGak_MXYMM5HkYTu.yzel9OIy PbQCZ0Ko7Vjw6x.npov70FXYuMM_MIC6TmGnAxMm3f5Xvd88mp7sPZ9XZrUp64Dn2WBZ9YA8X4AN 2A7os07M3j4edonJMvJJDFk3OFdWLOasCQxVqkxcujgHrm4355UkDyvyzpkfb65KqvzyVpjakLUU kRHgs04Pcqv.lI8.GIuEEgbkUsWsnFLMXO1RPESP3l8ba201YyViXxcC3C_eBHdZe8GcXe1yOKHS DAglMlTADuYWW7cnSARGa7lAYRVSZk4S3Gd7j9rTgh8kN1bcqVqg.5q2nx1Azot_6cz86_so..US 5a74aBJHO.hz4M.yNipZEAIRYPPN2YAgIPtScSdbxYn9guXpMAub8K1mxqzZYuGGL10mRGhciTxI BMZYVeeBb0Ekv7AyS7yxmFhH2aZLzpYGWTwLDSLS4YNBhfmDe2kc6Sd5B44kX1Ej0flX56UbC1YA _PtY1Y_FkZozMEo.IlacS5rktFUxPwVBN5MSqm8kTS0JyuBKAetJT5b0OOP2AfFeDKOD53X_Fjeg 8nsrvp25pVXgT0u2ZyBUtiu_g3f44TaJzgMflf2HunONjd6FUAwCKZnp9D4GP2WSXMrMQFyfEJ2s GiQ914QZtDVH5dk6mNOcUcSEzvYw4F81TiccTyLsbEsi2JJusiNs0.kRwxg03ll0aDWUR0pJLlsT Fe6etD6TS0XjGQs7HgU.o3vsJK8uNyQDRVMzBPOIm6N7bc6vdg0eS3NRkHVoME0qD4SIu2n2TXrj R6k4AMwbF4itGbyTHTaFDmmnvalHs5qhz8pTcBTnvv.igsjosTiV0XKsscwmABltbBkXkj2xG2Bj Fx4vPKwT1RdeLERNNTWMye39Ndbpa8fB1K7ZwN5uqz_MTdXt2rVBtM._E42tTfmtbRm71seIsODx x.suJxWI6QA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 13 Aug 2018 04:36:47 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp412.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6d28b8dc749cdb8bea5a2acc1fac8f19; Mon, 13 Aug 2018 03:36: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: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180813021226.GA46750@www.zefox.net> Date: Sun, 12 Aug 2018 20:36:01 -0700 Cc: Mark Johnston , John Kennedy , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> References: <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@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: Mon, 13 Aug 2018 04:36:54 -0000 On 2018-Aug-12, at 7:12 PM, bob prohaska wrote: > On Sun, Aug 12, 2018 at 04:23:31PM -0700, Mark Millard wrote: >> On 2018-Aug-12, at 3:40 PM, bob prohaska = wrote: >>=20 >>> On Sun, Aug 12, 2018 at 10:32:48AM -0700, John Kennedy wrote: >>>> . . . >>> Setting vm.pageout_oom_seq to 120 made a decisive improvement, = almost allowing >>> buildworld to finish. By the time I tried CAM_IOSCHED_DYNAMIC = buildworld was >>> getting only about half as far, so it seems the patches were harmful = to a degree. >>> Changes were applied in the order=20 >>=20 >> You could experiment with figures bigger than 120 for >> vm.pageout_oom_seq . >>=20 > Could anybody hazard a guess as to how much? The leap from 12 to 120 = rather > startled me, I thought a factor of two a big adjustment. Maybe go to = 240, > or is that insignificant? I'd keep multiplying by 10 until it works (or fails some other way), then back off by smaller factors if you want a narrower range to be known between failing and working (or failing differently). >> I'll note that the creation of this mechanism seems >> to be shown for -r290920 at: >>=20 >> = https://lists.freebsd.org/pipermail/svn-src-head/2015-November/078968.html= >>=20 >> In part is says: >>=20 >> . . . only raise OOM when pagedaemon is unable to produce a free >> page in several back-to-back passes. Track the failed passes per >> pagedaemon thread. >>=20 >> The number of passes to trigger OOM was selected empirically and >> tested both on small (32M-64M i386 VM) and large (32G amd64) >> configurations. If the specifics of the load require tuning, sysctl >> vm.pageout_oom_seq sets the number of back-to-back passes which must >> fail before OOM is raised. Each pass takes 1/2 of seconds. Less = the >> value, more sensible the pagedaemon is to the page shortage. >>=20 >> The code shows: >>=20 >> int vmd_oom_seq >>=20 >> and it looks like fairly large values would be >> tolerated. You may be able to scale beyond >> the problem showing up in your context. >=20 > Would 1024 be enough to turn OOMA off completely? That's what I = originally wanted to=20 > try. As far as I know until arithmetic fails for the sizes involved, it scales. The factor of 10 rule makes the number of tests logarithmic to find an sufficient upper bound (if there is an upper bound). After that with high/low bounds binary searching is a possibility. (That ignores any effort at determining repeatability.) >>=20 >>> pageout=20 >>> batchqueue >>> slow_swap >>> iosched >>=20 >> For my new Pine64+ 2GB experiments I've only applied >> the Mark J. reporting patches, not the #define one. >> Nor have I involved CAM_IOSCHED_DYNAMIC. >>=20 >> But with 2 GiBytes of RAM and the default 12 for >> vm.pageout_oom_seq I got: >>=20 >> v_free_count: 7773, v_inactive_count: 1 >> Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: = out of swap space >>=20 >> with no other reports from Mark Johnston's reporting >> patches. >>=20 >> It appears that long I/O latencies as seen by the >> subsystem are not necessary to ending up with OOM >> kills, even if they can contribute when they occur. >>=20 >=20 > It has seemed to me in the past that OOMA kills aren't closely-tied to = busy > swap. They do seem closely-related to busy storage (swap and disk). My Pine64+ 2GB experiment suggests to me that for 4 cores running 4 processes (threads) at basically 100% per core, with the processes/threads allocating and using ever the more memory actively over time, without freeing=20 until near the end, will lead to the OOM kills if they run long enough. (I'm taking the rest of the processes as being relatively idle, not freeing up very much memory explicitly very often. This is much like the -j4 buildworld buildkernel in my context.) I'd not be surprised if a programs (threads) that do no explicit I/O would get the same result if the memory use and the "compute/memory bound" property was similar. >> (7773 * 4 KiBytes =3D 31,838,298 Bytes, by the way.) >>=20 > The RPI3 seems to start adding to swap use when free memory drops = below about 20 MB, > Does that seem consistent with your observations? I did not record anything that would show when for the first Pine64+ 2GB experiment. There were around 19 MiBytes of in-use swap left around from before at the start of the 2nd test. Also not the best for finding when things start. But the first increment beyond 19M was (two lines from top output for each time): Sun Aug 12 16:58:19 PDT 2018 Mem: 1407M Active, 144M Inact, 18M Laundry, 352M Wired, 202M Buf, 43M = Free Swap: 3072M Total, 19M Used, 3053M Free Sun Aug 12 16:58:20 PDT 2018 Mem: 1003M Active, 147M Inact, 15M Laundry, 350M Wired, 202M Buf, 453M = Free Swap: 3072M Total, 22M Used, 3050M Free >>> My RPI3 is now updating to 337688 with no patches/config changes. = I'll start the >>> sequence over and would be grateful if anybody could suggest a = better sequence. >>=20 > It seems rather clear that turning up vm.pageout_oom_seq is the first = thing to try. > The question is how much: 240 (double Mark J.'s number), 1024 (small = for an int on > a 64 bit machine)? I made a recommendation earlier above. I'm still at the 120 test in my context. > If in fact the reporting patches do increase the load on the machine, = is the=20 > slow swap patch the next thing to try, or the iosched option? Maybe = something else > altogether? The slow_swap.patch material is reporting material, and so is one of the patches that I put in place so that I might see messages about: waited ?s for swap suffer [happens for 3 <=3D s] waited ?s for async swap write [happens for 3 <=3D s] thread ? waiting for memory (None of which were produced in my test. As far as I know no one has gotten the thread one.) CAM_IOSCHED_DYNAMIC does not seem to apply to my Pine64+ 2GB test that did not report any I/O latency problems for the subsystem. I've no reason to go that direction from the evidence available. And my tests do not help with identifying how to survive I/O latency problems (so far). For now vm.pageout_oom_seq variation is all the control that seems to fit my context. (Presumes your negative result for VM_BATCHQUEUE_SIZE making an improvement applies.) Other goals/cpontexts get into doing other things. I've no clue if there is anything interesting to control for CAM_IOSCHED_DYNAMIC. Nor for variations on the VM_BATCHQUEUE_SIZE figure beyond the 1 and 7 that did not help your I/O latency context. It does appear to me that you have a bigger problem, more difficult to control, because of the I/O latency involvement. What might work for me might not be sufficient for you, even if it is involved for you. > There's no immediate expectation of fixing things; just to shed a = little light. >=20 For now, as far as I know, Mark Johnston's reporting patches are the means of exposing useful information for whatever range of contexts/configurations. For now I'm just exploring vm.pageout_oom_seq value variations and what is reported (or if it finished without a OOM kill). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Aug 13 07:38:55 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 AF57A1068E61 for ; Mon, 13 Aug 2018 07:38:55 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh501-vm9.bullet.mail.kks.yahoo.co.jp (nh501-vm9.bullet.mail.kks.yahoo.co.jp [183.79.56.139]) by mx1.freebsd.org (Postfix) with SMTP id 9FDA98E7B4 for ; Mon, 13 Aug 2018 07:38:54 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.139] by nh501.bullet.mail.kks.yahoo.co.jp with NNFMP; 13 Aug 2018 07:36:16 -0000 Received: from [183.79.100.137] by t502.bullet.mail.kks.yahoo.co.jp with NNFMP; 13 Aug 2018 07:36:16 -0000 Received: from [127.0.0.1] by omp506.mail.kks.yahoo.co.jp with NNFMP; 13 Aug 2018 07:36:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 366415.72483.bm@omp506.mail.kks.yahoo.co.jp Received: (qmail 85452 invoked by uid 60001); 13 Aug 2018 07:36:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1534145776; bh=9xp7qMr0Y3RsMgQSYYXZsUYO/CnZITYRgLNDEws6lOg=; 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=Yknt2VK2Z17OKytRvJWL+Xt9i7A7n4ltyb0kpX+kjNLgNHaXcKaVaXMGMSJX7c7AB7h81momnNlJymS7JwQV2PAh66ZrZHEHuPphcRa1cSU9vF80uJNF+ASKDUo4zze80qF413DDsMCGo2cV8SZUQn4dJDZbJ6QTKYalnzyvh0Y= 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=U0g0XmAYBZoO24zalq91Ru7ZBSgm4FDzqOkrCcCSrBotGPYVWOD2RzAkjEsW8M1obru8Fz18l+aArxDVGuIdjTMz97n4BTmCtjrLw0yLND6tVYjHLwIcBBb1xlAz/oTfj+NUvWs3qmJ0pljaqBojnGPdlmRo1lx5GZz34TfY0Yw=; Message-ID: <14732.80527.qm@web103913.mail.ssk.yahoo.co.jp> X-YMail-OSG: wo49KG4VM1kCCA0rUw5V0jcqJ.NHkBOw_NvNh.08uVe53hOd2TQT6pJi7DeYjrVpaI6XRDKMxErBqj.iZELLdtCWSyu0vW6v37lK1GE.dds5vm3FLwoR.An7NZ.D2tS_geoDImWhsoCY.M6zWANpixZTPapJrazAhYBSE4YY8wbatygCH0r0FD7g2jOo0eEHrpf21Q7qUkPZ_6SVFgAo1nhjD9Jw.apUNvt9RgKuXemZcrFV__.V33Kb2_oUgXvlckXJncOUOV8Ht9iPpCKNCvA6yG6FZ1P9GlkjTzQ39nG7U2LXKaT1ZWSvZm.cfdEbHG7fslnavfwmxNWgQ17LoLpFz2ulKWDNEnYhX6n00knEHjHJQCjNoylV7D0nGNpRSs.g_Uoj_pEXliyK18XLm3DC5fiqMVQU2_Dst_uIFJfPCP17JrRVemeF4XTtAs4Tr5GzOfCU48sUl.5IEQ5mQq_JDNd99M8FejQtjSJxgDqO.K0mF9EIzw8.0lG6AF_fbsdOCLbNwG0pEfPMSXx8xmouDxvmeIFBRoiCK9.E7L1eAWaS2ReeLr0VSdKtBCuhD8Amb0yGvhaVtEI88WYD4fD9uMU7wJZzkkr1iyPS0sXcUR9wQizqMnbipTN0Eyg6 Received: from [203.165.91.75] by web103913.mail.ssk.yahoo.co.jp via HTTP; Mon, 13 Aug 2018 16:36:14 JST X-Mailer: YahooMailWebService/0.8.111_74 X-YMail-JAS: Yj1bYG4VM1ka5ZhjWRXuVHnX8JgTNBcCaFzQxVSkzGeyFMFA0l1o2Mf_cWn.404flZL7r8jVwVp3NEB8EXQZ5ag4J3lUNAR9tV4Vrilxy2iTFRSu60iKtc8ZyRKJINFy9DDs References: <64850.63077.qm@web101706.mail.ssk.yahoo.co.jp> <387823.67007.qm@web101711.mail.ssk.yahoo.co.jp> <812183.70978.qm@web101705.mail.ssk.yahoo.co.jp> <892631.23713.qm@web101718.mail.ssk.yahoo.co.jp> <408.23467.qm@web101707.mail.ssk.yahoo.co.jp> <920419.9428.qm@web103910.mail.ssk.yahoo.co.jp> <197535.81645.qm@web103907.mail.ssk.yahoo.co.jp> Date: Mon, 13 Aug 2018 16:36:14 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: solved Re: still hang up arm/ralink To: Warner Losh Cc: Michael Zhilin , "freebsd-arm@freebsd.org" In-Reply-To: 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: Mon, 13 Aug 2018 07:38:55 -0000 Hi.=0A=0A----- Original Message -----=0A>From: Warner Losh = =0A>To: Mori Hiroki =0A>Cc: Michael Zhilin ; "freebsd-arm@freebsd.org" =0A>Date: 20= 18/8/13, Mon 01:27=0A>Subject: Re: solved Re: still hang up arm/ralink=0A> = =0A>=0A>=0A>=0A>=0A>=0A>On Sat, Aug 11, 2018 at 11:07 PM, Mori Hiroki wrote:=0A>=0A>Hi=0A>>=0A>>Sorry I lost your mail. Becaus= e of arm ML is so many mail more than mips.=0A>>=0A>>----- Original Message= -----=0A>>>From: Warner Losh =0A>>>To: Mori Hiroki =0A>>>Cc: Michael Zhilin ; "freebsd-arm@= freebsd.org" =0A>>>Date: 2018/8/12, Sun 04:14=0A>>= >Subject: Re: solved Re: still hang up arm/ralink=0A>>> =0A>>>=0A>>>=0A>>>= =0A>>>=0A>>>=0A>>>On Sat, Aug 11, 2018 at 9:25 AM, Warner Losh wrote:=0A>>>=0A>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>On Thu, Aug 9, 2018 at 1= 1:52 PM, Mori Hiroki wrote:=0A>>>>=0A>>>>Hi.=0A>>>>= >=0A>>>>>----- Original Message -----=0A>>>>>>From: Warner Losh =0A>>>>>>To: Mori Hiroki =0A>>>>>>Cc: Michael = Zhilin ; "freebsd-arm@freebsd.org" =0A>>>>>>Date: 2018/8/10, Fri 11:16=0A>>>>>>Subject: Re: solved Re: stil= l hang up arm/ralink=0A>>>>>> =0A>>>>>>=0A>>>>>>Mori-san=0A>>>>>>=0A>>>>>>= =0A>>>>>>I took your advice and bought a Buffalo WZR2-G300N off ebay. It ar= rived while I was on vacation. So, I spent a few minutes with it today. I'v= e installed header for serial port, puzzled out the pins, found your blog t= hat had the pins and the piece I was missing (the baud rate). I now have ad= ded it to my test lab's terminal server and hope to start building images f= or it once I get my test lab's CI infrastructure up and running.=0A>>>>>>= =0A>>>>>=0A>>>>>Thanks for your cooperation.=0A>>>>>=0A>>>>>>=0A>>>>>>So, n= ow I'm sitting at the "RT2860-EVB#" prompt from uboot hoping to boot the RT= 1310 kernel. However, I lack instructions and can't seem to find all the de= tails in your posts or on your blog. How do I load/create the RAM disk refe= renced in the kernel config file "options=A0 =A0 =A0 =A0 =A0ROOTDEVNAME=3D\= "cd9660:/dev/cfi d0s.rootfs.uzip\"" ? what address do I load the kernel at = (0x40800000 is listed in a diagram, but 0x40000100 is shown in the dmesg) a= nd which variation of the kernel should I use? Thanks for any help you can = offer.=0A>>=0A>>>>>>=0A>>>>>=0A>>>>>I use ZRouter build system. But I am a = suggestion normal build system.=0A>>>>>=0A>>>>>I think=A0Buffalo WZR2-G300N= is different u-boot on US and Japan model.=0A>>>>>Because of my target pro= mpt is "5VT1310-EVB#".=A0 Be careful operation.=0A>>>>>You can find some in= formation=A0in printenv at u-boot.=0A>>>>>=0A>>>>>Sorry I forget memory add= ress setting in build system. I add this to review.=0A>>>>>=0A>>>>>https://= reviews.freebsd. org/D1 6622=0A>>>>>=0A>>>>>In this setting build kernel he= ader is this.=0A>>>>>=0A>>>>>% readelf -h Buffalo_WZR2-G300N_kernel=0A>>>>>= ELF Header:=0A>>>>>=A0 Magic: =A0 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00= 00 00=A0=0A>>>>>=A0 Class: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 ELF32=0A>>>>>=A0 Data:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 2's complement, little endian=0A>>>>>=A0 Version: =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 (current)=0A>>>>>=A0 OS/ABI:= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 UNIX - FreeBSD=0A>>= >>>=A0 ABI Version: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0=0A>>>>>= =A0 Type:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EXEC (= Executable file)=0A>>>>>=A0 Machine: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 ARM=0A>>>>>=A0 Version: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 0x1=0A>>>>>=A0 Entry point address: =A0 =A0 =A0 =A0 =A0 = =A0 =A0 0xc0000100=0A>>>>>=A0 Start of program headers:=A0 =A0 =A0 =A0 =A0 = 52 (bytes into file)=0A>>>>>=A0 Start of section headers:=A0 =A0 =A0 =A0 = =A0 3633180 (bytes into file)=0A>>>>>=A0 Flags: =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x5000202, has entry point, Version5 EABI, =0A>>>>>=A0 Size of this header: =A0 =A0 =A0 =A0 =A0 =A0 =A0 52 (byte= s)=0A>>>>>=A0 Size of program headers: =A0 =A0 =A0 =A0 =A0 32 (bytes)=0A>>>= >>=A0 Number of program headers: =A0 =A0 =A0 =A0 6=0A>>>>>=A0 Size of secti= on headers: =A0 =A0 =A0 =A0 =A0 40 (bytes)=0A>>>>>=A0 Number of section hea= ders: =A0 =A0 =A0 =A0 37=0A>>>>>=A0 Section header string table index: 34= =0A>>>>>=0A>>>>>Do opjcopy and compress and make u-boot image by load and e= ntry address is=A00x40000100.=0A>>>>>=0A>>>>>% file Buffalo_WZR2-G300N_kern= el.kbin .oldlzma.uboot=0A>>>>>=0A>>>>>Buffalo_WZR2-G300N_kernel. kbin .oldl= zma.uboot: u-boot legacy uImage, FreeBSD Kernel Image, Linux/ARM, OS Kernel= Image (lzma), 999004 bytes, Wed Aug=A0 8 22:50:36 2018, Load Address: 0x40= 000100, Entry Point: 0x40000100, Header CRC: 0xFEC4D6B9, Data CRC: 0xE650ED= DF=0A>>>>>=0A>>>>>It can execute on memory. (not flash)=0A>>>>>You need set= ipaddr and serverip on u-boot.=0A>>>>>=0A>>>>>5VT1310-EVB# tftpboot 008000= 00 Buffalo_WZR2-G300N_kernel.kbin .oldlzma.uboot=0A>>>>>TFTP from server 10= .10.10.3; our IP address is 10.10.10.190=0A>>>>>Filename 'Buffalo_WZR2-G300= N_kernel.kbi n.oldlzma.uboot'.=0A>>=0A>>>>>Load address: 0x800000=0A>>>>>Lo= ading: ############################## ############################## #####= =0A>>>>>########################### ### ############################## ####= #=0A>>>>>########################### ### ############################## ###= ##=0A>>>>>#=0A>>>>>done=0A>>>>>Bytes transferred =3D 999068 (f3e9c hex)=0A>= >>>>5VT1310-EVB# bootm=0A>>>>>## Booting image at 00800000 ...=0A>>>>>=A0= =A0 Image Name: =A0 FreeBSD Kernel Image=0A>>>>>=A0=A0 Image Type: =A0 ARM = Linux Kernel Image (lzma compressed)=0A>>>>>=A0=A0 Data Size:=A0 =A0 999004= Bytes =3D 975.6 kB=0A>>>>>=A0=A0 Load Address: 40000100=0A>>>>>=A0=A0 Entr= y Point:=A0 40000100=0A>>>>>=A0=A0 Verifying Checksum ... OK=0A>>>>>=A0=A0 = Uncompressing LZMA Kernel Image .............................. ............= OK=0A>>>>>=0A>>>>>Starting kernel @40000100...=0A>>>>>=0A>>>>>KDB: debugger= backends: ddb=0A>>>>>KDB: current backend: ddb=0A>>>>>Copyright (c) 1992-2= 018 The FreeBSD Project.=0A>>>>>Copyright (c) 1979, 1980, 1983, 1986, 1988,= 1989, 1991, 1992, 1993, 1994=0A>>>>>The Regents of the University of Calif= ornia. All rights reserved.=0A>>>>>=0A>>>>>If you can execute kernel then s= top at rootfs mount.=0A>>>>>=0A>>>>>I think this is first step.=0A>>>>>=0A>= >>>=0A>>>>=0A>>>>Where do I find oldlzma utility? The current one produces = an unbootable image:=0A>>>>=0A>>>>=0A>>>>%=A0objcopy -S -O binary kernel ke= rnel.kbin=0A>>>>% lzma kernel.kbin=0A>>>>% mkimage -A arm -O FreeBSD -T ker= nel -C lzma -a 0x40000100 -e 0x40000100 -n rt1310 -d kernel.kbin.lzma kerne= l.kbin.lzma.u-boot=0A>>>>Image Name:=A0 =A0rt1310=0A>>>>Created:=A0 =A0 =A0= Sat Aug 11 09:06:27 2018=0A>>>>Image Type:=A0 =A0ARM FreeBSD Kernel Image = (lzma compressed)=0A>>>>Data Size:=A0 =A0 1317305 Bytes =3D 1286.43 KiB =3D= 1.26 MiBLoad Address: 40000100=0A>>>>Entry Point:=A0 40000100=0A>>>>% scp = kernel.kbin.lzma.u-boot tftp:tftpboot=0A>>>>...=0A>>>>RT2860-EVB# bootm## B= ooting image at 00800000 ...=0A>>>>=A0 =A0Image Name:=A0 =A0rt1310=0A>>>>= =A0 =A0Image Type:=A0 =A0ARM Unknown OS Kernel Image (lzma compressed)=0A>>= >>=A0 =A0Data Size:=A0 =A0 1317305 Bytes =3D=A0 1.3 MB=A0 =A0Load Address: = 40000100=0A>>>>=A0 =A0Entry Point:=A0 40000100=0A>>>>=A0 =A0Verifying Check= sum ... OK=0A>>>>=A0 =A0Uncompressing Kernel Image ... LZMA ERROR 1 - must = RESET board to recover=0A>>>>OK=0A>>>>=0A>>>>=0A>>>>I see you have 'oldlzma= ' and online instructions use an oldlzma command...=0A>>>=0A>>>=0A>>>I buil= t oldlzma from zrouter and have the same results...=0A>>>=0A>>>=0A>>>Warner= =0A>>=0A>>You need make small rootfs because of this target flash is too sm= all.=0A>>ZRouter is make cd9660 rootfs image by limited files and uzip.=0A>= >And 64Kbyte synced kernel image append rootfs uzip.=0A>>=0A>>+------------= -------+------+-- ---------+=0A>>|u-boot kernel image|synced|rootfs uzip|= =0A>>+-------------------+------+-- ---------+=0A>>=0A>>This is complete im= age.=0A>>=0A>>Also you need fixed rootfs address in dts.=0A>>=0A>>sys/dts/a= rm/wzr2-g300n.dts=0A>>=0A>>This is flash u-boot command.=0A>>=0A>>5VT1310-E= VB#=A0tftpboot 0x00800000 Buffalo_WZR2-G300N.zimage=0A>>=0A>>5VT1310-EVB#= =A0erase 0x1F010000 0x1F3CFFFF=0A>>=0A>>5VT1310-EVB#=A0cp.b 0x00800000 0x1F= 010000 $(filesize)=0A>>=0A>>5VT1310-EVB# reset=0A>>=0A>=0A>=0A>Do I need it= to successfully uncompress the kernel? So far I can't get a kernel to unco= mpress w/o the LZMA ERROR 1 message. I have no doubt I'll need it eventuall= y, but right now I can't even get the kernel to start....=0A>=0A>=0A>Warner= =0A=0APlease use zrouter lzma command by this.=0A=0A% oldlzma e kernel.kbin= kernel.kbin.lzma=0A=0AThis is ray's magic.=0A=0AHiroki Mori=0A>=A0=0A>I ma= ke auto scan rootfs=A0partition patch at geom_flashmap.=0A>>=0A>>https://re= views.freebsd.org/ D13648=0A>>=0A>>This patch scan rootfs in named firmware= =A0partition.=0A>>=0A>>I have many time stop at mountroot. This patch is so= lution this.=0A>>=0A>>Regards=0A>>=0A>>Hiroki Mori=0A>>=0A>>>=A0=0A>>>Warne= r=0A>>>>=A0=0A>>>>Thanks=0A>>>>>=0A>>>>>Hiroki Mori=0A>>>>>=0A>>>>>=0A>>>>>= >=0A>>>>>>Warner=0A>>>>>>=0A>>>>>>=0A>>>>>>On Sat, Mar 10, 2018 at 2:31 AM,= Mori Hiroki wrote:=0A>>>>>>=0A>>>>>>Hi=0A>>>>>>>= =0A>>>>>>>I do try to todays current. It' work find on RT1310.=0A>>>>>>>=0A= >>>>>>>https://gist.github.com/ yamori813/ 88224f1c96c9c592fb611b12a15e4a b= 5=0A>>>>>>>=0A>>>>>>>=0A>>>>>>>Thanks=0A>>>>>>>=0A>>>>>>>Hiroki Mori=0A>>>>= >>>_________________________ ___ __ _________________=0A>>=0A>>>>>>>freebsd= -arm@freebsd.org mailing list=0A>>>>>>>https://lists.freebsd. org/ mailman/= listinfo/freebsd-arm=0A>>>>>>>To unsubscribe, send any mail to "freebsd-arm= -unsubscribe@ freebsd.org"=0A>>>>>>>=0A>>>>>>=0A>>>>>>=0A>>>>>>=0A>>>>>=0A>= >>>=0A>>>=0A>>>=0A>>>=0A>>=0A>=0A>=0A> From owner-freebsd-arm@freebsd.org Mon Aug 13 10:17: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 EDAC6106D534 for ; Mon, 13 Aug 2018 10:16:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-21.consmr.mail.gq1.yahoo.com (sonic312-21.consmr.mail.gq1.yahoo.com [98.137.69.202]) (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 5D242733A7 for ; Mon, 13 Aug 2018 10:16:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ib5dZ1AVM1lM8aGStNRpclcZHMG9Utd1Vo3_bzePEj426CrvazK28ycKq8rfdkb Pu6GYM2sFOtmTTZzPVT9a4K4HhSWAgzJVX8FxxIjIhOT_Eumh9w9ZPL4t1xlFQc5xpP.2H5NFV0h c95Fr1mnN4DYOQdZtirdvvbf_IQ1gIOaWTbFGKgD8THRUKLlSF_8_Ro4kJ4aj21_SbsN4U.TCKuT ot4ZiUaK1evwws7LqPFknJTkhTMzk2kjp.UyqM8udMMDIy71Oy5q_o_zGxTiU3_M0HMmoAWYXDh3 d_4d9zfXF7txbJWTVkeyACGbjBL_Wcm6SY1gNaSRkfQNnhdrYqinIjoREbqgOkjxCQ5hZfUp8skk dSF3_c2CMVbaaMhDBOvk5knYuds4_LS8c2rLTFrk.VRv9u8s1eDv_cXv_sRux2NVLzGYCXwpQP5O jWZHHdrg1XrQCyFtjqxMeWPkBIZwMumoYEml8LKoLBhgLWTWBzE0KwlgDnxPjT4HkV5wO.xCxzXy GPLXwc7Rgwk0ivO5rpmOd3Igzcb80a7hloILf9M143_gIbv5y7_5rsgwP7JhGKBkevls2VqN4KWz pjsY0KAsyI7z2JiZYO0Kk0AepKTHbES31awc20nbSJHrhDCNMzLiDzyvKqm2wmvckNdpBvRg5WZS 4vjnyPL4q95JHGjCsRcS6AYSkQCDCze.3GA6kJgTvQNsA610xTanV06i3KTV1RsTDMF_rMaIN9HR ZDNoUE5iiE8OEGJ1AA9GDaIJTMh07evtvU94uU7OPGATGcy85BUsgfssOwRX4hEqpykE_3jemVka jhOSGbH6ewk5gX5Lj09x4PUb5C7p5j81s599QePjtwd77WfN7V6xnpcp1DYBiz2L5QxAwpARDYIw VSWAn_ijLVNq33.ZD8dDCHgwS2hcE3KjkPhysuHIguU55GyK_zOb8SMqGAkRurX.DPm97kzPYmCO DgEysRjWO1P7iqzOV4r0J7IOJYRNMDl2Dz.NdnIACWWGtT4SSz7yuNFCJY172YgivpX77KX8Pzu8 khUkznjEBEjtQtf1kMm2G1P_Z Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 13 Aug 2018 10:16:51 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp412.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID db1ef0fe9ef849f14a4084fbf2932658; Mon, 13 Aug 2018 10:16: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 [a failure for a Pine64+ 2GB at head -r337400 without vm.pageout_oom_seq or #define adjustment, no I/O latency problem reported] From: Mark Millard In-Reply-To: <507FC6E0-6EDB-4A0D-A9A6-DD03B50A1DA3@yahoo.com> Date: Mon, 13 Aug 2018 03:16:48 -0700 Cc: Trev , bob prohaska , John Kennedy , Jamie Landeg-Jones , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7AAC5B79-003C-4504-8860-26657E3A7D98@yahoo.com> References: <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> <20180809153710.GC30347@www.zefox.net> <20180810044426.GB32974@www.zefox.net> <20180811163209.GA38922@www.zefox.net> <64798536-4ba5-24e9-304b-30cfb5b702d0@sentry.org> <507FC6E0-6EDB-4A0D-A9A6-DD03B50A1DA3@yahoo.com> To: Mark Johnston , Warner Losh 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: Mon, 13 Aug 2018 10:17:00 -0000 [vm.pageout_oom_seq=3D120 worked in this Pine64+ 2GB environment.] On 2018-Aug-12, at 10:59 AM, Mark Millard wrote: > [Quick top post: Possibly related bugzilla's for this area > are: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227609 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230402 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230454 > .] >=20 > On 2018-Aug-12, at 10:15 AM, Mark Millard = wrote: >=20 >> Based on having all Mark Johnston's reporting-patches but >> not adjusting vm.pageout_oom_seq or the #define I got >> an OOM kill during buildworld on a Pine64+ 2GB (so 2 GiByte >> of RAM). >>=20 >> I'll give other environment characteristic later. >> But that no I/O latency problems were reported by the >> patches is not a surprise: the device with the root file >> system and swap partition has not historically shown >> latency problems and is not of a type usually used with >> such a system (better than normal). >>=20 >> I expect that this case shows that the problem does not >> require I/O latency problems to be involved. >>=20 >> The only console message was: >>=20 >> Aug 12 09:30:13 pine64 kernel: v_free_count: 7773, v_inactive_count: = 1 >> Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: = out of swap space >>=20 >> The build had been started at: 01:44:59 so the failure >> was around 7 hours 45 minutes into the build. >>=20 >> The build log shows: >>=20 >> Building = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/lib= clang/Sema/SemaDeclAttr.o >> Building = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/lib= clang/Sema/SemaDeclCXX.o >> Building = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/lib= clang/Sema/SemaDeclObjC.o >> --- Sema/SemaDecl.o --- >> c++: error: unable to execute command: Killed >> 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 >> ******************** >>=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/SemaDecl-44b104.cpp >> c++: note: diagnostic msg: /tmp/SemaDecl-44b104.sh >> c++: note: diagnostic msg:=20 >>=20 >> ******************** >> *** [Sema/SemaDecl.o] Error code 254 >>=20 >>=20 >> Description of the context . . . >>=20 >> I have access to a Pine64+ 2GB (that was updated to -r337400 >> via a cross build) and had it doing a self-hosted rebuild of >> -r337400 via -j4. (This was a jump from its last update over >> 10 months ago. I've not historically had OOM kill problems.) >>=20 >> The root file system is on a USB3.0-capable 240 GB SSD >> plugged in the lower slot, where it gets the 480Mbps >> USB 2.0 classification. The kernel was loaded from a >> microSDHC card that also supplied a /etc/fstab that >> redirects to the USB root file system. >>=20 >> (With an edit of that /etc/fstab the microSDHC can boot >> standalone: I keep it tracking.) >>=20 >> # usbconfig >> ugen0.1: at usbus0, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DSAVE (0mA) >> ugen1.1: at usbus1, cfg=3D0 md=3DHOST = spd=3DFULL (12Mbps) pwr=3DSAVE (0mA) >> ugen0.2: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH = (480Mbps) pwr=3DON (0mA) >>=20 >> Historically I've not observed latency problems for >> the USB SSD. None were reported by Mark Johnston's >> reporting patches, unlike for Bob P.'s context. >>=20 >> In top I'd seem over 1400 Mem Active, well over the amount >> of RAM in a rpi3 or rpi2. (Of course with more memory the >> relative timings of what is running will be different >> from what rpi3's/rpi2's get. That is not the only source of >> variation.) >>=20 >> Swap had been used, I've seen 19M Used shown (of 3 GiByte >> in the swap partition in use). (I do not have in place my >> prior changes to record and report the maximum observed >> swap used: I reverted to the normal version of top during >> top's development activity.) >>=20 >> I'm unlikely to have observed approximate the maximums for >> Mem Active or Swap Used. These are things I wish there were >> normally available for inspection from FreeBSD. >>=20 >> I did not have a parallel loop showing gstat output >> or other such, relying on Mark Johnston's patches >> for reporting any that are a problem for the subsystem(s) >> involved. (It is also less I/O to not be running the >> extra logs.) >>=20 vm.pageout_oom_seq=3D120 worked in this Pine64+ 2GB environment. There were no messages from Mark Johnston's reporting patches. It took a little under 13 hr 40 minutes for a from-scratch build that did not build the bootstrap compiler or bootstrap linker but did build the clang extras: # = ~/sys_build_scripts.aarch64-host/make_cortexA53_nodebug_clang_bootstrap-aa= rch64-host.sh -j4 buildworld buildkernel . . . --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined = that CC=3Dcc matches the source tree. Not bootstrapping a = cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined = that LD=3Dld matches the source tree. Not bootstrapping a cross-linker. . . . -------------------------------------------------------------- >>> Kernel build for GENERIC-NODBG completed on Mon Aug 13 00:44:10 PDT = 2018 -------------------------------------------------------------- Script done, output file is = /root/sys_typescripts/typescript_make_cortexA53_nodebug_clang_bootstrap-aa= rch64-host-2018-08-12:11:07:29 (The script file name has the start time in it.) That was based on: # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host=20 TO_TYPE=3Daarch64 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D WITH_SYSTEM_LINKER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D #WITH_LLD_BOOTSTRAP=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D #WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITHOUT_BINUTILS=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # Use of the .clang 's here avoids # interfering with other CFLAGS # usage, such as ?=3D usage. CFLAGS.clang+=3D -mcpu=3Dcortex-a53 CXXFLAGS.clang+=3D -mcpu=3Dcortex-a53 CPPFLAGS.clang+=3D -mcpu=3Dcortex-a53 ACFLAGS.arm64cpuid.S+=3D -mcpu=3Dcortex-a53+crypto ACFLAGS.aesv8-armx.S+=3D -mcpu=3Dcortex-a53+crypto ACFLAGS.ghashv8-armx.S+=3D -mcpu=3Dcortex-a53+crypto I used the following: # more monitor_ram_swap.sh=20 #!/bin/sh while true do sleep 1 ; date ; top -CawSores | egrep "(Mem|Swap):" done=20 to monitor part of the build, although I accidentally stopped it part way through clang/libclang being built and did not notice at the time. This was somewhat past where the prior vm.pageout_oom_seq=3D12 test had the supposedly-OOM kill. The peak observed mem-active was 1572M: (I manually added the blank lines before date output.) . . . Sun Aug 12 19:12:27 PDT 2018 Mem: 1473M Active, 64M Inact, 752K Laundry, 352M Wired, 202M Buf, 76M = Free Swap: 3072M Total, 41M Used, 3031M Free, 1% Inuse Sun Aug 12 19:12:28 PDT 2018 Mem: 1478M Active, 65M Inact, 752K Laundry, 352M Wired, 202M Buf, 69M = Free Swap: 3072M Total, 41M Used, 3031M Free, 1% Inuse Sun Aug 12 19:12:29 PDT 2018 Mem: 1540M Active, 39M Inact, 752K Laundry, 351M Wired, 202M Buf, 35M = Free Swap: 3072M Total, 41M Used, 3031M Free, 1% Inuse Sun Aug 12 19:12:31 PDT 2018 Mem: 1568M Active, 12M Inact, 1192K Laundry, 342M Wired, 202M Buf, 41M = Free Swap: 3072M Total, 41M Used, 3031M Free, 1% Inuse Sun Aug 12 19:12:32 PDT 2018 Mem: 1572M Active, 2780K Inact, 1512K Laundry, 342M Wired, 202M Buf, 49M = Free Swap: 3072M Total, 41M Used, 3031M Free, 1% Inuse Sun Aug 12 19:12:33 PDT 2018 Mem: 1113M Active, 3828K Inact, 1612K Laundry, 342M Wired, 202M Buf, = 505M Free Swap: 3072M Total, 41M Used, 3031M Free, 1% Inuse . . . But this was not where the (earlier) peak observed swap-use of 222M Used was recorded: . . . Sun Aug 12 18:56:35 PDT 2018 Mem: 1118M Active, 209M Inact, 250M Laundry, 345M Wired, 202M Buf, 43M = Free Swap: 3072M Total, 216M Used, 2856M Free, 7% Inuse Sun Aug 12 18:56:36 PDT 2018 Mem: 1117M Active, 209M Inact, 250M Laundry, 345M Wired, 202M Buf, 44M = Free Swap: 3072M Total, 216M Used, 2856M Free, 7% Inuse Sun Aug 12 18:56:37 PDT 2018 Mem: 1123M Active, 208M Inact, 247M Laundry, 345M Wired, 202M Buf, 42M = Free Swap: 3072M Total, 219M Used, 2853M Free, 7% Inuse . . . (an omitted block of 219M Used examples) . . . Sun Aug 12 18:57:09 PDT 2018 Mem: 1114M Active, 217M Inact, 247M Laundry, 346M Wired, 202M Buf, 41M = Free Swap: 3072M Total, 219M Used, 2853M Free, 7% Inuse Sun Aug 12 18:57:10 PDT 2018 Mem: 1127M Active, 205M Inact, 244M Laundry, 347M Wired, 203M Buf, 42M = Free Swap: 3072M Total, 222M Used, 2850M Free, 7% Inuse Sun Aug 12 18:57:11 PDT 2018 Mem: 988M Active, 162M Inact, 148M Laundry, 345M Wired, 202M Buf, 320M = Free Swap: 3072M Total, 56M Used, 3016M Free, 1% Inuse . . . The first and last recorded was: Sun Aug 12 11:24:50 PDT 2018 Mem: 62M Active, 435M Inact, 4596K Laundry, 454M Wired, 202M Buf, 1014M = Free Swap: 3072M Total, 19M Used, 3053M Free . . . Sun Aug 12 19:47:06 PDT 2018 Mem: 782M Active, 83M Inact, 1068K Laundry, 347M Wired, 202M Buf, 753M = Free Swap: 3072M Total, 41M Used, 3031M Free, 1% Inuse =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Aug 13 15:48: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 0121010760E3 for ; Mon, 13 Aug 2018 15:48:07 +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 5D25C7F676; Mon, 13 Aug 2018 15:48:06 +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 w7DFm43M037722; Mon, 13 Aug 2018 08:48:04 -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 w7DFm4e8037721; Mon, 13 Aug 2018 08:48:04 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201808131548.w7DFm4e8037721@pdx.rh.CN85.dnsmgr.net> Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] In-Reply-To: <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> To: Mark Millard Date: Mon, 13 Aug 2018 08:48:04 -0700 (PDT) CC: bob prohaska , freebsd-arm , Mark Johnston 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: Mon, 13 Aug 2018 15:48:07 -0000 > On 2018-Aug-12, at 7:12 PM, bob prohaska wrote: > > > On Sun, Aug 12, 2018 at 04:23:31PM -0700, Mark Millard wrote: > >> On 2018-Aug-12, at 3:40 PM, bob prohaska wrote: > >> > >>> On Sun, Aug 12, 2018 at 10:32:48AM -0700, John Kennedy wrote: > >>>> . . . > >>> Setting vm.pageout_oom_seq to 120 made a decisive improvement, almost allowing > >>> buildworld to finish. By the time I tried CAM_IOSCHED_DYNAMIC buildworld was > >>> getting only about half as far, so it seems the patches were harmful to a degree. > >>> Changes were applied in the order > >> > >> You could experiment with figures bigger than 120 for > >> vm.pageout_oom_seq . > >> > > Could anybody hazard a guess as to how much? The leap from 12 to 120 rather > > startled me, I thought a factor of two a big adjustment. Maybe go to 240, > > or is that insignificant? > > I'd keep multiplying by 10 until it works (or fails some > other way), then back off by smaller factors if you want > a narrower range to be known between failing and working > (or failing differently). > > >> I'll note that the creation of this mechanism seems > >> to be shown for -r290920 at: > >> > >> https://lists.freebsd.org/pipermail/svn-src-head/2015-November/078968.html > >> > >> In part is says: > >> > >> . . . only raise OOM when pagedaemon is unable to produce a free > >> page in several back-to-back passes. Track the failed passes per > >> pagedaemon thread. > >> > >> The number of passes to trigger OOM was selected empirically and > >> tested both on small (32M-64M i386 VM) and large (32G amd64) > >> configurations. If the specifics of the load require tuning, sysctl > >> vm.pageout_oom_seq sets the number of back-to-back passes which must > >> fail before OOM is raised. Each pass takes 1/2 of seconds. Less the > >> value, more sensible the pagedaemon is to the page shortage. > >> > >> The code shows: > >> > >> int vmd_oom_seq > >> > >> and it looks like fairly large values would be > >> tolerated. You may be able to scale beyond > >> the problem showing up in your context. > > > > Would 1024 be enough to turn OOMA off completely? That's what I originally wanted to > > try. > > As far as I know until arithmetic fails for the sizes > involved, it scales. > > The factor of 10 rule makes the number of tests > logarithmic to find an sufficient upper bound (if > there is an upper bound). After that with high/low > bounds binary searching is a possibility. > > (That ignores any effort at determining repeatability.) Perhaps a binary search of make -j1 buildworld on an AMD64 system of memory size that can complete this job without OOM. I bet once you find that value you well find that make -JN scales pretty well to requiring that amount of hard memory to complete a buildworld. My reasonsing is the "can not swap runable processes" that Mark found in the description of how the FreeBSD VM system works. Swap size/space does not matter for this condition as the system is not going to swap the large runnable compilers and linkers that occur during buildworld. > > >> > >>> pageout > >>> batchqueue > >>> slow_swap > >>> iosched > >> > >> For my new Pine64+ 2GB experiments I've only applied > >> the Mark J. reporting patches, not the #define one. > >> Nor have I involved CAM_IOSCHED_DYNAMIC. > >> > >> But with 2 GiBytes of RAM and the default 12 for > >> vm.pageout_oom_seq I got: > >> > >> v_free_count: 7773, v_inactive_count: 1 > >> Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: out of swap space > >> > >> with no other reports from Mark Johnston's reporting > >> patches. > >> > >> It appears that long I/O latencies as seen by the > >> subsystem are not necessary to ending up with OOM > >> kills, even if they can contribute when they occur. > >> > > > > It has seemed to me in the past that OOMA kills aren't closely-tied to busy > > swap. They do seem closely-related to busy storage (swap and disk). > > My Pine64+ 2GB experiment suggests to me that for 4 cores > running 4 processes (threads) at basically 100% per core, > with the processes/threads allocating and using ever > the more memory actively over time, without freeing > until near the end, will lead to the OOM kills if they > run long enough. > > (I'm taking the rest of the processes as being relatively > idle, not freeing up very much memory explicitly very > often. This is much like the -j4 buildworld buildkernel > in my context.) > > I'd not be surprised if a programs (threads) that do no > explicit I/O would get the same result if the memory > use and the "compute/memory bound" property was similar. > > >> (7773 * 4 KiBytes = 31,838,298 Bytes, by the way.) > >> > > The RPI3 seems to start adding to swap use when free memory drops below about 20 MB, > > Does that seem consistent with your observations? > > I did not record anything that would show when for > the first Pine64+ 2GB experiment. > > There were around 19 MiBytes of in-use swap left around > from before at the start of the 2nd test. Also not the > best for finding when things start. But the first increment > beyond 19M was (two lines from top output for each time): > > Sun Aug 12 16:58:19 PDT 2018 > Mem: 1407M Active, 144M Inact, 18M Laundry, 352M Wired, 202M Buf, 43M Free > Swap: 3072M Total, 19M Used, 3053M Free > > Sun Aug 12 16:58:20 PDT 2018 > Mem: 1003M Active, 147M Inact, 15M Laundry, 350M Wired, 202M Buf, 453M Free > Swap: 3072M Total, 22M Used, 3050M Free > > > >>> My RPI3 is now updating to 337688 with no patches/config changes. I'll start the > >>> sequence over and would be grateful if anybody could suggest a better sequence. > >> > > It seems rather clear that turning up vm.pageout_oom_seq is the first thing to try. > > The question is how much: 240 (double Mark J.'s number), 1024 (small for an int on > > a 64 bit machine)? > > I made a recommendation earlier above. I'm still at the 120 test > in my context. > > > If in fact the reporting patches do increase the load on the machine, is the > > slow swap patch the next thing to try, or the iosched option? Maybe something else > > altogether? > > The slow_swap.patch material is reporting material, > and so is one of the patches that I put in place so > that I might see messages about: > > waited ?s for swap suffer [happens for 3 <= s] > waited ?s for async swap write [happens for 3 <= s] > thread ? waiting for memory > > (None of which were produced in my test. As far as > I know no one has gotten the thread one.) > > CAM_IOSCHED_DYNAMIC does not seem to apply to my > Pine64+ 2GB test that did not report any I/O latency > problems for the subsystem. I've no reason to go > that direction from the evidence available. And my > tests do not help with identifying how to survive > I/O latency problems (so far). > > For now vm.pageout_oom_seq variation is all the control > that seems to fit my context. (Presumes your negative > result for VM_BATCHQUEUE_SIZE making an improvement > applies.) > > Other goals/cpontexts get into doing other things. I've > no clue if there is anything interesting to control for > CAM_IOSCHED_DYNAMIC. Nor for variations on the > VM_BATCHQUEUE_SIZE figure beyond the 1 and 7 that did > not help your I/O latency context. > > It does appear to me that you have a bigger problem, > more difficult to control, because of the I/O latency > involvement. What might work for me might not be > sufficient for you, even if it is involved for you. > > > There's no immediate expectation of fixing things; just to shed a little light. > > > > For now, as far as I know, Mark Johnston's reporting patches > are the means of exposing useful information for whatever > range of contexts/configurations. For now I'm just > exploring vm.pageout_oom_seq value variations and what is > reported (or if it finished without a OOM kill). > > === > 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" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Mon Aug 13 16:08:20 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 2E14010767C5 for ; Mon, 13 Aug 2018 16:08:20 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 B2B2A80118 for ; Mon, 13 Aug 2018 16:08:19 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-qt0-x230.google.com with SMTP id c15-v6so17977741qtp.0 for ; Mon, 13 Aug 2018 09:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2WZCibrTN0pxPibXSfEQ1HCxtyxM8lTflNc49D+ttOk=; b=VGSB2altUW6T6qK3vSe21Rs5a2oxW5Mff3bzLTzvURHsWLK/7grpvozbJVnM+uJqC1 kh4iTwGNZHyFSd9VPglXLUyiDll8ZfglAWjZWd2DUYvvainZKQ+pEMpCQvyvyCtHKa5Q 88N8xUy8Lb3/fS8LME3rNbm/fJ6GGwzMDHJryHij8wAmDECgXWD0HPCjUfDAz5dCqEms r0DX8pNvEMEnuLS7JqFnrAJIoXZK5LCWcSbfcxtecDr6XSRONVD1J3+wHe9Ff8nbFTP2 1wRzckuYWEd1GD+yL8P2lDefEUzLd+dvpamk6/52jkKkhLGnnQsj7CHUoEC7uFNjyGeW ez/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2WZCibrTN0pxPibXSfEQ1HCxtyxM8lTflNc49D+ttOk=; b=hURHjnhiB0Tc2SwEyukeYNJtxmh9t5Y7zl5FYRdtA3tUyfViPJeSALrshoH1PsiCXL 7GNmvzxVtlN9IPlZAba0wTce0C16mnDMNTuGTfEZtaee/8hUs1L9s3ueReWnQDvb/J0Q S5EBKpRej1xwWg1F34SUqY+0nzl3lcLvg6T/O04M9T+PYtXdc8jJjaHFJjIALk6wp941 I0KKpMCgC70d2PwRBxoMMRmq4R5fEMBnW8o4IvjVXB/OdgzjQIBKXcxTw4TTY+csTTwD HaB8nDNzrCzT+aII8FSxgGlnsWkkRhGI33ikQ/JYyRcIZZtZOdMMgOe1h7a1qcOPhri8 SwZA== X-Gm-Message-State: AOUpUlGdGUcqPMC7DhSNCMjSeEmdgR0a6lGh6xLGZ5aYvt/0TvNMiA1S b0f+TASmVTB9R3v+DLPq/ayukYb1baUbqkKfuPMzp2em X-Google-Smtp-Source: AA+uWPxZ/jQxPWpUev6aZQHsHwrdryNiaFnfRqjO6nkePNd+9O0q9/cbN0dcgHG6Ew1cQkdPjfwF7L1iUKN78cbFDQM= X-Received: by 2002:a0c:c30f:: with SMTP id f15-v6mr15460536qvi.104.1534176499081; Mon, 13 Aug 2018 09:08:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:29c3:0:0:0:0:0 with HTTP; Mon, 13 Aug 2018 09:08:18 -0700 (PDT) In-Reply-To: <1534020520.35460.1@hraggstad.unrelenting.technology> References: <1533577708.4175.0@hraggstad.unrelenting.technology> <1534020520.35460.1@hraggstad.unrelenting.technology> From: Ganbold Tsagaankhuu Date: Tue, 14 Aug 2018 00:08:18 +0800 Message-ID: Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Greg V Cc: freebsd-arm 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: Mon, 13 Aug 2018 16:08:20 -0000 On Sun, Aug 12, 2018 at 4:48 AM, Greg V wrote: > > > On Sat, Aug 11, 2018 at 3:09 PM, Ganbold Tsagaankhuu > wrote: > >> >> >> On Tue, Aug 7, 2018 at 1:48 AM, Greg V >> wrote: >> >>> Hi, >>> >>> I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64 ROCKPro64 >>> board): >>> >>> https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 >>> >>> >> Very nice. I have NanoPC-T4 board and will test your patch. >> Did you try to load kernel via tftp at u-boot prompt? like: >> >> tftpboot 0x02000000 kernel.bin, go 0x02000000 >> >> Does it work for you that way? >> > > kernel.bin?? EFI has always been the way to go with aarch64 (and I think > it's even recommended on armv7/6 too). > > I do it like this: > > env set serverip 192.168.1.2 > env set bootargs boot.nfsroot.server=${serverip} > boot.nfsroot.path=/some/path comconsole_speed=${baudrate} > tftpboot ${kernel_addr_r} loader.efi > tftpboot ${fdt_addr_r} dtb/rockchip/rk3328-rock64.dtb > bootefi ${kernel_addr_r} ${fdt_addr_r} > > But the more-automated way (fully configured by dhcp) should work too, at > least if you don't have dhcp and tftp on different servers > Thank you. I've managed to boot NanoPC-T4 board with your patches using loader.efi on fat partition on SD card: http://dpaste.com/0Y00M4B I used rk3399-rockpro64.dtb, as rk3399-nanopi4-rev00.dtb is somehow not working for me. Ganbold From owner-freebsd-arm@freebsd.org Mon Aug 13 16:29: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 7B4561077137 for ; Mon, 13 Aug 2018 16:29:38 +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 0873780BE0 for ; Mon, 13 Aug 2018 16:29:37 +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 w7DGTZfG091224 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 13 Aug 2018 09:29:35 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w7DGTZZ0091223 for freebsd-arm@FreeBSD.org; Mon, 13 Aug 2018 09:29:35 -0700 (PDT) (envelope-from jmg) Date: Mon, 13 Aug 2018 09:29:35 -0700 From: John-Mark Gurney To: freebsd-arm@FreeBSD.org Subject: anyone working on armv8crypto? Message-ID: <20180813162935.GK97145@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]); Mon, 13 Aug 2018 09:29:35 -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, 13 Aug 2018 16:29:38 -0000 Is anyone working on expanding the support of the armv8crypto module? Right now it only supports AES-CBC, and missing a number of other useful ciphers, like -GCM and -XTS (geli encryption). It also doesn't support the SHA1 or SHA2 hashes either. If you are, please let me know! Thanks. -- 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 Aug 13 17:32: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 D531110788D3 for ; Mon, 13 Aug 2018 17:32:22 +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 51B4083542 for ; Mon, 13 Aug 2018 17:32:22 +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 w7DHWKSI092165 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 13 Aug 2018 10:32:20 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w7DHWKe4092164 for freebsd-arm@FreeBSD.org; Mon, 13 Aug 2018 10:32:20 -0700 (PDT) (envelope-from jmg) Date: Mon, 13 Aug 2018 10:32:20 -0700 From: John-Mark Gurney To: freebsd-arm@FreeBSD.org Subject: attempted to get A64-LTS thermal working Message-ID: <20180813173220.GL97145@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]); Mon, 13 Aug 2018 10:32:20 -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, 13 Aug 2018 17:32:23 -0000 So, w/ a pointer from manu: https://twitter.com/manuvadot/status/1029002683892609026 I'm working from the July 9th snapshot, FreeBSD-12.0-CURRENT-arm64-aarch64-PINE64-20180709-r336134.img I tried to put the dtb on the FAT partition, but u-boot doesn't seem to load it: [freebsd@generic ~]$ ls /boot/msdos/dtb/allwinner/sun50i-a64-sopine-baseboard.dtb /boot/msdos/dtb/allwinner/sun50i-a64-sopine-baseboard.dtb So, I decided to manually load the dtb w/ loader: OK set currdev=disk0p1: OK load -t dtb dtb/allwinner/sun50i-a64-sopine-baseboard.dtb dtb/allwinner/sun50i-a64-sopine-baseboard.dtb size=0x5c63 and w/ it loaded, I can see the thermal device: aw_thermal0: mem 0x1c25000-0x1c250ff irq 8 on simplebus0 and: root@generic:~ # sysctl -a | grep therm dev.aw_thermal.0.gpu2: 24C dev.aw_thermal.0.gpu1: 23C dev.aw_thermal.0.cpu: 24C dev.aw_thermal.0.%parent: simplebus0 dev.aw_thermal.0.%pnpinfo: name=thermal_sensor@1c25000 compat=allwinner,sun50i-a64-ths dev.aw_thermal.0.%location: dev.aw_thermal.0.%driver: aw_thermal dev.aw_thermal.0.%desc: Allwinner Thermal Sensor Controller dev.aw_thermal.%parent: but then the ethernet does not work: awg0: mem 0x1c30000-0x1c3ffff irq 30 on simplebus0 awg0: Failed to find syscon node awg0: cannot get syscon driver handle 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:1a:xx:xx:xx and it never gets link: Waiting 30s for the default route interface: .....(no carrier) I've put the broken boot at: https://www.funkthat.com/~jmg/FreeBSD/arm/a64-lts.broken.20180813.txt I've put the working boot at: https://www.funkthat.com/~jmg/FreeBSD/arm/a64-lts.working.20180813.txt took me a few seconds to realize that the reason they are about the same length is that the broken has additional other drivers like the mx2510 flash driver and spi. -- 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 Aug 13 17:35: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 E3729107895F for ; Mon, 13 Aug 2018 17:35:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (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 69C6D83625 for ; Mon, 13 Aug 2018 17:35:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Hqqjg.EVM1nrg8PuqjF1V4D7bpt1xLoilSFHicTSWunF6G1WHcZbq7ImG0mzbqu JaoS_1o4QtX9mrGnI.K99_b_VwODohysXIPgPSRuZljZB_M30yLfjDvN_b_rMOpNcvLqBdhnZMlg ynHQi7gmwyYgBbj1yrP8Umz4QLPh_Hxh3pOzIbGFPuX7_u24X2FtjXa4E2C9vsH8RE5aZp8LMqwH he_1wEopF9ngRPydGwZsxlhvXrH2WDkckT5dqHwT_pyBsm1uTHmwEzssDn7.GjNKdBCXRqxipZnG 28wtBq8dxdy_NsKoslFCXn1ajRZgE__Q13bHZym9rjWqrXC.8CyLXsZ6HcOlSo7sX3SGfbJI58td mRLvvE5DBCgJNbJeDiZvQZsojYDQYoYUNEGsoF8MUip7dmIH5IfpQidP4vH6pmnOoTAQh6WRm9dc 9t2GjNq03IduGJV4Tj1H5ErL_N6IvOouhgfuiVHJUmhbxfif2GO6My9D860wLQmO0pp2YCHMe.q1 BvJ3CS59IxYEeH2PNJs4hFnOJ6OJVcgq79NXK0OE26KnoPohs8Ryyi9Mw4kUqvUubeae1VqxRxuI 1nzZzUvB7nPHXCQfVPWtOfdzu75Obp8onm0nt5Q6hFkC29nBr4ZANpyUqTSYeUHLO3bC6xdSUGI4 p3cR3u8D2t38SpFB0FY7nEObaGR_yU1FTPsg_33C3BnZRHl1xYuGzMyUBtA8oKTSFuyOLSBn2Fbq zFO4zQqyZcATYILvCgRpvgp0TOY9ljl1R5ge9QRjCSlFbmOzat9Gw0PzWI8zVjljxaq3oLLHck3K RcG9T43Nk1rUhYdhF753otTW0Ry88J6O0e1OBLyj2ZwUxFRlyPgBQXzV1FOBccmPs35En2ZgHVf. pFY9pZhsg05JiMW0vTa6MNmpNT2dc6.kNHdtx_TfVOZB6PCDk_2mGSxQi6KsWI9qAQjI3fpeCfo1 hMrCOIL1D2YibGI6b4MsKfdQe2tTjF0ocIh8qJ2gfSCIGz17jgFSPUe1.W6IJK4mBAUkukyjkVCl Z9KsV2q4dizAh Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Mon, 13 Aug 2018 17:35:45 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp407.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7af08cc4af41d6adb610cf473cecf762; Mon, 13 Aug 2018 17:35:41 +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: <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> Date: Mon, 13 Aug 2018 10:35:38 -0700 Cc: Mark Johnston , John Kennedy , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@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: Mon, 13 Aug 2018 17:35:52 -0000 On 2018-Aug-12, at 8:36 PM, Mark Millard wrote: > On 2018-Aug-12, at 7:12 PM, bob prohaska = wrote: >=20 >> . . . >> Would 1024 be enough to turn OOMA off completely? That's what I = originally wanted to=20 >> try. >=20 [The 1024 is for vm.pageout_oom_seq.] I'm going to try a different wording about vm.pageout_oom_seq to address such questions: vm.pageout_oom_seq indirectly sets how long FreeBSD will tolerate Low Free RAM (by its Low Free RAM criteria). The "indirect" is because my wording is time based but the vm.pageout_oom_seq units are not. For a given environment smaller vs. larger is less time vs. more time. So, while one can make FreeBSD tolerate Low Free RAM longer (up to a point, apparently huge), no specific value directly turns off OOM (better: Low Free RAM) process killing. (Based on mathematical arithmetic. I've not analyze odd consequences of causing overflows for the code's details.) The approximation to turning off being intolerant of Low Free RAM is to have vm.pageout_oom_seq so large that you would not be willing to wait for the process kills to start. But the minimum for that is likely not obvious, so just use a fairly large figure for the int value for the architecture being tested. (rpi2 V1.1's and rpi3's have fairly large int types in C.) (I've assumed that the representation of vm.pageout_oom_seq is respected everywhere that it is used. If someplace mixes it with smaller types, this would need to be considered for what is "fairly large". This would require a code inspection.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Aug 13 18:53: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 E9C53107A5FF for ; Mon, 13 Aug 2018 18:53:35 +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 571A986F55; Mon, 13 Aug 2018 18:53: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 w7DIrpsC049914 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Aug 2018 11:53: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 w7DIroqT049913; Mon, 13 Aug 2018 11:53:50 -0700 (PDT) (envelope-from fbsd) Date: Mon, 13 Aug 2018 11:53:50 -0700 From: bob prohaska To: Mark Millard Cc: Mark Johnston , John Kennedy , freebsd-arm , bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180813185350.GA47132@www.zefox.net> References: <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> 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: Mon, 13 Aug 2018 18:53:36 -0000 On Mon, Aug 13, 2018 at 10:35:38AM -0700, Mark Millard wrote: > On 2018-Aug-12, at 8:36 PM, Mark Millard wrote: > > > On 2018-Aug-12, at 7:12 PM, bob prohaska wrote: > > > >> . . . > >> Would 1024 be enough to turn OOMA off completely? That's what I originally wanted to > >> try. > > > > [The 1024 is for vm.pageout_oom_seq.] > > I'm going to try a different wording about vm.pageout_oom_seq > to address such questions: > > vm.pageout_oom_seq indirectly sets how long FreeBSD will tolerate > Low Free RAM (by its Low Free RAM criteria). The "indirect" is > because my wording is time based but the vm.pageout_oom_seq units > are not. For a given environment smaller vs. larger is less time > vs. more time. > > So, while one can make FreeBSD tolerate Low Free RAM longer > (up to a point, apparently huge), no specific value directly > turns off OOM (better: Low Free RAM) process killing. (Based on > mathematical arithmetic. I've not analyze odd consequences of > causing overflows for the code's details.) > > The approximation to turning off being intolerant of Low Free > RAM is to have vm.pageout_oom_seq so large that you would not > be willing to wait for the process kills to start. > > But the minimum for that is likely not obvious, so just use > a fairly large figure for the int value for the architecture > being tested. (rpi2 V1.1's and rpi3's have fairly large int > types in C.) > > (I've assumed that the representation of vm.pageout_oom_seq is > respected everywhere that it is used. If someplace mixes it > with smaller types, this would need to be considered for what > is "fairly large". This would require a code inspection.) > I'll start with 1024 as "almost" ten times 120 and see what happens. Thank you very much for explaining in plain English what vm.pageout_oom_seq influences. I had no idea it was tied to free RAM, taking the reference to swap literally. I can't resist asking two dumb questions: First, why the confusing wording of the error message, is it shared with other tests? Second, wouldn't it be better to suppress the starting of new processes, rather than killing those already underway? Sort of like a harried clerk saying "take a number!". Another approach might be to write an entire process space to /tmp for restart when the crisis is over. Lousy for throughput, but it would keep folks away from the power switch. Many thanks! bob prohaska From owner-freebsd-arm@freebsd.org Mon Aug 13 20:15: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 4827C107C5EF for ; Mon, 13 Aug 2018 20:15:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-9.consmr.mail.gq1.yahoo.com (sonic308-9.consmr.mail.gq1.yahoo.com [98.137.68.33]) (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 C267C8AFAC for ; Mon, 13 Aug 2018 20:15:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 6IAKzPsVM1mmaoEtxCMk2.KzVZHtfAd1fNupIiHqEgnn.SdICsLikgO9HltgKfa gIbLnpXuafGsmBploO.m8ElvcNV_judvz7g_grkIWku1Wz2_bdRih_a.dhQS4LUlFuirBEmTWLpT pYb7rHYczruVCq2QZaijJDKPGjhkeiOonNjHlg9HIIOGUZYuKHYr2voGtGVWpUytN.cYKm_DEN6a tTYViKSRu8FwBiEKB2yIes916sSiGgZ.sRE4MKxrC1fAxD6JhfidacC5ugSgx3VH1LjHIeujftyq dGB_e1yoOMRDrYnBfUTBJ4FBLzeblJD9WGMzcc.n88r37uGBEkJEXDxyL.omvRGgG1.wW0uvHdo6 DMZgaP2z15j3_dmDaN.Got54KIJiR2iHsd.vEJsvMNfHIedCaM.4W8KIhkEDzf7p89hjm0Iz0T86 tTA8mdjJBnalG4F7gvgz5bgRgeMSxBkZb4imnUArA5GM3uoN_QpYuKouAZ7qKQ8OMK_m0eEITvDx AZ4uVO6Yl8UvTaEnTZJd6JiCFJBFAuJWU6NasG2IdGMqdb4I18WnbP_hGJd0KDsnjDup7NfZ7sem Wn2LEcwa7_N2J7XDFmG29dQBRjSJCYVwFqpndvHOf_1laoKIzz5Y6k88Ew1h6LFLWxA4fNygqjzc fHL9iSDizik6Ua_An1f4kXLxylBPiUNYT.CTQh9aqFqNbwkpDVqQxA3p9pHBX5j74uZvpvsfwekD 5CeX06F5hWd7h8M_zCTfXqoHQNcjcp9nXWSuRUYPK2zmnyirJt.iFAWpCCUhQu52OOmAaH0A_G8a M54c6U91nKoH.JPOVD6IfKFHu_nj8ePjpSTChrFL_.jO8Og9BU8qcJwPPZ5VisLpDAs7Q_Ny7Fnw IsE8_Sju3VqoCJrHEIY80U3O55jsLwRxOVzLuBfSPN3GoN7PQN4dd.Ty2Hf.awSSLpiww4bgxojN CpylgXpra_6vCSqHna7qh79BYbkt9a4PHgs7JI4P3dPyotYbl_A5pQSafB9TUI4Y7QIfjCL1oplu rsiFYsUL2jHA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Mon, 13 Aug 2018 20:15:48 +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 1f8ea332bef4cf0752c370d22f4df331; Mon, 13 Aug 2018 20:05: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 ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180813185350.GA47132@www.zefox.net> Date: Mon, 13 Aug 2018 13:05:38 -0700 Cc: Mark Johnston , John Kennedy , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@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: Mon, 13 Aug 2018 20:15:56 -0000 On 2018-Aug-13, at 11:53 AM, bob prohaska wrote: > On Mon, Aug 13, 2018 at 10:35:38AM -0700, Mark Millard wrote: >> On 2018-Aug-12, at 8:36 PM, Mark Millard = wrote: >>=20 >>> On 2018-Aug-12, at 7:12 PM, bob prohaska = wrote: >>>=20 >>>> . . . >>>> Would 1024 be enough to turn OOMA off completely? That's what I = originally wanted to=20 >>>> try. >>>=20 >>=20 >> [The 1024 is for vm.pageout_oom_seq.] >>=20 >> I'm going to try a different wording about vm.pageout_oom_seq >> to address such questions: >>=20 >> vm.pageout_oom_seq indirectly sets how long FreeBSD will tolerate >> Low Free RAM (by its Low Free RAM criteria). The "indirect" is >> because my wording is time based but the vm.pageout_oom_seq units >> are not. For a given environment smaller vs. larger is less time >> vs. more time. >>=20 >> So, while one can make FreeBSD tolerate Low Free RAM longer >> (up to a point, apparently huge), no specific value directly >> turns off OOM (better: Low Free RAM) process killing. (Based on >> mathematical arithmetic. I've not analyze odd consequences of >> causing overflows for the code's details.) >>=20 >> The approximation to turning off being intolerant of Low Free >> RAM is to have vm.pageout_oom_seq so large that you would not >> be willing to wait for the process kills to start. >>=20 >> But the minimum for that is likely not obvious, so just use >> a fairly large figure for the int value for the architecture >> being tested. (rpi2 V1.1's and rpi3's have fairly large int >> types in C.) >>=20 >> (I've assumed that the representation of vm.pageout_oom_seq is >> respected everywhere that it is used. If someplace mixes it >> with smaller types, this would need to be considered for what >> is "fairly large". This would require a code inspection.) >>=20 >=20 > I'll start with 1024 as "almost" ten times 120 and see what happens. >=20 > Thank you very much for explaining in plain English what=20 > vm.pageout_oom_seq influences. I had no idea it was tied=20 > to free RAM, taking the reference to swap literally.=20 The "out of swap space" in: Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: out = of swap space is just wrong relative to what drives the killing. The swap space may or may not be low, that depends on the overall set/number of processes and their properties. This whole investigation would have been better directed up front by different text in the message. > I can't resist asking two dumb questions: > First, why the confusing wording of the error message, is it shared = with other tests? The wording might go back to 4.4BSD when swapping of running processes was done and the kills likely did not happen until such swapping became unavailable via swap space limitations for the configuration. For FreeBSD it is very misleading to anyone not already familiar with FreeBSD's choices in this area. (That would be me before finding the material that I quoted from the book.) > Second, wouldn't it be better to suppress the starting of new = processes, rather than > killing those already underway? Sort of like a harried clerk saying = "take a number!". Nothing says that attempts to create new processes are going on in all workloads with the issue. And if Free RAM is already low, it would stay low. Just one process that keeps a sufficient number of pages in the "Active" category for an environment and stays runnable all the time can lead to kills of processes that are not subject to being swapped out. > Another approach might be to write an entire process space to /tmp for = restart when the > crisis is over. Lousy for throughput, but it would keep folks away = from the power switch. Sounds like you just specified a form of swapping, /tmp not being fundamental. In other words: more like 4.4BSD style, not FreeBSD style. Here there is architecture choice and goals/primary contexts. FreeBSD is never likely to primarily target anything with a workload like buildworld buildkernel on hardware like rpi3's and rpi2 V1.1's and Pine64+ 2GB's and so on. And if things were still like gcc 4.2.1 for what it takes to build the toolchain, this likely would not have been noticed on such hardware. The big change has been what it takes to build the toolchain instance(s) that other stages of buildworld buildkernel use. That is the change in the workload that requires changes in the likes of vm.pageout_oom_seq for buildworld buildkernel --or just finding a -jN figure that avoids leading to Low Free RAM for the environment(when possible). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Aug 13 21:16: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 3B0B1107DF02 for ; Mon, 13 Aug 2018 21:16:23 +0000 (UTC) (envelope-from tuexen@fh-muenster.de) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4A228DA0F for ; Mon, 13 Aug 2018 21:16:22 +0000 (UTC) (envelope-from tuexen@fh-muenster.de) Received: from [192.168.1.6] (p57BB4A87.dip0.t-ipconnect.de [87.187.74.135]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 54E59721E282F; Mon, 13 Aug 2018 23:16:11 +0200 (CEST) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_41DC1485-66C9-4A49-AF1E-F79E10FDBC28"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: anyone working on armv8crypto? Date: Mon, 13 Aug 2018 23:16:08 +0200 In-Reply-To: <20180813162935.GK97145@funkthat.com> Cc: freebsd-arm@FreeBSD.org To: John-Mark Gurney References: <20180813162935.GK97145@funkthat.com> X-Mailer: Apple Mail (2.3445.9.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de 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, 13 Aug 2018 21:16:23 -0000 --Apple-Mail=_41DC1485-66C9-4A49-AF1E-F79E10FDBC28 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 13. Aug 2018, at 18:29, John-Mark Gurney wrote: > > Is anyone working on expanding the support of the armv8crypto module? > > Right now it only supports AES-CBC, and missing a number of other > useful ciphers, like -GCM and -XTS (geli encryption). It also > doesn't support the SHA1 or SHA2 hashes either. I'm planning to work on SHA1 and SHA2, but can't right now provide a firm deadline... Best regards Michael > > If you are, please let me know! > > Thanks. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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" --Apple-Mail=_41DC1485-66C9-4A49-AF1E-F79E10FDBC28 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODA4MTMyMTE2MDlaMCMGCSqGSIb3DQEJBDEWBBQWV2OfcFx3Ljkk2Hl9 lQxiRYeZGDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQBJIDQtYGuG3DVyQdu8csI0paYyptOihmuK EC9n7qRIXmFI/3wki7mOgciXysSCowtKKYCzVCFMQm+zkkvgXMhvczdgAoVV9z63dT9kjLNPOGOT Cg25XsSZYzT3Q53aJitcsxrgHcfrpIfYdP26X/iZ0pC+aJyAHcrrAtwuon7FYDmNMKEVHxWg0Po1 oollyfuxQuRx+HpH9sF9kbQWG65DICmCVuSMt9tTlMjtoEPcUUci5btwC+rvan8fnDPfyg0k7FoD D7G/+8ixj31X+2HHBsXdAGkJpu801iFo4A07CqyhQfZYnWoyngfJsBe6hRtbB3UhYI9ERiVCaXUW xLoPAAAAAAAA --Apple-Mail=_41DC1485-66C9-4A49-AF1E-F79E10FDBC28-- From owner-freebsd-arm@freebsd.org Tue Aug 14 01:42: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 DD08510607BD for ; Tue, 14 Aug 2018 01:42: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 3D3F8772EA; Tue, 14 Aug 2018 01:42: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 w7E1gRWb050986 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Aug 2018 18:42:27 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7E1gQG7050985; Mon, 13 Aug 2018 18:42:26 -0700 (PDT) (envelope-from fbsd) Date: Mon, 13 Aug 2018 18:42:26 -0700 From: bob prohaska To: Mark Millard Cc: Mark Johnston , John Kennedy , freebsd-arm , bob prohaska Subject: Re: RPI3 swap experiments (grace under pressure) Message-ID: <20180814014226.GA50013@www.zefox.net> References: <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@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, 14 Aug 2018 01:42:18 -0000 [Altered subject, philosophical question] On Mon, Aug 13, 2018 at 01:05:38PM -0700, Mark Millard wrote: > > Here there is architecture choice and goals/primary > contexts. FreeBSD is never likely to primarily target > anything with a workload like buildworld buildkernel > on hardware like rpi3's and rpi2 V1.1's and > Pine64+ 2GB's and so on. > I understand that the RPi isn't a primary platform for FreeBSD. But, decent performance under overload seems like a universal problem that's always worth solving, whether for a computer or an office. The exact goals might vary, but coping with too much to do and not enough to do it with is humanity's oldest puzzle. Maybe I should ask what the goals of the OOMA process serve. I always thought an OS's goals were along the lines of: 1. maintain control 2. get the work done 3. remain responsive There's at least some degree of conflict between all of them, made worse when the workload grows beyond the design assumptions. The RPI makes the issue more visible, but it's always lurking. OOMA seems to sacrifice getting work done, potentially entirely, in support of keeping the system responsive and under control. To have some fun with the office analogy, when business is slow the clerk serves customers as they come in. When things get busy, the clerk says "take a number". When they get really busy new customers are told "come back tomorrow" and when they get absolutely frantic present customers are told "I can't finish this now, I'll call you when it's done". That's grace under pressure. What do FreeBSD's designers want the system to do as it's progressively overworked? Is the office analogy too ambitious? Thanks for reading, and apologies for the ruminating. bob prohaska From owner-freebsd-arm@freebsd.org Tue Aug 14 04:39:30 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 DAA31106AFC7 for ; Tue, 14 Aug 2018 04:39:29 +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 649EE7DCAF; Tue, 14 Aug 2018 04:39:29 +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 w7E4c565010629 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Aug 2018 21:38:05 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w7E4c5md010628; Mon, 13 Aug 2018 21:38:05 -0700 (PDT) (envelope-from warlock) Date: Mon, 13 Aug 2018 21:38:04 -0700 From: John Kennedy To: Mark Millard Cc: bob prohaska , Mark Johnston , freebsd-arm Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180814043804.GE81324@phouka1.phouka.net> References: <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Tue, 14 Aug 2018 04:39:30 -0000 First off Mark, well said. It's a pity to edit so much of it out. On Mon, Aug 13, 2018 at 01:05:38PM -0700, Mark Millard wrote: > Here there is architecture choice and goals/primary contexts. FreeBSD is > never likely to primarily target anything with a workload like buildworld > buildkernel on hardware like rpi3's and rpi2 V1.1's and Pine64+ 2GB's and so on. It's masochistic, but I think it's important to be able to recompile the FreeBSD platform. It's independent, it's standalone, and it doesn't depend on something else to give it life. I remember when BSD and it's predecessors ran on a lot less power than a RPI. Of course, everything was smaller then. You can pry my nice, modern computer with fast CPUs and fast disk out of my cold dead hands though. (: > And if things were still like gcc 4.2.1 for what it takes to build the > toolchain, this likely would not have been noticed on such hardware. The big > change has been what it takes to build the toolchain instance(s) that other > stages of buildworld buildkernel use. That is the change in the workload that > requires changes in the likes of vm.pageout_oom_seq for buildworld > buildkernel --or just finding a -jN figure that avoids leading to Low Free > RAM for the environment(when possible). I've been running vmstat in a loop during the whole build process (haven't finished a whole run yet). With 1G, I'm sort of begrudging ntpd it's 18M of resident RAM, but the top-5 and only running processes are by far and large the build processes (as sorted by resident memory). As you note, looking to have as much free RAM as possible (paging, not swapping since long delays in swread means I'm not crunching code). This run is -j4, and I expect I'll try a -j3 for the "fun" of it. As you note, doing some swapping isn't bad, as long as I'm not wasting so much time that my workload would run faster with -j3 and more RAM being available. It's true that a RPI is not my choice for disk-I/O workloads. And not enough RAM to keep it there, either but it's way better than some. I'd love to have a whole host of little IoT RPIs running FreeBSD if I wouldn't want to patch them all the time. From owner-freebsd-arm@freebsd.org Tue Aug 14 07:09: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 16325106E93C for ; Tue, 14 Aug 2018 07:09:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.ne1.yahoo.com (sonic312-23.consmr.mail.ne1.yahoo.com [66.163.191.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 950BA81FA7 for ; Tue, 14 Aug 2018 07:09:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: n8ZTi3gVM1nPafWBceoDh7OMOjifB7cHSz.y.IeTie72wbJMEm2HBLwf4A9K3uB OHssnShRXLdSHXvwyD8R2HoeQ69WKYYBxHRzpFdt1ExKxXOrVxIr9Fcam.7GlK4Z4BgpS53kNdD2 67Wei0A1Gn1l_LyxTOxPbGkgF6XHCM73q4hUgncz1bFVJebwLCmVFK2_Lg6K8zpr7cy4iMlK_UVb JuYM0ri3bwZALOBUjq3yb0xHxiUQETeB1zl4yqcHKGaSTAGJCkDE1BR1LwbRBZWVNJaSYRJiZljQ .QRCUOwidM6EbZ0D8hO_Wf.NROTABAdB3Lvp4ZAQb7lPqkxC36tXGISxM_hAce8O49EBEAlUBari fiPkX2Eckt_bxBh_jiNFCpCdx.e5mhZgqzq.SvKi62BC3TuGxLssRB1rNZsXXKGuxRHvZDu8.xFs h1GEIDDhupivj_ioOcOyXgLB4jfjRyaKCGMPyoaXb2yPbzm4VK8cGfrVhzn85EI1QZtf0ABP6W4v Z2Md0_X4mkJhc3hPWQXQkzXl082b7xzSuSbCMvzcxYpbFDLYUQ76nf8ksTK2ACmY6UgsxmOqrock uuGlWsfoR1cpY82v74cMnpF2UhAQcHpCKLL.jhzUWlEhhbU_ItJSloGKhIx2erowWu1k_hVAFfAo DvnpiF4LlTZ8.Z7VM8IBMIIvl77lsYF5aQEONRTHqoxfBhhZ.HKCgT7pk6BZ7kUVHxFJaXiCEQsP zDmjHyFtB1ylZV1bhgwgDB.mbG0sGSiE4hERZM8j3BVb1_B_9oPRRVuZ4uL6XndfgWKPfp_TZKXI BErDHYLA95nDxju6YuO4H9G1jPlhU9SkgBQKfLwxMS.duwr3QuEgD5Obc0n9UIJ_5o9ZYm7W7lrm QyQ9_8O9cOwSIOZI0nGpuO2FY1pIgOa2FXXEj7cCu1sWKbNJqe.iEaAwj8lowt89pBQhiqc8TnRu g11w9Iwh9mwcW_a.uDMIs6k8zvc8B_4RnH0DqQIQdHGPvwsWZNhPCRQt1XVBAsxk_RwNOcjpWaPD WBJjLFn4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Tue, 14 Aug 2018 07:09:45 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0489c294de1e80ac546a37a23229b753; Tue, 14 Aug 2018 07: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 (grace under pressure) From: Mark Millard In-Reply-To: <20180814014226.GA50013@www.zefox.net> Date: Tue, 14 Aug 2018 00:09:42 -0700 Cc: John Kennedy , freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <44459672-F494-4DE9-B055-A466BE3253C9@yahoo.com> References: <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@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, 14 Aug 2018 07:09:52 -0000 On 2018-Aug-13, at 6:42 PM, bob prohaska wrote: > [Altered subject, philosophical question] > On Mon, Aug 13, 2018 at 01:05:38PM -0700, Mark Millard wrote: >> >> Here there is architecture choice and goals/primary >> contexts. FreeBSD is never likely to primarily target >> anything with a workload like buildworld buildkernel >> on hardware like rpi3's and rpi2 V1.1's and >> Pine64+ 2GB's and so on. >> [I'm not a FreeBSD designer and have never been one. The below notes suggest my guesses as to their choices for what to primarily target. But I do not plan on continuing for the "philosophical question".] > I understand that the RPi isn't a primary platform for FreeBSD. > But, decent performance under overload seems like a universal > problem that's always worth solving, whether for a computer or > an office. The following uses a very specific example of a rather different context from the tiny board computers. When I have access to the Ryzen Threadripper 1950X with 96 GiByte or 128 GiBytes of RAM installed I do not have this type of problem with -j32 (16 two-thread cores). (It has been a couple of months since I last did this.) No need to adjust vm.pageout_oom_seq . (In fact I was unaware of that control until recently.) In fact even for the 96 GiByte configuration I can poudriere bulk -a allowing 32 jobs that are reach allowed up to 32 active processes during the build of all the ports. The paging/swapping and "disk" I/O are fast and the RAM limits their use. (There are way over 20,000 ports that attempt to build when I do this. Frequently multiple tools chains build in significantly overlapping time frames, including multiple llvm's at once. If I remember right the build takes something like 36 hours, but it has been a fair time since I've run such a test.) [I'll note that the worst-case conditions of 32 jobs each actually using 32 active processes has never been closely approached when I've attempted this. But having hundreds of active processes at times does happen. But not hundreds of large-RAM-active-usage processes that each stay active over long periods.] It is an environment effectively designed for the type of activity, fitting FreeBSD's principles of operation, but scaled based on probabilities for the combinations of jobs that occur at once. (And it well covers buildworld buildkernel --which is primarily what I've used it for.) It is a very different environment from trying to get the the most out of a fairly minimal environment for the software involved. There is also a huge difference in cost. At least for now this 1950X context does not need "the" problem solved: it is not a problem so far. I.e, free RAM does not stay low for long so far. [Note: I'm not aware of any significant problem with a default of vm.pageout_oom_seq=120 or some such for the contexts that I deal with. But vm.pageout_oom_seq was added because an (implicit?) fixed figure was a problem before the addition. My earlier earlier text tries to generalize beyond the specifics for vm.pageout_oom_seq .] > The exact goals might vary, but coping with too much > to do and not enough to do it with is humanity's oldest puzzle. Trying to well span all the combinations without sometimes problematical tradeoffs is an unsolved problem. FreeBSD has picked what type of range it primarily targets and covers some other contexts in ways that fit with that. > Maybe I should ask what the goals of the OOMA process serve. > I always thought an OS's goals were along the lines of: > 1. maintain control > 2. get the work done > 3. remain responsive > > There's at least some degree of conflict between all of them, > made worse when the workload grows beyond the design assumptions. > The RPI makes the issue more visible, but it's always lurking. See above about the 1950X example: not always an active issue for the specific issue involved that this started from. > OOMA seems to sacrifice getting work done, potentially entirely, > in support of keeping the system responsive and under control. FreeBSD expects explicit management of the RAM use for whatever the general type of work is (such as using a smaller -jN for buildworld buildkernel --or vm.pageout_oom_seq assignment), and expects configurations designed to have the desired performance characteristics for the management technique used. (The two are not independent.) FreeBSD does not attempt to provide a universal, automatic management of RAM use that gets all potential forms of work done. FreeBSD is not designed to get maximal results from minimal hardware without explicit management, so: not automatic. > To have some fun with the office analogy, when business is > slow the clerk serves customers as they come in. When things > get busy, the clerk says "take a number". When they get really > busy new customers are told "come back tomorrow" and when they > get absolutely frantic present customers are told "I can't finish > this now, I'll call you when it's done". That's grace under pressure. Can you imagine types of computer-server contexts were such latency additions to much/most/all new incoming work is not acceptable? Where having some "failed try again"s for just some specific work examples would be better than adding notable latency to all the incoming work when things are not going well? Is everything having to wait to sometime later, such as the next day, or even far less time, called "server down" in some contexts, even if the OS on the server is still running? [I'm not claiming the existing Low Free RAM process-killer behavior is a direct solution. But it does can avoid swapping latencies automatically being involved.] (My activities are not in such server contexts but FreeBSD does not target my activities.) > What do FreeBSD's designers want the system to do as it's > progressively overworked? Is the office analogy too ambitious? > My earlier text suggests some of my expectations for this, but I can not speak for the historical or modern FreeBSD designers. They would have to confirm or deny various of my expectations and provide points I've not even considered. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Aug 14 07:56:30 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 2E6AB106F5DE for ; Tue, 14 Aug 2018 07:56:30 +0000 (UTC) (envelope-from pcrilly@goodgas.com.au) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 B9D528342C for ; Tue, 14 Aug 2018 07:56:29 +0000 (UTC) (envelope-from pcrilly@goodgas.com.au) Received: by mail-it0-x22e.google.com with SMTP id j81-v6so16983305ite.0 for ; Tue, 14 Aug 2018 00:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=goodgas-com-au.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=P2ZWeUDjFEg/YNc38XuQHvzEv78Hsr6A7UTvTiVSlCk=; b=EV0cPUGfu8R8J7T2J3ZjWVKCZnbaKwq5JL1MQC5vVvfM/b5ehBmhFXiqU6mNQ1hmsc 5fxTnbJHSAcKs0eWuVymrxqVAIvJyLVdLapttzUUdHwPyqFlwzPviC/dslPY1y2yzgR6 6kkRH68d8XQsDQBKR02yZtF/+zqEAf4JNehGIVPmpCf0OXK2SDx0vqhb8bGnrc3xOm7M bAtwKISe6KXNle48XPYMbt9ta3zOqAzS2A4YAIWnYLt7OODnkPMZXRTBXY7DlQgcXeNB 8SPskqEI5i2x2VITHyRzUoB5SXgLC50FrJX96v2K9AD1x5dPOERSVEwluhbS3yU8Ge5J yZzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=P2ZWeUDjFEg/YNc38XuQHvzEv78Hsr6A7UTvTiVSlCk=; b=gMaJ3E2XPtlTGML8O5TkHPQ5S1kt1L6cOct5XuOvKi4GpV5iLeqdtsrCUehdlbvQSp cFphTMK7EVIEhpPIj+tVLSgWhSOKGkQTZnPw/AEuZzp3qUyZXbrQGnamLNOgCxfN4k/q HURICkivtLvPQ25J0R/rtniuceVoToscWwDU7K/QeKoXYug49piilWDg9dnl5LPfCNii S1oFcqt/vXWEyVUxOUhqB/W03McqNwCNGz4OkayyPQecpN46vlaLsFocFNzqYMJyle4Z NppWmBLdgePbecjmsLISQhyuV30vFNZLCil3FzbPhNNqCR700IXnpo/kqac/FPaTj+YN KRdA== X-Gm-Message-State: AOUpUlGmTP7vW2VRBo78HvNnqULLVWnSKhlW3rho+KhDUG6iu0JMQd7t PSk8OlcAfwy7uhua0JG7GJBGSXtFmBc= X-Google-Smtp-Source: AA+uWPwqGDrvUdDuaglLao8zp1HHlIbsEoWecmNs2bfnqCrg8+5MmYkbaB6AIisrLcnw/H4J7776lA== X-Received: by 2002:a24:64d8:: with SMTP id t207-v6mr13534996itc.84.1534233387773; Tue, 14 Aug 2018 00:56:27 -0700 (PDT) Received: from [10.190.0.10] ([117.20.4.26]) by smtp.googlemail.com with ESMTPSA id z3-v6sm14255946ioz.85.2018.08.14.00.56.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 00:56:27 -0700 (PDT) Subject: Re: RPI3 swap experiments (grace under pressure) To: freebsd-arm@freebsd.org References: <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> From: Patrick Crilly Message-ID: <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> Date: Tue, 14 Aug 2018 17:56:20 +1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180814014226.GA50013@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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, 14 Aug 2018 07:56:30 -0000 On 14-Aug-18 11:42 AM, bob prohaska wrote: > [Altered subject, philosophical question] > On Mon, Aug 13, 2018 at 01:05:38PM -0700, Mark Millard wrote: >> Here there is architecture choice and goals/primary >> contexts. FreeBSD is never likely to primarily target >> anything with a workload like buildworld buildkernel >> on hardware like rpi3's and rpi2 V1.1's and >> Pine64+ 2GB's and so on. >> > I understand that the RPi isn't a primary platform for FreeBSD. > But, decent performance under overload seems like a universal > problem that's always worth solving, whether for a computer or > an office. The exact goals might vary, but coping with too much > to do and not enough to do it with is humanity's oldest puzzle. It's a very difficult problem to solve.  And provokes some pretty heated arguments. If you are experiencing overload, then there's a case for saying the platform/system isup to the task. > > Maybe I should ask what the goals of the OOMA process serve. > I always thought an OS's goals were along the lines of: > 1. maintain control > 2. get the work done > 3. remain responsive > > There's at least some degree of conflict between all of them, > made worse when the workload grows beyond the design assumptions. > The RPI makes the issue more visible, but it's always lurking. > > OOMA seems to sacrifice getting work done, potentially entirely, > in support of keeping the system responsive and under control. I believe the thinking is that if the system remains remains responsive you have a chance of fixing the problem or at the very least you can login and gather information about what is causing the problem. > > To have some fun with the office analogy, when business is > slow the clerk serves customers as they come in. When things > get busy, the clerk says "take a number". When they get really > busy new customers are told "come back tomorrow" and when they > get absolutely frantic present customers are told "I can't finish > this now, I'll call you when it's done". That's grace under pressure. Nice analogy. If people just keep coming all day, I think what you've described is a responsive system. The clerk isn't getting any work done,  he's just responding to customers.  And would "can't finish it now" be analogous to killing  off processes? > What do FreeBSD's designers want the system to do as it's > progressively overworked? Is the office analogy too ambitious? > > Thanks for reading, and apologies for the ruminating. > -- "With great power comes great electricity bill" From owner-freebsd-arm@freebsd.org Tue Aug 14 10:28:31 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 6BF2A1073A59 for ; Tue, 14 Aug 2018 10:28:31 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD3A288DE4 for ; Tue, 14 Aug 2018 10:28:30 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-qk0-x235.google.com with SMTP id v17-v6so12972716qkb.11 for ; Tue, 14 Aug 2018 03:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3wkyr1lVrcWI+q8UOOEsXOIuRXhs/vybR11zIPJvUF0=; b=mN+UqxEH7i05fkB6lgkfj1tFzq24+ZeXCk3ORyN3Vn7ZYHvQOlOhZc36N4vMPHtevT dOKXqVVhjgwMJnKSTUgriWaKs31Icy8Jd+y8dwnSsJ49wffB5mFUXMWiXU4OzbwY2s8Q 14b1OV+0X4nsTIomdi7rIIXe2UrLdCTL6pj5jpVV58tUUgapm4SgvfmZmEM/7wRqTdMx 8fQQkvn0mg0q2jLxp8W2URDXbcIZFsKFyl2RC4p0wY2hAigcmaBB4DfjqylluP0wkZh+ +PpRoljygTUgFAjhkOkSGhZoc8MFNdWTqhPegLH8J5/17hwCjtY4OVwisGKvEgFFSt6N tIxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3wkyr1lVrcWI+q8UOOEsXOIuRXhs/vybR11zIPJvUF0=; b=IYrNNLxvDhUwFpqQM0weeNBAoFoEbrD3oopp8i0N6xaJa4TB4iPPpMbe4NZBfL5tEY op3O+43qRjbs7L5Sm3viO34T4G5Fx/Cp0TxxcyYhNtJ8NA6L/ekgN3nsKHKIJmEK966D yZPyqQrnrmmfTOelCphmoByMjb0tXj2z2+8V+fzF9EAxtb+jIkVgJaxiSoFtdMwsFg/N LdGgvJ1hck1FEK/IlV0u1aOUC/9lOqG1CRmPghlWjg1vGeannSwdNs8xVoKocv8OMAWA eWBoFZbMbAgvHlZo8xnjY7AIqnPB50d5scJ0QzpYg1hRMRxjNX2UgLiARj7tKge9EqGU ri2w== X-Gm-Message-State: AOUpUlEA1rgWzXY8IFQvnyscPcYKEsj/reUYukYOEEHL+1U90Gjy/Zth PcTw1WCzIy1nRvNOGeDJmhwMxAcT6tsHG3aQg3wq918ndgk= X-Google-Smtp-Source: AA+uWPyt/mStdN2D7zPxiSs54Ve0tptRPkRzEKbsvopVK4aAtUVDgmf8GAlgKOP72xSBppayeLL3X0UumO6dL4ycTU4= X-Received: by 2002:a37:5347:: with SMTP id h68-v6mr18652987qkb.21.1534242510285; Tue, 14 Aug 2018 03:28:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:29c3:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 03:28:29 -0700 (PDT) In-Reply-To: References: <1533577708.4175.0@hraggstad.unrelenting.technology> <1534020520.35460.1@hraggstad.unrelenting.technology> From: Ganbold Tsagaankhuu Date: Tue, 14 Aug 2018 18:28:29 +0800 Message-ID: Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Greg V Cc: freebsd-arm 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: Tue, 14 Aug 2018 10:28:31 -0000 On Tue, Aug 14, 2018 at 12:08 AM, Ganbold Tsagaankhuu wrote: > > > On Sun, Aug 12, 2018 at 4:48 AM, Greg V > wrote: > >> >> >> On Sat, Aug 11, 2018 at 3:09 PM, Ganbold Tsagaankhuu >> wrote: >> >>> >>> >>> On Tue, Aug 7, 2018 at 1:48 AM, Greg V >>> wrote: >>> >>>> Hi, >>>> >>>> I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64 ROCKPro64 >>>> board): >>>> >>>> https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 >>>> >>>> >>> Very nice. I have NanoPC-T4 board and will test your patch. >>> Did you try to load kernel via tftp at u-boot prompt? like: >>> >>> tftpboot 0x02000000 kernel.bin, go 0x02000000 >>> >>> Does it work for you that way? >>> >> >> kernel.bin?? EFI has always been the way to go with aarch64 (and I think >> it's even recommended on armv7/6 too). >> >> I do it like this: >> >> env set serverip 192.168.1.2 >> env set bootargs boot.nfsroot.server=${serverip} >> boot.nfsroot.path=/some/path comconsole_speed=${baudrate} >> tftpboot ${kernel_addr_r} loader.efi >> tftpboot ${fdt_addr_r} dtb/rockchip/rk3328-rock64.dtb >> bootefi ${kernel_addr_r} ${fdt_addr_r} >> >> But the more-automated way (fully configured by dhcp) should work too, at >> least if you don't have dhcp and tftp on different servers >> > > > Thank you. > I've managed to boot NanoPC-T4 board with your patches using loader.efi on > fat partition on SD card: > > http://dpaste.com/0Y00M4B > > I used rk3399-rockpro64.dtb, as rk3399-nanopi4-rev00.dtb is somehow not > working for me. > Finally managed to do network boot to multiuser: http://dpaste.com/2573EV8 Maybe will try again rk3399-nanopi4-rev00.dtb. Ganbold > > Ganbold > > > > > > From owner-freebsd-arm@freebsd.org Tue Aug 14 11:01: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 48B011074687 for ; Tue, 14 Aug 2018 11:01:48 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 DAC8B89EF6 for ; Tue, 14 Aug 2018 11:01:47 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-qt0-x22d.google.com with SMTP id c15-v6so20640231qtp.0 for ; Tue, 14 Aug 2018 04:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7S2yACHhc7FQzq0czdnxfnRVDUZmSt4Fd3hLASOcMe4=; b=ckq1NbDowNOH8YaVdU1ehvg6nhN5VypfkD8H+TP9bdnSgpOh1LeFgMtHnmwJoX86Y9 J7USTPiH4Ktwkx45palvkBZjzF4COIWw8Rd7n+U6RIclXv1JUwKmW+A7ENkMDzhoi67H Hd2iyUNvxC5eRhFpwFCV7W7U1+G4ZDDtL1fkXOCyp99Qoe7Q19a0VEYJ3GGpTMV/pp7W n8M78x37dVBexDTiviH/BIyr1RJ6TgLNDT1A+Q5nbIfjM1zDnouDaZeVSpVP1mVAvdMp WpIq2FB00OKHN9YzRA699eOwOHqmBUrkdXk6xFuuyRoAOuuBiW7EadbK3UZqRmOre37Q 034w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7S2yACHhc7FQzq0czdnxfnRVDUZmSt4Fd3hLASOcMe4=; b=Rwp2UW7yP9kaOYFoJCpy3qaqa8Sh8n/lYF1mFN9hjj51X9KJcK+ewWfUR3SzZG520M 6i/JGhhp1chXyDpANRe7XZ/34/75UvcENFPL1xsRJ4BF5+p27mxHlGfFaeCOxNr7s7Vr 2onuBtU/CskG6Ul79SJIIRSVdiQUWkSMtrw8Ut9rIAM9kPOO3lLaCbfRY7fOinfE0bXi R+ll8eL1Q10nfj82Va7NltOvznr85bBne9cZFxczGmPc4udvo2tEAy6eNzjul0yVhdTs Ji+2ItR5Fm2j3SAcWYwjA5sO0rjQX/l6ofszzi2+xfu9JfUCJEY37cM8pE1rVviWHOG6 QLVg== X-Gm-Message-State: AOUpUlH9+PbKLHWh5AKCGYWtGVzmIaRghzMpxIQohB+jQL1byd5Q+1nx WqUopJIt87kAiNLkTJd1hcu5kc+bYHkCybUt9+5Dmou3TDw= X-Google-Smtp-Source: AA+uWPy3OLVVCdwS5iWm47JMsxKtPTlHX3aFj8o0FG9CzavDMAxj/52njfDAZZggk7PDMkj6geoSOs/5YoFGNJqGmz0= X-Received: by 2002:ac8:3885:: with SMTP id f5-v6mr20985127qtc.337.1534244507265; Tue, 14 Aug 2018 04:01:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:29c3:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 04:01:46 -0700 (PDT) In-Reply-To: <1533577708.4175.0@hraggstad.unrelenting.technology> References: <1533577708.4175.0@hraggstad.unrelenting.technology> From: Ganbold Tsagaankhuu Date: Tue, 14 Aug 2018 19:01:46 +0800 Message-ID: Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Greg V Cc: freebsd-arm 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: Tue, 14 Aug 2018 11:01:48 -0000 Greg, On Tue, Aug 7, 2018 at 1:48 AM, Greg V wrote: > Hi, > > I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64 ROCKPro64 > board): > > https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 > > As with the ROCK64, boot is over the network. To boot, dd ayufan's ubuntu > image onto an sdcard and Ctrl-C the linux boot on the kernel selection > screen. U-Boot on SPI flash is not available yet. > > Unfortunately, performance is very disappointing =E2=80=94 I think the bi= g > cluster's default frequency is very low. > (Everything runs faster if cpuset to the LITTLE cores.) > > Looks like we'll need a driver for the "rockchip,rk808" PMIC to make > cpufreq_dt work=E2=80=A6 > Also my attempt at the clock driver is very incomplete ;) > Can you change the patches according to style(9) for phabricator review ( https://reviews.freebsd.org) and send them to me? I think full files should be fine too. thanks, Ganbold > > _______________________________________________ > 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 Tue Aug 14 12:43:12 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 6CCE1107701F for ; Tue, 14 Aug 2018 12:43:12 +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 03D0D8D4C6; Tue, 14 Aug 2018 12:43: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 w7ECfsvn047288 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Aug 2018 05:41:54 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w7ECfrwp047287; Tue, 14 Aug 2018 05:41:53 -0700 (PDT) (envelope-from warlock) Date: Tue, 14 Aug 2018 05:41:53 -0700 From: John Kennedy To: bob prohaska Cc: Mark Millard , Mark Johnston , freebsd-arm Subject: Re: RPI3 swap experiments (grace under pressure) Message-ID: <20180814124153.GF81324@phouka1.phouka.net> References: <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180814014226.GA50013@www.zefox.net> 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: Tue, 14 Aug 2018 12:43:12 -0000 On Mon, Aug 13, 2018 at 06:42:26PM -0700, bob prohaska wrote: > I understand that the RPi isn't a primary platform for FreeBSD. > But, decent performance under overload seems like a universal > problem that's always worth solving, ... I don't think anything we're talking about explicitly rules out the RPI as a platform, one way or the other, except in it's ability to soak up abuse. I think what you're pitching is basically a scheduling change (with what tasks get run, with a not insignificant trickle-down to how they're swapping). I think the "general case" is "plan your load so everything runs in RAM" but knowing that there is generally a 80/20 rule (don't get hung up on specific numbers -- there is a line, I'm sure it'll move around) of memory that doesn't need to stay resident to memory that does. Oversubscription. And as far as the scheduler goes, it just ends up with a mess of dynamic needs. Personally, I consider swap as a kludge and a type of overdraft protection. I'm writing a bunch a bunch of checks and I hope they won't all get cached (sorry, pun) at the same time but sometimes that is beyond my control. > There's at least some degree of conflict between all of them, > made worse when the workload grows beyond the design assumptions. > The RPI makes the issue more visible, but it's always lurking. I think slow peripherals and lack of memory are the targets. I'd never stick my swap onto a something like a USB card if I didn't have to. > OOMA seems to sacrifice getting work done, potentially entirely, > in support of keeping the system responsive and under control. I'm not a fan of OOM-death, but I think I understand the logic. It would be awesome if there was a scheduling algorithm that could balance everything happily, but I think this tradeoff basically boils down to responsiveness (is process A getting CPU time) against oversubscription of resources. "The beatings will continue until morale improves", except we're talking about processes being taken out back and shot in the head. Killing them seems extreme and somewhat arbitrary, but I'd quickly degenerate into a list of what I'd prefer was killed and the code mess that might be to try and implement it. I can easily imagine scenarios with basically a swap deadlock (no way to get a process into RAM to run in order to be "responsive") and then have to make a decision: Kill this thing that is basically hung or let it stick around indefinitely? And how many times do you do that before ALL swap is exhausted? We're not talking about checking your malloc() return code, we're talking about not even being able to grow a stack to make that call. So I can see myself with OOM-killings as a last-ditch defense against total system failure (and knowing that any OOM-killing might end up as a not-failed but useless system if a vital service is sacrificed). We're just talking about a knob to control some threshold where it becomes palatable. I don't think there is enough info to make the kind of informed decision we'd like the scheduler to make. From owner-freebsd-arm@freebsd.org Tue Aug 14 13:24:20 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 CFB1210781C2 for ; Tue, 14 Aug 2018 13:24:20 +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 4ADAC8E9E0 for ; Tue, 14 Aug 2018 13:24:19 +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=ELHXcRsdpa3jBwPgHQ3pIDoynSa5h7BOQQVk4wjO3hs=; b=oThPZUaKofHiYrR6UGp9kw/RnA2rrHJs+D1IjnHULkGewFbmMaxP4Pc5UIMFfTxAx0Fnn7Z4y1yFDhM0vVJH2OOVTjVf6pfCrpRhQalcp56vgl5an/vD9GbWEmHMzB9KiEMHhz1WXhQ4O/wAEExSziFB1/V8iBx3yLPYQQjPTSY= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id 3e257be8 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 14 Aug 2018 13:24:03 +0000 (UTC) Date: Tue, 14 Aug 2018 16:23:57 +0300 From: Greg V Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Ganbold Tsagaankhuu Cc: freebsd-arm Message-Id: <1534253037.1656.0@hraggstad.unrelenting.technology> In-Reply-To: References: <1533577708.4175.0@hraggstad.unrelenting.technology> 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: Tue, 14 Aug 2018 13:24:21 -0000 On Tue, Aug 14, 2018 at 2:01 PM, Ganbold Tsagaankhuu=20 wrote: > Greg, >=20 > On Tue, Aug 7, 2018 at 1:48 AM, Greg V =20 > wrote: >> Hi, >>=20 >> I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64=20 >> ROCKPro64 board): >>=20 >> https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 >>=20 >> As with the ROCK64, boot is over the network. To boot, dd ayufan's=20 >> ubuntu image onto an sdcard and Ctrl-C the linux boot on the kernel=20 >> selection screen. U-Boot on SPI flash is not available yet. >>=20 >> Unfortunately, performance is very disappointing =97 I think the big=20 >> cluster's default frequency is very low. >> (Everything runs faster if cpuset to the LITTLE cores.) >>=20 >> Looks like we'll need a driver for the "rockchip,rk808" PMIC to make=20 >> cpufreq_dt work=85 >> Also my attempt at the clock driver is very incomplete ;) >=20 > Can you change the patches according to style(9) for phabricator=20 > review (https://reviews.freebsd.org) and send them to me? > I think full files should be fine too. My patches are rather incomplete and janky, don't do anything with them. manu@ got a ROCKPro64 recently=20 https://twitter.com/manuvadot/status/1027152057051041793 so you can=20 expect proper versions of these "soon" :) (btw is the style(9) thing about how I put the various clock setting=20 structs on one line? :D) = From owner-freebsd-arm@freebsd.org Tue Aug 14 13:30:12 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 95B9A10782CF for ; Tue, 14 Aug 2018 13:30:12 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 0F4138EADD for ; Tue, 14 Aug 2018 13:30:12 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-qt0-x229.google.com with SMTP id h4-v6so21051784qtj.7 for ; Tue, 14 Aug 2018 06:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BsIfcrdLGWdywFl6s+BMyVWH7PCa+bIjOupc1OhoG2c=; b=lqEdQ2Ts6068hOSjrbgRryfVVk21SDYC0WnA8MfaHVJN1juhrJ5GxYHcGoAFEr4c4g KD2vBrakXRXGyNIEJdeA6KOoI6HDxMU4dsW82zBs+lKftRoFmEFP092cG+LYa68s4wOL kmYz1PeG8yfN04tfVhvOZrmHamVSfK1yUCoop1z003xlS4ouczCdwARczNIhFqos2dPU MUFEDZVnPx+hBVaPEBb5La7n90dFA/U/AL2K6M4gpav+5MTFvVdsuuk4HUAPpdt6xB5E W9YkowkxQydN6b/J3ujopYZzTsy+hFALIzfC1vNNgEpwfrVZcIREFouXPtiu/hCW53jS NIFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BsIfcrdLGWdywFl6s+BMyVWH7PCa+bIjOupc1OhoG2c=; b=ryYewNFU70Q1iUcx8Ab9WiRSZsbwhM0MDac3RHgaj0rLiihGvz0Zezq95kkboITGru PzoRqFGuV/oc09KOr2IFDeJaEwlHgy5mAZfEhPfL3X36pma426j+yl/qQ0L4/K3Z2Iak Y0EVhqoFt3KF5FQQPmQBlSSXQiJ3w1E6WkiQIgry6jE68vb7MTtvOlDxKwMqHRA9z7Y8 KiDd7B03kfaq5Vm0taVW1/zT8+4r6PMfkEmcmQTe9ZlGD8wqRWoBkT/cI+mZ2scHuQyB TXXXDmPFjiAHNgfIzAcD/cj4YjiMUABiAsCZt6cJe3giosnnnidpndLXVFIzqeYy6MTn byLQ== X-Gm-Message-State: AOUpUlH2eLEA5AhqjL9soOWpAtgbr/1FmJXWvLYzVY3nFFCAzoqUI+tc ZLqYaBl+0lfTq0bViK+kCNRJpwva2G4ju4lLIq4q6D4Y8tg= X-Google-Smtp-Source: AA+uWPwAq2SFOyqlyOix6/FSYSZI2jHEZ0aT/eIIhUBuRpAT3T9RQHQ+4rm234+cAx/8G2hMhefu01/sFq8FSORjM8Q= X-Received: by 2002:ac8:29a4:: with SMTP id 33-v6mr21952826qts.354.1534253411577; Tue, 14 Aug 2018 06:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:29c3:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 06:30:11 -0700 (PDT) In-Reply-To: <1534253037.1656.0@hraggstad.unrelenting.technology> References: <1533577708.4175.0@hraggstad.unrelenting.technology> <1534253037.1656.0@hraggstad.unrelenting.technology> From: Ganbold Tsagaankhuu Date: Tue, 14 Aug 2018 21:30:11 +0800 Message-ID: Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Greg V Cc: freebsd-arm 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: Tue, 14 Aug 2018 13:30:12 -0000 Greg, On Tue, Aug 14, 2018 at 9:23 PM, Greg V wrote= : > > > On Tue, Aug 14, 2018 at 2:01 PM, Ganbold Tsagaankhuu > wrote: > >> Greg, >> >> On Tue, Aug 7, 2018 at 1:48 AM, Greg V >> wrote: >> >>> Hi, >>> >>> I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64 ROCKPro64 >>> board): >>> >>> https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 >>> >>> As with the ROCK64, boot is over the network. To boot, dd ayufan's >>> ubuntu image onto an sdcard and Ctrl-C the linux boot on the kernel >>> selection screen. U-Boot on SPI flash is not available yet. >>> >>> Unfortunately, performance is very disappointing =E2=80=94 I think the = big >>> cluster's default frequency is very low. >>> (Everything runs faster if cpuset to the LITTLE cores.) >>> >>> Looks like we'll need a driver for the "rockchip,rk808" PMIC to make >>> cpufreq_dt work=E2=80=A6 >>> Also my attempt at the clock driver is very incomplete ;) >>> >> >> Can you change the patches according to style(9) for phabricator review = ( >> https://reviews.freebsd.org) and send them to me? >> I think full files should be fine too. >> > > My patches are rather incomplete and janky, don't do anything with them. > manu@ got a ROCKPro64 recently https://twitter.com/manuvadot/ > status/1027152057051041793 so you can expect proper versions of these > "soon" :) > I meant to say that we can rather use your patches if no one did it yet. Emmanuel, Do you have proper patches yet? > > (btw is the style(9) thing about how I put the various clock setting > structs on one line? :D) > > Yes :) thanks, Ganbold From owner-freebsd-arm@freebsd.org Tue Aug 14 18:20: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 38E3D1080AB4 for ; Tue, 14 Aug 2018 18:20:42 +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 B4FF7808D7 for ; Tue, 14 Aug 2018 18:20:41 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu ([IPv6:2001:470:71:d47:c4f7:ef33:9cec:87d]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id w7EIKbWX069262 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 14 Aug 2018 20:20:38 +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=1534270838; bh=pIkiLQAGkkmAtZuQZKQFfnP9NgED6v8ngcGKSoTM0J0=; h=To:From:Subject:Date; b=vqS6ZzvulCXfqanCzaxykNQrf7oy/+3MdbfYxokSwaFIfuYUJ9TSk8QuZCt8bK0g3 pDpnIR5WX7/k1NmiXZGa1U4HEaFEX5XfzdPLNudA/g13nvg9d5YPCSbtxvUAwXx2RZ SXTekfwHmbKEpadU1MXb4yRoIBPpHp31IQ0spyottMvRihDjqqinJ00sm1C1H4G/Hw tCbDx4k5/d3YZIeup7hF7S/nZUNNuOifY1fGbabZo97AxrG4va9azky/6uhbnSvbTO RFpLIV++43DXVAHrA7S3OoOe2hrFlzsCrFOX3t1CWQNlWdNrBjqWz9B81bhxRFCRC1 z/NczBXhyIStA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host [IPv6:2001:470:71:d47:c4f7:ef33:9cec:87d] claimed to be fomalhaut.potoki.eu To: freebsd-arm@freebsd.org 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: 1-Wire and RPi2 Message-ID: <1e34169b-a638-ca80-13f1-b96585483a76@plan-b.pwste.edu.pl> Date: Tue, 14 Aug 2018 20:20:28 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0Dn94Eeso2wQKAO5iBVAgYZqzeKDWaUtg" 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, 14 Aug 2018 18:20:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0Dn94Eeso2wQKAO5iBVAgYZqzeKDWaUtg Content-Type: multipart/mixed; boundary="d1yb8LQyL4C1cAkuJLTE8BoAWMYLah84W"; protected-headers="v1" From: Marek Zarychta To: freebsd-arm@freebsd.org Message-ID: <1e34169b-a638-ca80-13f1-b96585483a76@plan-b.pwste.edu.pl> Subject: 1-Wire and RPi2 --d1yb8LQyL4C1cAkuJLTE8BoAWMYLah84W Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB I followed owc(4) man page, so added "onewire { ..." to rpi2.dts file. Then the kernel was recompiled and reinstalled. Also rpi2.dtb was recompiled using /usr/src/sys/tools/fdt/make_dtb.sh and reinstalled in /boot/msdos. The only significant change I can see is changed MAC address assigned for ue0. The 1-Wire device is still missing and I want to find out what I am doing wrong. Is 1-Wire bus supported on RPi2 boards running FreeBSD 12.0-ALPHA1? --=20 Marek Zarychta --d1yb8LQyL4C1cAkuJLTE8BoAWMYLah84W-- --0Dn94Eeso2wQKAO5iBVAgYZqzeKDWaUtg 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//1SjSwFAltzHXUACgkQdZ/s//1S jSxkOQf+IZvUR0aHFd0rdeLpP+Gl6g/Frr3uZbwO5OjC9uLXYm49287p0xWfO4J1 LvGlwqdnRzctytVS80jt+uDQJxV4eQ6wrxbcOm29KxCTWkdszpvMVajWNE2xNq3V l1MjuaPPmnbcm87q7slIX2+2GKdXOv2ssQmmR1FnK929i3f/VicUW5E+dEGEI/PG 7R3lW6UG4+/iOXGkgPjbF7OvfRE9S53X8UZrGIhT4sfa/YSrEjjGCXLMf2vkPGy5 68HVEswotMbHUNGXMrnrAMRU8qBzCJRrgqaBupsRHOrO9hT09eTTS9r1z6soyHJq GoqEk011/YulVa/jC9halW2NGX2Xqg== =An54 -----END PGP SIGNATURE----- --0Dn94Eeso2wQKAO5iBVAgYZqzeKDWaUtg-- From owner-freebsd-arm@freebsd.org Tue Aug 14 19:15: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 DBA7110551C3 for ; Tue, 14 Aug 2018 19:15:15 +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 712908332C for ; Tue, 14 Aug 2018 19:15:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id l14-v6so19337864iob.7 for ; Tue, 14 Aug 2018 12:15:15 -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=xcxjjb/k2KqmMBBQM3NFfFyREcX+rGqlvlICrEoK3qo=; b=c4cLlLG51jd11fFl3c6y9jSVjmSdEj71FEVCHV7Wx+D8mqGWhtsmc9axoUJne6QYvg xL2/braS814LGiUmRYWYCdYLHdOmMnz2gzB6EgC/C0n6VBn5Fzf2dn5K9hTO+NTF4ee3 WcHglDond/UA98hkdMlI1vZud7pwmN5Z8fgGYB2hacuSOh+uVWmr9h4u7tIwIUrczW69 OD/A+BQWxCUPaRecZaBsNzg1lWFDfpbbPQKX8CXof4G59K0NHWSxO9oyP9oipk7Uoz0h Yzs0s5OGVn0ol6WVD3fce5R4bOgCb1VklxwIY98Hx+KTYMLd2V69Hcb+1SFTNeuZ1koe 0ovA== 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=xcxjjb/k2KqmMBBQM3NFfFyREcX+rGqlvlICrEoK3qo=; b=U7BtbUDYZGrk6wqQsxR16rrbH4riyelyWhhoZp6H4x8uGHUBeBzLhq5lnr0lQZ1AqO 1r94eljF3BnUUDScmHegEyJkG/TwFakppfxtm1InvW6Ud6wGJdTmK5wJlw63rVSEl5Im ZtuRnZNuksNiKHl1LdXYfDej/tf2X8e4I7th+kQrEIfU2oz5oOmxTg5JrQZ6BkD+j/6V KrXw57Islu1y4+Bo9GaB1FpWeFjuQ8wQ6VBaKxPyrJ0qGaj/I61Cto96d0m/fbS4keaK F0JtSSHH13368mt8xr2zmjysWwED0KXsAXEtTKQ3/WPqFLOvrpG+ozWCP4ZzbK0RAvCM CtMA== X-Gm-Message-State: AOUpUlEVbP79gi3so7t5LzO+2D+rY8LcM1a7aRwDIbiP+7uijBNdM6Zr 9v68MfEdN7ntTkPQAt/oblIc78SZ/m3gNoytyhiDrCKPZJg= X-Google-Smtp-Source: AA+uWPxq7Ek08QMpt5fgEV5aVyMt4o5gH8raXPJS0rfm5wNq8tOAu1i5i9X0TclXIQUSJM3yYrkBSgwnHLz4KGdmj3Q= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr19654350ioa.168.1534274114746; Tue, 14 Aug 2018 12:15:14 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 12:15:14 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <1e34169b-a638-ca80-13f1-b96585483a76@plan-b.pwste.edu.pl> References: <1e34169b-a638-ca80-13f1-b96585483a76@plan-b.pwste.edu.pl> From: Warner Losh Date: Tue, 14 Aug 2018 13:15:14 -0600 X-Google-Sender-Auth: FpcjSKnUay5iYENdcjCKrGRKwq8 Message-ID: Subject: Re: 1-Wire and RPi2 To: Marek Zarychta 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: Tue, 14 Aug 2018 19:15:16 -0000 On Tue, Aug 14, 2018 at 12:20 PM, Marek Zarychta < zarychtam@plan-b.pwste.edu.pl> wrote: > I followed owc(4) man page, so added "onewire { ..." to rpi2.dts file. > Then the kernel was recompiled and reinstalled. Also rpi2.dtb was > recompiled using /usr/src/sys/tools/fdt/make_dtb.sh and reinstalled in > /boot/msdos. > > The only significant change I can see is changed MAC address assigned > for ue0. The 1-Wire device is still missing and I want to find out what > I am doing wrong. > > Is 1-Wire bus supported on RPi2 boards running FreeBSD 12.0-ALPHA1? > I'd expect it to work. I've not recently confirmed it working though. Warner From owner-freebsd-arm@freebsd.org Tue Aug 14 20:48: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 419D410618BB for ; Tue, 14 Aug 2018 20:48:47 +0000 (UTC) (envelope-from alydiomc@yahoo.com) Received: from sonic305-22.consmr.mail.ne1.yahoo.com (sonic305-22.consmr.mail.ne1.yahoo.com [66.163.185.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 C7417884B9 for ; Tue, 14 Aug 2018 20:48:46 +0000 (UTC) (envelope-from alydiomc@yahoo.com) X-YMail-OSG: 8MyzgvYVM1lO_4TPA4uhAUbLAgY9EcbxetyBuLzpm71UTWqCUY_IpMra.XXMRkI I37KtpqyCviuOFcFAakVmMQypa0Oz_cIju6r6kkt2xkBgOT6KPSyK43a1.JhgELE._EaRpbcXlA_ JEgytAXQRBoTbWI3y9wrfsoOMZ04kyMCoyspaEfzJzQD18yHJ4W9_I45qkNvVbcLdQ.WmCd88fzP bYIl7iYdvAkwE1pt1WHBKOk7MOHj8fLppQe2IY7V1aSfu_S.FlYb6Kq_JThc2BX0tUun28.sfZuM fbDvRQTlh2QSqajuynQyagVCoEKFdwz4571tQhcdfDRKD_q3uTUtXSz8SsERRrlJMJefN9H7V_bJ REE0jmHwz8tCZWt0z6BFhEpJ6T8H_Q3PPDKEE.9GTO1C6wHvuPwZnmv9muq0ncc7Dk5muhj17gWF hkw3bDUE5QBL4UXy1EflY1rlJoGpy_k.5DAbggU_wXH7Qc55TCJmVtdwZ8Kvyw8DWWcnUg1zwk7p 5dkLmzy9IOsc8PuFdZ9SdJOwviszKK83QkQ9f4K1SQilecBfTdleODPYP6sV._K8PXkRrHkihuZw EoQvBVphpHZIkKVFXSEkZs4ukVDM0.4EfB1WPEwPmLfZD3ZTlcJiBPzj6b5NZFTWGsw1sEzzUhhA iy2.WiiS8rEfzf.HT3K97AW5vSDowc63hnD7K_k0nHR4DI37p3s8JKWIuFz8Gh1LCGyqVUU5GI.m iXfM2_GgSotZKMEYDu7urf6uHmRaQ9HHh.VlZE3ghqHbsdH9IzyJDEV7WxF6q6f2RezNjqz42.KN ZMIFkr9Go6THMzfNRqQA.0wilV6RGrBEKkfcBdHXCW89hvKsIG1zOI0JuIdAw8oo5iviT1zW6GSa _6ZoKwMBihVtoi5vte89H.0LFnzSDNa.3QsJQ5hVXh.jS8arpexvaFzsQbmAPa1s5oBF1GPKpu9K ipHNxv4Jp4VscLg.cPaE04pfKHngnO1j.jjv5bXonDM6DEfMNVkRf5VPqO2iAGcM9vkvMZHY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Tue, 14 Aug 2018 20:48:39 +0000 Date: Tue, 14 Aug 2018 20:48:37 +0000 (UTC) From: lyd mc To: Daniel Braniss , Emmanuel Vadot Cc: "freebsd-arm@freebsd.org" , Ian Lepore Message-ID: <1483769405.6803274.1534279717489@mail.yahoo.com> In-Reply-To: <20180812065314.ff83dd595460a0fadee77f59@bidouilliste.com> References: <165877705.5351934.1533988165694.ref@mail.yahoo.com> <165877705.5351934.1533988165694@mail.yahoo.com> <1533999888.31375.6.camel@freebsd.org> <2122126425.5355832.1534000914963@mail.yahoo.com> <5E1DB0F5-EF98-46A8-8D33-11052834E35C@cs.huji.ac.il> <20180812065314.ff83dd595460a0fadee77f59@bidouilliste.com> Subject: Re: Nanopi Neo I2C MIME-Version: 1.0 X-Mailer: WebService/1.1.12206 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 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: Tue, 14 Aug 2018 20:48:47 -0000 >=20 >=20 > > On 11 Aug 2018, at 18:21, lyd mc via freebsd-arm wrote: > >=20 > > Hi Ian, > > The iic bus seem to be working on linux image. I can detect the device = at 0x18. > > root@nanopi-neo:~/prog/I2C #=C2=A0 i2c -f /dev/iic0 -s > > Hardware may not support START/STOP scanning; trying less-reliable read= method. > > Scanning I2C devices on /dev/iic0: > >=20 > > some kdump output of above command:=C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 C= ALL=C2=A0 ioctl(0x3,I2CRSTCARD,0xbfbfec64) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CSTART,= 0xbfbfec64) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No = such file or directory > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CSTOP,0= xbfbfec64) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 > > .=C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRSTCA= RD,0xbfbfec64) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDWR,0= xbfbfec50) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No = such file or directory > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRSTCAR= D,0xbfbfec64) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDWR,0= xbfbfec50) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No = such file or directory > > Seems I2CRSTCARD and I2CSTOP are the only working ioctl on me. > > I activated i2c0 using below dts code: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i2c@1c2ac00 { > >=20 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 compatible =3D "allwinner,sun6i-a31-i2c"; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 reg =3D <0x1c2ac00 0x400>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 interrupts =3D <0x0 0x6 0x4>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 clocks =3D <0x1d 0x3b>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 resets =3D <0x1d 0x2e>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 pinctrl-names =3D "default"; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 pinctrl-0 =3D <0x20>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 status =3D "okay"; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 #address-cells =3D <0x1>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 #size-cells =3D <0x0>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 phandle =3D <0x41>; > >=20 > >=20 > > Regards,Alyd > >=C2=A0 =C2=A0 On Saturday, August 11, 2018, 11:04:54 PM GMT+8, Ian Lepor= e wrote:=C2=A0=20 > >=20 > > On Sat, 2018-08-11 at 11:49 +0000, lyd mc via freebsd-arm wrote: > >> Hi List, > >> Can you help me make I2C work in this board? > >> I can detect the controller but cannot access it through iic ioctl.=20 > >>=20 > >> root@nanopi-neo:~/prog/I2C # dmesg |grep iic > >> iichb0: mem 0x1c2ac00- > >> 0x1c2afff irq 34 on simplebus0 > >> iicbus0: on iichb0 > >> iichb1: mem 0x1c2b000- > >> 0x1c2b3ff irq 35 on simplebus0 > >> iicbus1: on iichb1 > >> iichb2: mem 0x1c2b400- > >> 0x1c2b7ff irq 36 on simplebus0 > >> iicbus2: on iichb2 > >> iic0: on iicbus0 > >> iic1: on iicbus1 > >> iic2: on iicbus2 > >>=20 > >> kdump output: > >>=20 > >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 NAMI=C2=A0 "/dev/iic0" > >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 openat 3 > >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDWR,0xbfbf= ecd4) > >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No such = file or directory > >>=20 > >> This seems to work on my RPI. > >>=20 > >=20 > > In this case, I wonder if the "errno 2" is not ENOENT, but > > rather IIC_ENOACK which has not been translated to a proper errno > > before returning. IIC_ENOACK is basically a timeout and can happen if > > the slave address is wrong, or if the pinmux is wrong so that the bus > > is electrically inactive. > >=20 > > Is the bus working in general? Do any devices show up on a scan with > >=20 > >=C2=A0 i2c -f /dev/iic0 -s > >=20 > > -- Ian > >=20 >=20 > the driver has timing issues (among others :-). I?m cc?ing the guys I got= a ?working?=C2=A0 twsi stuff=20 > to see if I can pass it on. >What timing issue and "other issues" are you talking about ? > danny Hi Manu, Thanks for dropping by! Can you help me address my issue? I already recompiled the with:1. TARGET_ARCH=3Darmv6 (same issue)2. Disable= d some i2c modules (same issue)=C2=A0=C2=A0=C2=A0 # I2C support =C2=A0=C2=A0=C2=A0=C2=A0 device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 iicbus =C2=A0=C2=A0=C2=A0=C2=A0 device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 iic =C2=A0=C2=A0=C2=A0=C2=A0 device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 twsi =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 rsb=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # Allwinner Reduc= ed Serial Bus =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 p2wi=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # Allwinner Push-Pull T= wo Wire =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 axp209=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # AXP209 Power Management Unit =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 axp81x=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # AXP813/818 Power Management Un= it =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 bcm2835_bsc =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 fsliic=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # Freescale i2c/iic =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 icee=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # AT24Cxxx and compatib= le EEPROMs =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 sy8106a=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # SY8106A Buck Regulator =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ti_i2c =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 am335x_pmic=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 # AM335x Power Management IC (TPC65217) =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 am335x_rtc=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 # RTC support (power management only) =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 twl=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # TI TWLX0X0/TPS6= 59x0 Power Management =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 twl_vreg=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # twl voltage regulation =C2=A0=C2=A0=C2=A0=C2=A0 #device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 twl_clks=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # twl external clocks =20 Regards,Alyd On Sunday, August 12, 2018, 12:53:18 PM GMT+8, Emmanuel Vadot wrote: =20 =20 On Sat, 11 Aug 2018 18:50:18 +0300 Daniel Braniss wrote: >=20 >=20 > > On 11 Aug 2018, at 18:21, lyd mc via freebsd-arm wrote: > >=20 > > Hi Ian, > > The iic bus seem to be working on linux image. I can detect the device = at 0x18. > > root@nanopi-neo:~/prog/I2C #=C2=A0 i2c -f /dev/iic0 -s > > Hardware may not support START/STOP scanning; trying less-reliable read= method. > > Scanning I2C devices on /dev/iic0: > >=20 > > some kdump output of above command:=C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 C= ALL=C2=A0 ioctl(0x3,I2CRSTCARD,0xbfbfec64) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CSTART,= 0xbfbfec64) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No = such file or directory > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CSTOP,0= xbfbfec64) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 > > .=C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRSTCA= RD,0xbfbfec64) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDWR,0= xbfbfec50) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No = such file or directory > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRSTCAR= D,0xbfbfec64) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl 0 > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDWR,0= xbfbfec50) > >=C2=A0 =C2=A0 871 i2c=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No = such file or directory > > Seems I2CRSTCARD and I2CSTOP are the only working ioctl on me. > > I activated i2c0 using below dts code: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i2c@1c2ac00 { > >=20 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 compatible =3D "allwinner,sun6i-a31-i2c"; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 reg =3D <0x1c2ac00 0x400>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 interrupts =3D <0x0 0x6 0x4>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 clocks =3D <0x1d 0x3b>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 resets =3D <0x1d 0x2e>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 pinctrl-names =3D "default"; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 pinctrl-0 =3D <0x20>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 status =3D "okay"; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 #address-cells =3D <0x1>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 #size-cells =3D <0x0>; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 phandle =3D <0x41>; > >=20 > >=20 > > Regards,Alyd > >=C2=A0 =C2=A0 On Saturday, August 11, 2018, 11:04:54 PM GMT+8, Ian Lepor= e wrote:=C2=A0=20 > >=20 > > On Sat, 2018-08-11 at 11:49 +0000, lyd mc via freebsd-arm wrote: > >> Hi List, > >> Can you help me make I2C work in this board? > >> I can detect the controller but cannot access it through iic ioctl.=20 > >>=20 > >> root@nanopi-neo:~/prog/I2C # dmesg |grep iic > >> iichb0: mem 0x1c2ac00- > >> 0x1c2afff irq 34 on simplebus0 > >> iicbus0: on iichb0 > >> iichb1: mem 0x1c2b000- > >> 0x1c2b3ff irq 35 on simplebus0 > >> iicbus1: on iichb1 > >> iichb2: mem 0x1c2b400- > >> 0x1c2b7ff irq 36 on simplebus0 > >> iicbus2: on iichb2 > >> iic0: on iicbus0 > >> iic1: on iicbus1 > >> iic2: on iicbus2 > >>=20 > >> kdump output: > >>=20 > >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 NAMI=C2=A0 "/dev/iic0" > >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 openat 3 > >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 CALL=C2=A0 ioctl(0x3,I2CRDWR,0xbfbf= ecd4) > >>=C2=A0 1290 mcp=C2=A0 =C2=A0 =C2=A0 RET=C2=A0 ioctl -1 errno 2 No such = file or directory > >>=20 > >> This seems to work on my RPI. > >>=20 > >=20 > > In this case, I wonder if the "errno 2" is not ENOENT, but > > rather IIC_ENOACK which has not been translated to a proper errno > > before returning. IIC_ENOACK is basically a timeout and can happen if > > the slave address is wrong, or if the pinmux is wrong so that the bus > > is electrically inactive. > >=20 > > Is the bus working in general? Do any devices show up on a scan with > >=20 > >=C2=A0 i2c -f /dev/iic0 -s > >=20 > > -- Ian > >=20 >=20 > the driver has timing issues (among others :-). I?m cc?ing the guys I got= a ?working?=C2=A0 twsi stuff=20 > to see if I can pass it on. What timing issue and "other issues" are you talking about ? > danny >=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 =20 From owner-freebsd-arm@freebsd.org Tue Aug 14 21:30: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 58A4E10651FA for ; Tue, 14 Aug 2018 21:30:52 +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 CB56E89EE4 for ; Tue, 14 Aug 2018 21:30:51 +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 w7ELV8jQ055030 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Aug 2018 14:31:09 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7ELV7gV055029; Tue, 14 Aug 2018 14:31:07 -0700 (PDT) (envelope-from fbsd) Date: Tue, 14 Aug 2018 14:31:07 -0700 From: bob prohaska To: Patrick Crilly Cc: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments (grace under pressure) Message-ID: <20180814213107.GA51051@www.zefox.net> References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> 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, 14 Aug 2018 21:30:52 -0000 On Tue, Aug 14, 2018 at 05:56:20PM +1000, Patrick Crilly wrote: > On 14-Aug-18 11:42 AM, bob prohaska wrote: > > I understand that the RPi isn't a primary platform for FreeBSD. > > But, decent performance under overload seems like a universal > > problem that's always worth solving, whether for a computer or > > an office. The exact goals might vary, but coping with too much > > to do and not enough to do it with is humanity's oldest puzzle. > > It's a very difficult problem to solve.?? And provokes some pretty heated > arguments. Understood. The arguments that apply to a Mars rover don't apply to a rack server, and vice versa. To a degree I'm hoping for Mars rover behavior by a rack server OS on a smartphone platform 8-) > > If you are experiencing overload, then there's a case for saying the > platform/system isup to the task. ^^^^ Did you mean to say "isn't up"? In general, I agree in that case. > > > > Maybe I should ask what the goals of the OOMA process serve. > > I always thought an OS's goals were along the lines of: > > 1. maintain control > > 2. get the work done > > 3. remain responsive > > > > OOMA seems to sacrifice getting work done, potentially entirely, > > in support of keeping the system responsive and under control. > Yes, but it seems to be the _first_visible_ response. Seems to me it would be better reserved as a last resort. > I believe the thinking is that if the system remains remains responsive > you have a chance of fixing the problem or at the very least you can > login and gather information about what is causing the problem. > Yes, some responsiveness is needed to distinguish from stuck. > > > > To have some fun with the office analogy, when business is > > slow the clerk serves customers as they come in. When things > > get busy, the clerk says "take a number". When they get really > > busy new customers are told "come back tomorrow" and when they > > get absolutely frantic present customers are told "I can't finish > > this now, I'll call you when it's done". That's grace under pressure. > > Nice analogy. If people just keep coming all day, I think what you've > described is a responsive system. I'm thinking of transient overloads; for permanent overloads there's no hope. "Transient" would be more than a task duration but less than a vacation interval, by how much I'm not sure, but it would scale with those intervals. > The clerk isn't getting any work done,?? he's just responding to customers.?? The clerk is timesharing, going from one task to the next in turn. Response time will suffer, because that's the only elasticity left in the problem. > And would "can't finish it now" be analogous to killing?? off processes? Not if the "I'll call you when it's done" is honored. The task is placed in a queue, finished when the overload passes, and the clerk returns the results. When the queue gets short enough he begins starting new tasks again. Mark M. equated this with swapping, as opposed to paging and I think he's right. In a sense, the "I'll call you when it's done" is like an old-fashioned batch processing scheme. Does FreeBSD have any vestigal remnant features for accepting batch jobs? High nicenes is similar but still interactive. Responsiveness, if only to say "There are nnn tasks ahead of you, please call back after ....." is the only degree of freedom left. Exactly out how bad to let that get before admitting defeat would vary greatly between an interactive job and a batch job. To a degree, OOMA is biased toward interactive use. Buildworld is more like a batch job. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Tue Aug 14 22:04: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 3CE9F106633D for ; Tue, 14 Aug 2018 22:04:53 +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 91F638B3B5 for ; Tue, 14 Aug 2018 22:04:52 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu ([IPv6:2001:470:71:d47:c4f7:ef33:9cec:87d]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id w7EM4kW6071852 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Aug 2018 00:04:46 +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=1534284286; bh=y/PPKUrJf1TbR94MdaYLHndUz4R7sQ/Is85qHa8EDgM=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=e/6eNFFHYdb9p4BK2Mo18Cy1rEJjys+exW9YlW3RPqTUOP3uRB9Z1Wm0uCTNqt4NT zD+U+bRoy7ArAMOOCV12ZBpu/qUZBQuAhN1J8KiWnkwzG+6++3jEDcYBIB44SPVDf5 IpMWh7306m0JRT7Mct2ePh2AvS3RZKamzu3ojqt/8EJn65zWDKphP7v1axfArPDcUw gIhQ9be4Q4U+ZFdoIUqXjdvJb9az0P9tlJECulpzryOH5SXoQJmJVwWxPHFETlqSKm fxWYL8GSQhSPkbXSw0mB8tQtA0e6cHGk8pX6R9dKWiL9xLdXkCzW6Mn/TK/iVp8RQu 53yBXqIhA9VsA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host [IPv6:2001:470:71:d47:c4f7:ef33:9cec:87d] claimed to be fomalhaut.potoki.eu To: Warner Losh Cc: "freebsd-arm@freebsd.org" References: <1e34169b-a638-ca80-13f1-b96585483a76@plan-b.pwste.edu.pl> 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: 1-Wire and RPi2 Message-ID: Date: Wed, 15 Aug 2018 00:04:36 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kM9OzwNNjm9rqRN1BfRkX73G5N0JerjXL" 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: Tue, 14 Aug 2018 22:04:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kM9OzwNNjm9rqRN1BfRkX73G5N0JerjXL Content-Type: multipart/mixed; boundary="PCwj3c4IzaGkGYHA7Ngtevw9zCLPXLXie"; protected-headers="v1" From: Marek Zarychta To: Warner Losh Cc: "freebsd-arm@freebsd.org" Message-ID: Subject: Re: 1-Wire and RPi2 References: <1e34169b-a638-ca80-13f1-b96585483a76@plan-b.pwste.edu.pl> In-Reply-To: --PCwj3c4IzaGkGYHA7Ngtevw9zCLPXLXie Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable W dniu 14.08.2018 o=C2=A021:15, Warner Losh pisze: > > > On Tue, Aug 14, 2018 at 12:20 PM, Marek Zarychta > > > wrote: > > I followed owc(4) man page, so added "onewire { ..." to rpi2.dts fi= le. > Then the kernel was recompiled and reinstalled. Also rpi2.dtb was > recompiled using /usr/src/sys/tools/fdt/make_dtb.sh and reinstalled= in > /boot/msdos. > > The only significant change I can see is changed MAC address assign= ed > for ue0. The 1-Wire device is still missing and I want to find out > what > I am doing wrong. > > Is 1-Wire bus supported on RPi2 boards running FreeBSD 12.0-ALPHA1?= > > > I'd expect it to work. I've not recently confirmed it working though. > > Warner Thank you for this device driver and for the reply. Of course, it works, I upgraded this box from 11-STABLE, but only partially upgraded boot environment installed on /boot/msdos partition. Currently (for FreeBSD 12.0-ALPHA1) getting ow_temp(4) working on Raspberry Pi 2 is pretty straightforward. I couldn't resist posting a simple tutorial, maybe some enthusiasts will benefit from it: pkg install rpi-firmware cp /usr/local/share/rpi-firmware/overlays/w1-gpio.dtbo /boot/msdos/overla= ys/ echo 'dtoverlay=3Dw1-gpio' >>/boot/msdos/config.txt echo 'ow_load=3D"yes"'=C2=A0 >>/boot/loader.conf echo 'owc_load=3D"yes"' >>/boot/loader.conf echo 'ow_temp_load=3D"yes"' >>/boot/loader.conf After reboot: #dmesg | grep -i wire owc0: at pin 4 on gpiobus0 ow0: <1 Wire Bus> on owc0 ow_temp0: romid 28:90:2d:e0:05:00:00:c7 on ow0 ow_temp1: romid 28:02:e6:84:05:00:00:d4 on ow0 ow_temp2: romid 28:9e:0a:a1:05:00:00:12 on ow0 ow_temp3: romid 28:db:82:85:05:00:00:07 on ow0 --=20 Marek Zarychta --PCwj3c4IzaGkGYHA7Ngtevw9zCLPXLXie-- --kM9OzwNNjm9rqRN1BfRkX73G5N0JerjXL 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//1SjSwFAltzUf0ACgkQdZ/s//1S jSzYogf7B4aiSC336j8MTSvduqUlGZ+yoo8yq9SdnD9cihiVuBLgSKUhAqDLLsG0 HDw6NZ719dEXWBN2H1r4yw9Ui1M2OtLxrlthaPA3Vyyy3+i9oP9++CkeFuWYIXlV Tbwij3JUP5cVY+QAA7zwGDzGA6fIHK8HpiE+HrSLuxbxEL1opPvubn/rTagumPDW Qx4QMA9hBzH7HabCfE7dvaBzCZeCymOCwwK+3NypXRnnhqtB4QXhKots623DmHNf RwVmmWbJbyiYsXeEDHkNS3JTuMsvjaMMfWRMCGNHy76tpbeKXXJF67odEPo4ElLY oivexdIr2IOY+dMeYkmVQwSTp0CYHA== =5oB+ -----END PGP SIGNATURE----- --kM9OzwNNjm9rqRN1BfRkX73G5N0JerjXL-- From owner-freebsd-arm@freebsd.org Tue Aug 14 22:17: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 8A64C10669FC for ; Tue, 14 Aug 2018 22:17:45 +0000 (UTC) (envelope-from jedi@jeditekunum.com) Received: from a1i76.smtp2go.com (a1i76.smtp2go.com [43.228.184.76]) (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 148C88B9FF for ; Tue, 14 Aug 2018 22:17:44 +0000 (UTC) (envelope-from jedi@jeditekunum.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=m4fue0.a1-4.dyn; x=1534285965; h=Feedback-ID: X-Smtpcorp-Track:Message-Id:To:Date:Subject:From:Reply-To:Sender: List-Unsubscribe; bh=IMvB4AZ2xkXDcbr10eszJCc9G48qc+ON5v7Px0uq634=; b=pUnlCWnc 4pbmCywQouHQcO4fK397zhZ/6kzGV0RUtBkBn2j6APq2ay6/kSaZ1oGZZTFZFQy8uVknJxUaHL3rQ zh1yIMwUDC/Y7qIhz3CTwefkPCFO9Kdvycl4ZY8DG72fEuv7j6DiaPYmAt4mNFTjFgkNK+ksQymRr q8z5GxNUWYj7WQlH65bSVD3aEMpnLEMnAIF9v5Nkc0M8plW/++NdwO6MdBF9IUJTqLnNqGaPWQCAq ZSqc/JTg0Vv+NCFmt86r0rCzAg5ObhYzxp3ybXX3eZSUoAjYO/qn4+Zy0F1OBs43uLzjYBPhoruuk mgRc96XD6SES5HKPz/AKndNUPw==; Received: from [10.45.33.53] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fphdC-WxjvQx-5t for freebsd-arm@freebsd.org; Tue, 14 Aug 2018 22:17:38 +0000 Received: from [10.162.213.37] (helo=takodana.opaxus.net) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fphdB-rlZFPj-Cv for freebsd-arm@freebsd.org; Tue, 14 Aug 2018 22:17:37 +0000 Received: from dagobah.opaxus.net (173-28-113-92.client.mchsi.com [173.28.113.92]) by takodana.opaxus.net (Postfix) with ESMTPSA id A12A011967 for ; Tue, 14 Aug 2018 17:17:35 -0500 (CDT) From: Jedi Tek'Unum Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (grace under pressure) Date: Tue, 14 Aug 2018 17:17:34 -0500 References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> To: freebsd-arm@freebsd.org In-Reply-To: <20180814213107.GA51051@www.zefox.net> Message-Id: X-Mailer: Apple Mail (2.3445.9.1) X-Smtpcorp-Track: 1fphdUr_ZFeMCv.cxljZEdMl Feedback-ID: 207158m:207158azGM_-I:207158s4k39g8-gK:SMTPCORP X-Report-Abuse: Please forward a copy of this message, including all headers, to 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, 14 Aug 2018 22:17:45 -0000 I firmly disagree with the entire concept of out of memory killers. They = are simply evil and in my opinion a complete cop-out. I first = encountered this kind of kludge back in the =E2=80=9880s with AIX. It = was bad then and it still is today. Frankly I find it ridiculous that = they still exist. For 35+ years I=E2=80=99ve worked with many unix variants on everything = from supercomputers on down. A majority on SunOS/Solaris. BIG Solaris = systems running crushing workloads. I have one question=E2=80=A6 when was the last time anyone saw Solaris = kill a process because the system was under memory stress? In my = experience, NEVER! And I wouldn=E2=80=99t say that the system became = unreasonably unresponsive either. As far as I=E2=80=99m concerned, any system deployed in a =E2=80=9Cmission= critical role=E2=80=9D (and I=E2=80=99m not referring to life-critical) = has no business ever killing a process for load reasons. Period. I=E2=80=99d go further and say that any unix system today has had plenty = of time to evolve into a =E2=80=9Cutility-grade=E2=80=9D service and is = therefore expected to support exactly that kind of mission critical = role. To claim that it isn=E2=80=99t possible, or practical, just = doesn=E2=80=99t hold water - Solaris has been doing it for a LONG TIME. I=E2=80=99m fully aware of the disaster related to the current owner of = Solaris. I=E2=80=99m not advocating the owner or, unfortunately, the = technology for the same reason. But that doesn=E2=80=99t change the = technical basis of saying this is a level of engineering that is = expected. From owner-freebsd-arm@freebsd.org Tue Aug 14 22:32: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 781A11068205 for ; Tue, 14 Aug 2018 22:32:49 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E3D368C241 for ; Tue, 14 Aug 2018 22:32:48 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [10.100.0.31] (haymarket.m5p.com [10.100.0.31]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id w7EMWK6U059762 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 14 Aug 2018 18:32:29 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: RPI3 swap experiments (grace under pressure) To: freebsd-arm@freebsd.org, jedi@jeditekunum.com References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> From: George Mitchell Openpgp: preference=signencrypt Autocrypt: addr=george+freebsd@m5p.com; prefer-encrypt=mutual; keydata= xsFNBFgnLnwBEADAJDiBKQX77LFRz9wZW8mz3KvaQol2nIremcws0F1mz/zgFlk6uhQVtwnL wb4XL5LdFwcNE1+QZzPLcbYWoWQlz0lBw1bMuKAgr0S6V2e0+I0DqhKeslVFctcTwtvT6pnK VLZXO/7ZGAaLzG4K5vSPzgoevU+YI/pxNsVCH2UO/c3jQW63uEt25mIZbCF1Pu4jgp4RhIgF ujn877r/j6OwBwjzRUu3E6ADp+U825d+5YCuQMEH0wIPnn9GTpXvfdKdbwOIl2akqXqs4cnk iATWfK3r6D4mvDEj1OPHlTvJYcfic7aOIiAwmx1C1v78GjXOdOOA0SGffNix3C2/8oZUO1+V Aet4MKpUKkduWSvULhIkHNZ5Nu8SIJOqge8pmtHxuNXAMfMrAjMdjPwwBFLsYg3Xa2E2oJwg ehTauwd/EDJFcVCyDCyCAYOi/BH/+XQyxzgDlY9N9qj9tHqhVPI6XK7t8UVffGiZUq4rHp5J RdOToqiTNC6eCJBczhMIW+DuFvWU9e6W708T1dz0Accn6Lrgk4eRIn3GFPBG+TxnpjAqHsbW 607dcnD3YKAqY4e+khczL4EObhe7dC1v2fmZiAC6Ds3WHR11IfqoUgCkIwJ590Ej+ElygJFF XxI82wtEz9hkeLLvItpyEJNVjppViRW+Dgl/U7ypHB3qDgYjgwARAQABzSBHZW9yZ2UgTWl0 Y2hlbGwgPGdlb3JnZUBtNXAuY29tPsLBlwQTAQgAQQIbIwUJCWYBgAULCQgHAgYVCAkKCwIE FgIDAQIeAQIXgBYhBDXTOGR5LbCVuZCmV8EREt5vqeH5BQJYWXFRAhkBAAoJEMEREt5vqeH5 SRsQAIb/crcxXyAyeokAuTjN+YXkEFdVv/JrOgNXKdCukXt/UGd3nZTcAzpllytDIvIlPTNI 2/nZ5sm6ymeyVwmvkrM/r3sRUib5ftakJpbv0wn2j+eCGAca8IA2frBUg9bEXKcHRJRQCztG cpousHzOziTCRQ/1NfPcIFBNbQMPUVoQ96cJPvM/XfFGOISKKsSI78skHm6Oazh1hLCQTKvy hNNgVpNP/PHCHMbla1+SNgyn35CUelTh153lnkOhw1XyX6IxY4o5Bhcf3YrxAVcoeHq3FEH0 T3ygAdI14VrZGXXitBAMI78QLB0FiWMoPQ3Oddnoh6tlT4djnsc9IW0Tzk6ozvQL7sKdYgO8 ZlIpkBqQQfpSHzwPu9EkOFggPWB9WtP3IajQ0lt1LovqMug4C8APRC2/1cvi+GUIRwjVsop0 ukhlLTTJd3/S4Muh3s87M4Rdek1xpOiMKjYOVaxmhQQ91oz971zJuJJWpX7uUQiXx9oEwCDW TvI5yEuqYLsMUwx3d2iFTr+HbtlBJmF+Vguyrn/a3vFK8P/TH9fMvNeTdln9SuOOa1SAMMcy czOpBYg9RpzNLshUJVrhKzugT59Rl2wsNQsQCUkzgF3f8cZHJyl+8x6t0nuM9LTkMv13YIXS Mde3UOD2EaBhmeIqvC/adQHxpNudvxM1viFJDnTnzsFNBFgnLnwBEAC7kzsZqjBRPonnr/63 C98FSa3LikvqQWygmPSCC9DsFX/fB0CSXIHTrHQ4a7lXdfZyTZcGdxXN+MC8O8thjvVq6WYm CpyOJ/bq4SxOa9cnQSJ5SP9VCmVoDN/3T4ybXFzLAt756kfQ5jsVuP0m6iQ4z918zhZXk+Mo qdwGjYTxsBD02a7m1aeYafyaI2mZ+vdEy0cDhV4PDXI6ThLNAavTPji6ZrBdH5a4LMg30u8v kkNe0eCKvU+0cWb2VQIeddMhhiGSBE2Dv+A4eNe1VZvoGpLDlYdnoHraVFL2GHNFGymj/uRf 1hja5kW9Rekisqby5SpGABwrFFEs7ABpfYG0IRBKbjjG1Cqdfe/R6ETJFvvNOOpCKPAWeqYf Isxv4OHWTmhKihhIanYWCAe1MDLRRbj7UrOTZeia2WJ4v58xbU5rVQoHI/Tzaq86rXzRWITc 5w+kresMad0zpvQ900BdHc8ATNY2aW/Fr5it5OqMvIW6Y4gc8Z95MkQPVc8vj3WzfxuWtZNK 6Wbv4r6Qbiwg1RpY1JoEIoF4OsZJOVMQaB6ezD7xvaa2eY6nRGtq9SoJxo2qvlSbLlKq8NdH VYHhtTbpQ1NfrEJfv5sLX5W5IpoYww48bFYH67+7r1f/W3voBptSgE7qnYAm6Em9bEAKOQEX 8BXwoa54fn03z6TyhwARAQABwsFkBBgBCAAPBQJYJy58AhsMBQkJZgGAAAoJEMEREt5vqeH5 6PcP+JvrMM7ZM8UlnbrY4Er9psPj3ayllRhQFA9h6GNUKYuSzSxOrPaT96s8KUGMCr4jrn1S WFmeeNLLOgSJmQRicMh6LmnKq6WY6UaOfn7Y9O62NUjXfEI3Bw4ID36YCdQ+CJd14r0YOf4M 5F50bvHV3lbzD9TXZPxecHKC2ZUMBbT37tsckWCLL3lzKMsqQLwBUmgBl1NIUc7gyXxiNyxb 6SPVF1NguDDM438mcg9jSRAyjgAk6POUEM8YIXkw0Gg6HF1tNMJJ1xTMBCLYl6fHTtsxJpf9 yo+Hnw346hqYzXn4ytHJ49Ngcre8uhqM1l8iMpa17tEjfalkc1FWR9/qvoowOKtxpvblsy3a YzeEFgIomhLzISz6IafQ3S7Mt5AFlqwN/qQHx0k2V66GzDG0ngZBPROP1sXSpdJzO0zbJQFn MZE3f+y8vXMcE/MBXR7kAdYYApiEMQzVxy9TdQDU3lGLptcPZ1IOntTNFFrvp5NwsKi+6C9i mXtd5kJ1PwhcJYW3/ov/490l60C5SFUL/RZ/NOW8SHFaPcqlGcqIlexFKbzrMQwmYXo95jWB eZ0Qn+raxCUFZNGiwtusyQGBMcpHVJUanOCNd1z4ZbfmhUjDJKC/7YWDunvaDRSukGiRCl6J s8caqXHiVZjx+s76iWzm6AHRP5jg9D6EtTOrGiE= Message-ID: Date: Tue, 14 Aug 2018 18:33:06 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BiJJYE0y7ISOZHp9FkSdRyLQW62Nzdzk9" X-Spam-Status: No, score=-1.0 required=10.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mailhost.m5p.com [10.100.0.247]); Tue, 14 Aug 2018 18:32:29 -0400 (EDT) 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, 14 Aug 2018 22:32:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BiJJYE0y7ISOZHp9FkSdRyLQW62Nzdzk9 Content-Type: multipart/mixed; boundary="kQX1MtV0C5PfBKYjtFlRKgAMJkHVHhT9C"; protected-headers="v1" From: George Mitchell To: freebsd-arm@freebsd.org, jedi@jeditekunum.com Message-ID: Subject: Re: RPI3 swap experiments (grace under pressure) References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> In-Reply-To: --kQX1MtV0C5PfBKYjtFlRKgAMJkHVHhT9C Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 08/14/18 18:17, Jedi Tek'Unum wrote: > I firmly disagree with the entire concept of out of memory killers. The= y are simply evil and in my opinion a complete cop-out. I first encounter= ed this kind of kludge back in the =E2=80=9880s with AIX. It was bad then= and it still is today. Frankly I find it ridiculous that they still exis= t. > [...] However: consider the subject (Raspberry Pi). -- George --kQX1MtV0C5PfBKYjtFlRKgAMJkHVHhT9C-- --BiJJYE0y7ISOZHp9FkSdRyLQW62Nzdzk9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAltzWKgACgkQwRES3m+p 4fnKTQ/9GTAyPJx4YlSnknl6dIkt5U82FD8DoqKX5mwA07MKq6i0Ag72txNkyJIc 1FMwVtdMAZvrOBFqy/y1H9Afj6zHGep4JuusgvayTQdtPZ7jWjEk+WSQcV449k4f wnxeYuKHE8rxG5VhP0pcTW0321zuqG6IB0wqLKgoViTO7or4VLigQK4CC2ryD2FV NG4gmNaULQ4pUUDVLd1QNwpBMxLw44ef//sR2+8VWX5QfVA0hwnyrfokrtwldWS+ tGXG/VXB3lhAL8SvrYDUwv3p6m9XQhZ/SuHNLKIwNCMlXijJpf+Xbo/isBLsS0Zk Y6yaIikqULNwZza2KmM1YY4y56LDRuLGSk46cms0ZteL9UOr0rwK1wP+kU7fVv5D h+pRcRo0ay9F9/dIGHGzHcZdD1fBLPWeL8ptGmtB3niumSM0NIx/+Ep3sE4SyytP wFs8BozAPp/MuDxW8QZvh9N2342u9Fnhxt0FG2ZR9qHe6HV0LsA57pwJ1oFCqoet pL2oCgiT0+iwt/gEkxHsZOiJChSN2fbzr/mnq0jOb/fBvfIGiJY5yN09/ubVBPf9 vfRTPFN4QJTvd8mxxXHQHtizrfoB5aGASGAslR8dIFZUq3lskTx2zoa4kVTz7cNU yhmYb3l/Kl9NiBZ+T39y7qlYpeDtjxQ/V3NkyThFURsU/KnAHyY= =rEhz -----END PGP SIGNATURE----- --BiJJYE0y7ISOZHp9FkSdRyLQW62Nzdzk9-- From owner-freebsd-arm@freebsd.org Tue Aug 14 23:11:31 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 1166A106928B for ; Tue, 14 Aug 2018 23:11:31 +0000 (UTC) (envelope-from jeditekunum@gmail.com) Received: from a1i76.smtp2go.com (a1i76.smtp2go.com [43.228.184.76]) (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 A72628D47B for ; Tue, 14 Aug 2018 23:11:30 +0000 (UTC) (envelope-from jeditekunum@gmail.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=m4fue0.a1-4.dyn; x=1534289190; h=Feedback-ID: X-Smtpcorp-Track:To:Message-Id:Date:From:Subject:Reply-To:Sender: List-Unsubscribe; bh=AIfUiYmub4X5L1yWheDIMEGNuiTKaDvD3pLlvDXKIs4=; b=vFJGna/d soGpN28HXIZ7poj+o17RRkRW+QD9izZBbaxb1CkZB167bqldsuR/+58FF12vU3qRfLGz9eQvXOcSM IeqhTZRa4L8xgTCFWQuUEoKclEfkZB99RTtvx/ljUqFFSf3YDU/6UB/+kALSH4NOHHB2eId+yoRfF nkT6J1wI7sf+bCYrgc10WwJEhQz1rd5vwfZQN/fecLcY15cFLsgfGLh2e0+tnKQzxL4C5PNJA3hP4 /HVY4Gi4aeLXg2HEFYX5CBDiDWZq2QUydCyf2RKdWi1815p9PZ6hE99Evo5aLahLfGE1dL1bdVR6u i8VeO/EuXvXDlBVqEXs3LGU1Cw==; Received: from [10.45.33.53] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fpiTJ-WxjtQG-AH; Tue, 14 Aug 2018 23:11:29 +0000 Received: from [10.162.213.37] (helo=takodana.opaxus.net) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fpiTI-rlZAMK-GY; Tue, 14 Aug 2018 23:11:28 +0000 Received: from [10.0.100.37] (173-28-113-92.client.mchsi.com [173.28.113.92]) by takodana.opaxus.net (Postfix) with ESMTPSA id DB5EF1197A; Tue, 14 Aug 2018 18:01:50 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: RPI3 swap experiments (grace under pressure) From: Jedi Tek'Unum X-Mailer: iPad Mail (15G77) In-Reply-To: Date: Tue, 14 Aug 2018 18:01:49 -0500 Cc: freebsd-arm@freebsd.org, jedi@jeditekunum.com Content-Transfer-Encoding: quoted-printable Message-Id: <78E3B5A8-D887-4468-B0C3-DAADD1D6816C@gmail.com> References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> To: George Mitchell X-Smtpcorp-Track: 1fpiTmr_ZjuKGY.cyGhjCUmv Feedback-ID: 207158m:207158azGM_-I:207158s4k39g8-gK:SMTPCORP X-Report-Abuse: Please forward a copy of this message, including all headers, to 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, 14 Aug 2018 23:11:31 -0000 Only Rpi has OOMA? My understanding was that this is an example of where it s= hows up. Scale doesn=E2=80=99t matter to me. If the platform is large enough to run i= t... That=E2=80=99s part of the insidious nature of this =E2=80=9Cfeature=E2=80=9D= . When depends on... lots of things. > On Aug 14, 2018, at 5:33 PM, George Mitchell wrot= e: >=20 >> On 08/14/18 18:17, Jedi Tek'Unum wrote: >> I firmly disagree with the entire concept of out of memory killers. They a= re simply evil and in my opinion a complete cop-out. I first encountered thi= s kind of kludge back in the =E2=80=9880s with AIX. It was bad then and it s= till is today. Frankly I find it ridiculous that they still exist. >> [...] >=20 > However: consider the subject (Raspberry Pi). -- George >=20 From owner-freebsd-arm@freebsd.org Tue Aug 14 23:50:13 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 86780106A139 for ; Tue, 14 Aug 2018 23:50:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 141D18E5C7 for ; Tue, 14 Aug 2018 23:50:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id s7-v6so21006885itb.4 for ; Tue, 14 Aug 2018 16:50:13 -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=Dm9HS6o1A6PUEFuQ06yarQlzd+UMsR02+AiHbEt+rcI=; b=Y1A7Ns5/TMv31GDaaq83Y7uLzsZ0RTuZJ9lahJaeKbEtzk9pGA5vEItxo0b4Jx3vao E2fKyZYG/y8VfU1v5kUpZAUr9mEQgbO7sPE97Vigye2Izrk+YOPOtnjZEyTdBh/OLIPm LEVUv+dOV6T6uTqNTTNxOq/XL3CeTcNsKS2nmXyDw0w8bnPVBbrMjmhfM1XrAQ+fFXLc Rje2FvU1TEOJ4PamEPxe1gJ3IlyPVbOUQe7HZcT1mTLqb2FTj1ixIiWB4nnZlOLQT3M0 MW77bOrn1kLxuc8JledIUNi8ulxODbcVsFJdiZ9f2dnAhmfVLl0g+q3PVcBExy0SwbpV 4fuQ== 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=Dm9HS6o1A6PUEFuQ06yarQlzd+UMsR02+AiHbEt+rcI=; b=SiOjdMguJ8vaazyjNx6ssZyhdxaUlS1l9xigKcx5NLQbIFPXORSmCUwgv3Zg0saxIR CXt7JOZWdFNGd5sl5PFqi4RGmc8pElGf4K2IFBlLIgeokHEsL+Uco6Sh408DfxRzzJgT zxPASe/ZmCdX/ROvOu9X2iat3/adtxVWOLT1s7t2o94UUswSD41LdctcQ5nSRVB0aFHf raGB2TPDRO75LrgEedAczOQV6u6vVrefmqfdvVhUGhJyKRpYBuDUDAQJTLnf/2/eiNgU 2WEhhFp1UmXFXe+45ED3m2/o84oo2Tyskj6OcxEq8DPjVKVPOMmr+VsqrtwtxADLgFrz H32w== X-Gm-Message-State: AOUpUlGjYUrh+RnT0N+8Jq20+qxtHyGPhbsaUH2Zulo/03LqnXeTMesi QqyDO0VrTef1+qnAfsna3sQdG1vHuPZbjSP0AmeGzQ== X-Google-Smtp-Source: AA+uWPzG30LBB0SpQqdnS8l1dHVO6U1QOZ5+HRuKwZU5rejfgSWsKO1DopKvQcQDnx0ZrHqlEMsKv92rWCD1k7mALZU= X-Received: by 2002:a24:b211:: with SMTP id u17-v6mr15827707ite.1.1534290612259; Tue, 14 Aug 2018 16:50:12 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 16:50:11 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180814014226.GA50013@www.zefox.net> References: <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> From: Warner Losh Date: Tue, 14 Aug 2018 17:50:11 -0600 X-Google-Sender-Auth: 4D7h4a2-VM9cCQ_neBsW3JhqoKs Message-ID: Subject: Re: RPI3 swap experiments (grace under pressure) To: bob prohaska Cc: Mark Millard , freebsd-arm , Mark Johnston 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: Tue, 14 Aug 2018 23:50:13 -0000 On Mon, Aug 13, 2018 at 7:42 PM, bob prohaska wrote: > [Altered subject, philosophical question] > On Mon, Aug 13, 2018 at 01:05:38PM -0700, Mark Millard wrote: > > > > Here there is architecture choice and goals/primary > > contexts. FreeBSD is never likely to primarily target > > anything with a workload like buildworld buildkernel > > on hardware like rpi3's and rpi2 V1.1's and > > Pine64+ 2GB's and so on. > > > > I understand that the RPi isn't a primary platform for FreeBSD. > But, decent performance under overload seems like a universal > problem that's always worth solving, whether for a computer or > an office. The exact goals might vary, but coping with too much > to do and not enough to do it with is humanity's oldest puzzle. > > Maybe I should ask what the goals of the OOMA process serve. > I always thought an OS's goals were along the lines of: > 1. maintain control > 2. get the work done > 3. remain responsive > Simplistically, one can view the VM system as a producer of dirty pages, and a cleaner of dirty pages. These happen at different rates, but usually are closely matched. We're normally able to launder enough pages to satisfy the need for new pages from the VM system (since clean pages can just be thrown away w/o any loss of data). The problem happens when we put a large load onto the creation side with a build. This generates a lot of dirty pages, and we have to flush the writes of the dirty pages quickly to keep up. When the backing store has time-varying write rates that vary substantially, we run into problems. We're not able to clean enough pages to keep up with demand. The system does what it can to slow down demand, but at some point it just can't keep up and we trigger OOM. I'm still firmly convinced that a combination of bugs that's making the storage system less robust. The solution? Fix those bugs. Once you do that, however, you are still stuck with crappy hardware is crappy. Swapping to the ultra-low-end is still going to suck. USB and SD cards generally is geared to long stretches of sequential writes and random reads since they are expected to go into cameras, or used as sneaker net. We might be able to not overload the device so much via tweaks to either the swap-out code (to reduce its rate more quickly when the GC on the card goes wonkies). But that might also allow for some way to write bigger, contiguous blocks when swapping out (which would help avoid the Read Modify Write behavior on 'small' writes that grind performance of some USB/SD flash devices into the ground). That would help this workload (and likely others). This is tricky because you'd want to do that as part of a single write which has some tricky implications for the VM system. These can be dealt with, of course. And the code to page it out will need a scatter gather list do the DMA works right, so we have to be careful not to exceed those limits. There's some clustering in the page-out code, but the swapper looks like it could use some work... I've not studied closely though to start work. At Netflix we've seen some workloads that suggest some improvements there would be helpful for us, but I don't know if that's the same problem or a different, related one. So, philosophically, I agree that the system shouldn't suck. Making it robust against suckage for extreme events that don't match the historic usage of BSD, though, is going to take some work. Warner From owner-freebsd-arm@freebsd.org Wed Aug 15 00:43:55 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 749F6106C38D for ; Wed, 15 Aug 2018 00:43:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-9.consmr.mail.gq1.yahoo.com (sonic316-9.consmr.mail.gq1.yahoo.com [98.137.69.33]) (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 DDA0A70885 for ; Wed, 15 Aug 2018 00:43:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: hE6gXY8VM1kYeFrg3fz5nhzIQu81f5bt45fCpAABkkct53ePdeauIbjaJ_aEq78 nfwYwXUi4NAihDv8I8MFN4yruzsZwpSbK4CGzmf5lkxKFSNIENObH.RRM7j1WTRluQXQBa1M2SjW zysDoZ8xkp1m7xa_R.7OXwrrtFC_NoIGMoNysj4b0VtwIMt3gfIXESd5BsTe9._u9Zb_FhiJyDIf uXprwO5UXo1ebAvowA4jngrTDPxw8SKwXfdQQTFRRlrOdJvzFKHTcnez2jQY1K9mSdLGuadl.oDz 5bl21SK61pAGuO1WSDc822WiyVrF7RLIX.4YpgidsRTASEz5rxOoVQCfM16VyQZEAvlloy6hk.cz wN9YO4v_q5cztzUCG716w4eHZsHx7pWrbGdBz9jLY5Mus2.nwKvBcMvtesxmLVCOACbMsszFX0z9 8jY4qjgNADfiBn5eQ6ycZUrMlgOnVctQ94zijNAcsxMZnIFjWb6EZSKrR7Zqqmi5NVUnF.N89UE1 qLhycZgbp2jKOmUWriOiwBLwWZ_k3snzok2Hw_7gkIbrw1cKWWafMDHT22UqVHzOy01.pailI5FE pP7Th314tjuntsVeUmZZc76MyWSkxU_aDzBn.BHFUjUaltBVKJKCOqLz13X7XU1ej_T0yNKhhvM2 VisxxIE7Nd.vP9XRSOKMER5iFwG5HW4Fhe9QNT4ydrsTdbGdVXR_3VT1z981HZeM_xCtuv.FMnkJ u_c2ve48nzbtxawa22pmbIE_IRD0_sYUbNc8wXS1YaGAavcOQcK3aTjnwXw9LnJrx40loWwYWWtE Iny6VTbpaWCI.lltJbiUm4JtQxiM5DcgaVprzq_3pbIeE2AFXnd4iL88zlMFXGhN2BaiMH_nnLbk b99jxvwISrYensHrj.zhyVdl7pf4FBvfbzPmr6YJq02469fQ0LVLhyZAFRKVDDS5ZYNocsGWkLqU y4.3rfN6kRhS2Q_hnmH0IwV9dQQBRDY_JBUDyJ6gBpr2fWDycgrSVZzc9eoup5m5ya8EkQ6bsafW YliAkwYrU Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 15 Aug 2018 00:43:48 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp430.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 851f19f8a99653398ed6315c46cb039b; Wed, 15 Aug 2018 00:33:38 +0000 (UTC) From: Mark Millard Message-Id: Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (grace under pressure) Date: Tue, 14 Aug 2018 17:33:37 -0700 In-Reply-To: Cc: bob prohaska , freebsd-arm , Mark Johnston To: Warner Losh References: <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=us-ascii 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: Wed, 15 Aug 2018 00:43:55 -0000 On 2018-Aug-14, at 4:50 PM, Warner Losh wrote: > On Mon, Aug 13, 2018 at 7:42 PM, bob prohaska > wrote: > [Altered subject, philosophical question] > On Mon, Aug 13, 2018 at 01:05:38PM -0700, Mark Millard wrote: > >=20 > > Here there is architecture choice and goals/primary > > contexts. FreeBSD is never likely to primarily target > > anything with a workload like buildworld buildkernel > > on hardware like rpi3's and rpi2 V1.1's and > > Pine64+ 2GB's and so on. > >=20 >=20 > I understand that the RPi isn't a primary platform for FreeBSD. > But, decent performance under overload seems like a universal > problem that's always worth solving, whether for a computer or > an office. The exact goals might vary, but coping with too much > to do and not enough to do it with is humanity's oldest puzzle.=20 >=20 > Maybe I should ask what the goals of the OOMA process serve. > I always thought an OS's goals were along the lines of: > 1. maintain control > 2. get the work done > 3. remain responsive >=20 > Simplistically, one can view the VM system as a producer of dirty = pages, and a cleaner of dirty pages. These happen at different rates, = but usually are closely matched. We're normally able to launder enough = pages to satisfy the need for new pages from the VM system (since clean = pages can just be thrown away w/o any loss of data). The problem happens = when we put a large load onto the creation side with a build. This = generates a lot of dirty pages, and we have to flush the writes of the = dirty pages quickly to keep up. When the backing store has time-varying = write rates that vary substantially, we run into problems. Just an FYI example comparison/contrast: For a buildworld buildkernel example with vm.pageout_oom_seq=3D12 v_free_count: 7773, v_inactive_count: 1 Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: out = of swap space without any "Mark J." messages such as: waited 4s for async swap write waited 4s for swap buffer waited 4s for async swap write waited 4s for async swap write waited 4s for async swap write The code uses 3s as the starting point for such reports as I remember, so shorter times would not have been reported. The context was a Pine64+ 2GB. A from-scratch buildworld buildkernel with vm.pageout_oom_seq=3D120 also reported no "waited" messages but had no kills. Note: I got that little "4s" block during a later poudriere bulk during or a few seconds after the devel/cmake build. So far that is the only report that I've seen from Mark J.'s reporting code for the Pine64+ 2G context that I have access to. Not even the later about 14.5 hr devel/llvm60 build reported such messages. poudreire bulk was running one job at a time but allowed each job to use all 4 cores. > . . . =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 15 01:35: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 E3B04106D960 for ; Wed, 15 Aug 2018 01:35: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 4EEDA71FA8; Wed, 15 Aug 2018 01:35:58 +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 w7F1aCqv055654 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Aug 2018 18:36: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 w7F1aC90055653; Tue, 14 Aug 2018 18:36:12 -0700 (PDT) (envelope-from fbsd) Date: Tue, 14 Aug 2018 18:36:12 -0700 From: bob prohaska To: Warner Losh Cc: Mark Millard , freebsd-arm , Mark Johnston , bob prohaska Subject: Re: RPI3 swap experiments (grace under pressure) Message-ID: <20180815013612.GB51051@www.zefox.net> References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@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: Wed, 15 Aug 2018 01:35:59 -0000 On Tue, Aug 14, 2018 at 05:50:11PM -0600, Warner Losh wrote: [big snip] > > So, philosophically, I agree that the system shouldn't suck. Making it > robust against suckage for extreme events that don't match the historic > usage of BSD, though, is going to take some work. > You've taught me a lot in the snippage above, but you skipped a key question: What do modern sysadmins in datacenter environments want their machines to do when overloaded? The overloads could be malign or benign, they might even be profitable. In the old days the rule seemed to be "slow down if you must, but don't stop". Page first, swap second, kill third. Has that changed? Perhaps the jobs aborted by OOMA can be restarted by another machine in the cloud? Then OOMA makes a great deal more sense. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Wed Aug 15 03:26: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 8CBF21070575 for ; Wed, 15 Aug 2018 03:26:56 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13C8775844 for ; Wed, 15 Aug 2018 03:26:56 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-oi0-x22a.google.com with SMTP id b15-v6so37452186oib.10 for ; Tue, 14 Aug 2018 20:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MGjM03Ao2yDXA6u3PDJ/DOmVxYq+fctL5XXIanup+K4=; b=Oi65Adrxcs005lnkFN+r2oIOjOYWbAxiWPFjVNHgvmgHlXdhqFC3Sfqeu8tlYu+OVU nNIpVeZmRLI8V9by0aAbL3bcOOOxhnnG7LRytvLRFWZj+TOgIaC4T2Hnl+rQqTFVdxgx 8gmBPmdeKoANS0wO5RblWC6j/HIeoHhGxef0Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MGjM03Ao2yDXA6u3PDJ/DOmVxYq+fctL5XXIanup+K4=; b=tlmOCXwitcpttdVtcEyun9Z0U6Nfk1o10plv+7Xmn9FCHbd/j3T6Jh7+5A+F7v54Su zkhiEQIHJFLJHoZRbQK3MKdkxsfO6JgHBTp35DEdTME0Fckiof32Jal8LOlBWMxyy7l4 i5CX48TQeJb4lSgCW1dtZroBZiiyC9VqEo3me2Ph+kAXPTv7/38g6mVvC1jtq0p7WC2k AvzDTb18neutplu+gFz9xSSk7d2hhMAqZYnoBoAuG9s9VQClkvivXzImwIwdrnkGSCXG rkocVZJtcCtvdQkXmEROtkIFXP4D4XZJcKYX8JPqirg3Ck/xWS3GBKVh5QtcY99llqTb qrKg== X-Gm-Message-State: AOUpUlEwjIWM6TUR45Zpk9S23ZogQ3VoTrRVQNHeYkXdj+QlnkAryzOo Dn/uMTOntgA6MwsmFCodn4L8Hbps3SU= X-Google-Smtp-Source: AA+uWPwwUi8CB7keKhquKzFrTOG2Oes7fGvFzMU3LBh9DSSw4EZPW7QInsab6i57+oxXwTkQuRlsug== X-Received: by 2002:aca:c00b:: with SMTP id q11-v6mr16217126oif.330.1534303615073; Tue, 14 Aug 2018 20:26:55 -0700 (PDT) Received: from [172.21.0.171] (65-36-116-65.dyn.grandenetworks.net. [65.36.116.65]) by smtp.gmail.com with ESMTPSA id r10-v6sm20017668oif.37.2018.08.14.20.26.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 20:26:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: RPI3 swap experiments (grace under pressure) From: Jim Thompson X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Tue, 14 Aug 2018 22:26:52 -0500 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> To: Jedi Tek'Unum 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, 15 Aug 2018 03:26:56 -0000 > On Aug 14, 2018, at 5:17 PM, Jedi Tek'Unum wrote: >=20 > I have one question=E2=80=A6 when was the last time anyone saw Solaris kil= l a process because the system was under memory stress? In my experience, NE= VER! And I wouldn=E2=80=99t say that the system became unreasonably unrespon= sive either. SunOS (4.x) and Solaris (2.3, at least) still had that kind of function in 1= 992. (Tadpole, Sun prior to that.) Never is a long time, Jim =E2=80=9CYoda=E2=80=9D Thompson= From owner-freebsd-arm@freebsd.org Wed Aug 15 04:26: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 70EC210720A6 for ; Wed, 15 Aug 2018 04:26:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE4D0777BE for ; Wed, 15 Aug 2018 04:26:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id v26-v6so36806iog.5 for ; Tue, 14 Aug 2018 21:26:40 -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=qvn/a9Zj2owm7UIMenicgFX/Z0gookeus80boi96XxI=; b=UTiUsUyKu/XvHQBghEPFaDRuWIe0gvpGHtnoZgbJaT2lZc5/+dkdc3EsDqg+BB15rs IWOI6ZL7MhPIFAvefrrnYJ8uNOGIuQ+BvfnconXFGgtjr8uZjI9B5Ph2BIsHO2sZ3Iy0 PhVmRwdMTsjyE01fgPlbJfAtfzHUnlVicLbobZrNdWCAsUNSTnekLyJzJdzppLGVWOma agSDDBoVPYqXkODwTDZlAf+2q4BQVTYJ8izMAVp1njP1uqXC+XgkNqncF82cKogwHld4 tPYyRJlUpxJH6swf4F77l5DjloK1jaQDkU2tujBmMVBaivm9XR+xM7PR7HH0cB58YzTt dFxw== 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=qvn/a9Zj2owm7UIMenicgFX/Z0gookeus80boi96XxI=; b=VN0cMDaZxTwfDb7UeA68hai6e4/8VVz1kN8ER3xQseIR80z2bvuDhFu//8/g6LsfEN PyRxyAWR4Lg1dauyH4YIzyg5/VccjDYs0zChZ/UHh/yZKRrriI91YQXpimSflR1BKtj2 2gJh0jpLn9ckHeEc/tZ//MJPrYC7KEFSLqpDDlENGlfQV5yUUJxmGuX1tq/51dR+aty5 uoHsHrVD81UmInRpoQOuTBSSvAWfLHFjCoZyeJpMM/TxazIs4zHrI9jOVhyb9KEcFWAH yhZb+tnBjqDbphtqT4zX1+FjDenIcp0/M/vviTGS0aVInnMUwRev1T8QB4n1nokP7iZ+ X82w== X-Gm-Message-State: AOUpUlHxco/NgYcGTzl+ty4rwMyD+OfZ2DOC68l41RGLkoCXZ8yGoEoh pbeFBo27OGeBYgg40FLsuIRdZ4SDu7kYiX2McHPEPA== X-Google-Smtp-Source: AA+uWPxsKc+o47gPrvhWI9lZuVwzAw97jzqTFs7ePM0V22u4iCTGYME1nokuBurx7EpFY+tlNrPkriUkMRwVj7S6n8I= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr20313246ioa.299.1534307200053; Tue, 14 Aug 2018 21:26:40 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:381a:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 21:26:39 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180815013612.GB51051@www.zefox.net> References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> From: Warner Losh Date: Tue, 14 Aug 2018 22:26:39 -0600 X-Google-Sender-Auth: axl48sGs_wFqlFZVYSr8m28RcCM Message-ID: Subject: Re: RPI3 swap experiments (grace under pressure) To: bob prohaska Cc: Mark Millard , freebsd-arm , Mark Johnston 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: Wed, 15 Aug 2018 04:26:41 -0000 On Tue, Aug 14, 2018 at 7:36 PM, bob prohaska wrote: > On Tue, Aug 14, 2018 at 05:50:11PM -0600, Warner Losh wrote: > [big snip] > > > > So, philosophically, I agree that the system shouldn't suck. Making it > > robust against suckage for extreme events that don't match the historic > > usage of BSD, though, is going to take some work. > > > > You've taught me a lot in the snippage above, but you skipped a key > question: > > What do modern sysadmins in datacenter environments want their machines > to > do when overloaded? The overloads could be malign or benign, they might > even > be profitable. In the old days the rule seemed to be "slow down if you > must, > but don't stop". Page first, swap second, kill third. > > Has that changed? Perhaps the jobs aborted by OOMA can be restarted by > another > machine in the cloud? Then OOMA makes a great deal more sense. No. That's not changed. That's the order we do things in FreeBSD still. The question is always when do you give up on each level? When do you start to swap? Ideally never, but you should swap when your current rate of page cleaning can't keep up with the demand, and there's dirty pages that you could use if you swap them out. When do you OOMA? Ideally, never, which is why we try to avoid it. The problem is that the heuristic we use to avoid it (12 tries) is well tuned for systems that are well matched to the I/O system, when dirty pages are created slower than the disk can swap them out, and there's rarely a backup in the disk system. There's no knowledge in the upper layers of how much we're loading the disks (apart from a few kludges like runningbuf), so it has to guess how it can best put load onto the disks to get the most out of them. All the tunables in the kernel for the VM system try to address these balance points. We want to have enough free pages so that we can give processes free pages so they don't have to sleep. We want to keep this above a minimum which is basically the response time of the page daemon to new or changing demand. The extra act as a shock absorber for changes in load. Otherwise, the PID that's in the page daemon does just enough work to ensure that we push out pages we need to to keep up with demand, yet not so much we do too much work. It knows how many new pages will be dirtied (estimated based on recent events), how many clean ones will show up (also based on recent history), so it can guess fairly well that to keep above the low water mark, it needs to launder so many pages in the next interval. The PID keeps the oscillations down, and allows it to respond more quickly to trouble than a simple 'steer out the error (P)' loop. However, tuning the PID look can be tricky in some applications. >From the data I've seen so far, FreeBSD isn't one of the tricky applications: there's a broad range of Kp, Kd and Ki values that give good results. So I think we may be seeing several problems here. One is that the normal write speed of thumb drives isn't that great, so the ability to push pages out is diminished (think of it this way: if you had 0 cost page out, you are only limited by the architecture's VM limits, real disks take time, so the practical limits are somewhat less of than that). In the past, read and write speed have remained in the same order of magnitude (more or less: median may be 5ms and P99 may be 40ms with max somewhere near 60ms, for example, and the numbers are similar for read and write), but with some flash that's no longer true. So even when there's not bugs / trouble in the I/O stack, you have things tied against you. Next, you have the problem that thumb drives have an 'erase size' that's more like 64k or 128k or so, not 4k so the traditional behavior of the swapper is going to do write somewhat less than that, which can make these drives perform even worse due to rewriting (the good ones have a true log device behind the scenes, so this doesn't matter, the bad ones cheat on cost so don't have enough RAM for the LUTs needed to do this, so make tradeoffs, one of which can be RMW). Next, there's issues with something in the system. Either the drive stops responding (so we get timeouts) or the USB stack hick-ups (so we get timeouts) or something. This problem comes and goes and confounds efforts to make the first problems better... So I think what's well tuned for the gear that's in a server doing traditional database and/or compute workloads may not be so well tuned for the RPi3 when you put NAND that can vary a lot in performance, as well as have fast reads and slow writes when the mix isn't that high. The system can be tuned to cope, but isn't tuned that way out of the box. tl;dr: these systems are enough different than the normal system that additional tuning is needed where the normal systems work great out of the box. Plus some code tuneups may help the algorithms be more dynamic than they are today. Warner From owner-freebsd-arm@freebsd.org Wed Aug 15 08:56: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 4DD81107A7E0 for ; Wed, 15 Aug 2018 08:56:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BD9E481070 for ; Wed, 15 Aug 2018 08:56:18 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 4a3d08a9; Wed, 15 Aug 2018 10:56:10 +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=4T0kSckAQfT6RYsBOl5cBnr6fvI=; b=fmkmYpNJWcivcUqPqhgg+KCQdAAl yriCFoLeAWmkRLu1M0rzXCj338yRksuQ9AGEDl063wbagQUUvnUs1L7HzU7bbLfe 0q6qn5dqFlrfYrKI315kesLe3kmidFggwkc3IV5MDez7Z6ILotJy3kDJwieGFzMR +NLpm3WONbWPYEk= 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=KVBg7AEDhoPC4OAKhk5I5y7HNHF5V0oBghIrTVSS1DEq5Uu2uNdI4csE YG8KnCCMg/BjoljwoMoMgZbYeFzl8l+5I5qDl27dXXhOzQYY1g+uUX5EBqNGDFsE X1wwUfgxenP7+z5Lhu3scxfjnuQY2pD//B5ehiEoZxjtISI/Rbg= Received: from knuckles.blih.net (37.168.27.0 [37.168.27.0]) by mail.blih.net (OpenSMTPD) with ESMTPSA id d5c7952e TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 15 Aug 2018 10:56:10 +0200 (CEST) Date: Wed, 15 Aug 2018 10:56:02 +0200 From: Emmanuel Vadot To: Ganbold Tsagaankhuu Cc: Greg V , freebsd-arm Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser Message-Id: <20180815105602.b106e1f55a3f839880b1b60e@bidouilliste.com> In-Reply-To: References: <1533577708.4175.0@hraggstad.unrelenting.technology> <1534253037.1656.0@hraggstad.unrelenting.technology> 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: Wed, 15 Aug 2018 08:56:19 -0000 On Tue, 14 Aug 2018 21:30:11 +0800 Ganbold Tsagaankhuu wrote: > Greg, >=20 > On Tue, Aug 14, 2018 at 9:23 PM, Greg V wro= te: >=20 > > > > > > On Tue, Aug 14, 2018 at 2:01 PM, Ganbold Tsagaankhuu > > wrote: > > > >> Greg, > >> > >> On Tue, Aug 7, 2018 at 1:48 AM, Greg V > >> wrote: > >> > >>> Hi, > >>> > >>> I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64 ROCKPro64 > >>> board): > >>> > >>> https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 > >>> > >>> As with the ROCK64, boot is over the network. To boot, dd ayufan's > >>> ubuntu image onto an sdcard and Ctrl-C the linux boot on the kernel > >>> selection screen. U-Boot on SPI flash is not available yet. > >>> > >>> Unfortunately, performance is very disappointing ? I think the big > >>> cluster's default frequency is very low. > >>> (Everything runs faster if cpuset to the LITTLE cores.) > >>> > >>> Looks like we'll need a driver for the "rockchip,rk808" PMIC to make > >>> cpufreq_dt work? > >>> Also my attempt at the clock driver is very incomplete ;) > >>> > >> > >> Can you change the patches according to style(9) for phabricator revie= w ( > >> https://reviews.freebsd.org) and send them to me? > >> I think full files should be fine too. > >> > > > > My patches are rather incomplete and janky, don't do anything with them. > > manu@ got a ROCKPro64 recently https://twitter.com/manuvadot/ > > status/1027152057051041793 so you can expect proper versions of these > > "soon" :) > > >=20 >=20 > I meant to say that we can rather use your patches if no one did it yet. >=20 > Emmanuel, >=20 > Do you have proper patches yet? No and I'm not in a hurry to put everything up for RK3399 so close to freeze. But if you want to clean them and put this in a review be my guest, I'll review them. >=20 >=20 > > > > (btw is the style(9) thing about how I put the various clock setting > > structs on one line? :D) > > > > > Yes :) >=20 >=20 > thanks, >=20 > Ganbold > _______________________________________________ > 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 Wed Aug 15 11:21: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 7FE91107FCEA for ; Wed, 15 Aug 2018 11:21:49 +0000 (UTC) (envelope-from jedi@jeditekunum.com) Received: from a1i76.smtp2go.com (a1i76.smtp2go.com [43.228.184.76]) (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 208AF86846 for ; Wed, 15 Aug 2018 11:21:48 +0000 (UTC) (envelope-from jedi@jeditekunum.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=m4fue0.a1-4.dyn; x=1534333009; h=Feedback-ID: X-Smtpcorp-Track:To:Message-Id:Date:From:Subject:Reply-To:Sender: List-Unsubscribe; bh=lqkPwWuBsmBLPu9fwfcMR2dJx1KvsA009YKKZONx1to=; b=vBJNcmb7 UAXcbKr7klz9tQWReAijWasYhwEPUvfFEa0X02eCLtfz9W76qxTWEh3SyujDTmZSzfTbtUVNR1v6I 2D09lVmA/AspPeG646BnnsSajKyUCK3c/Am6KlkUUTwUumVv2UdeRsSdtOm/TRjdbS5wavPM6xmlD 3kw/yz1gWQfP+wac1bHno5iPZ8TMevDE4msTZCayMAr9epGeWYngjWjb6+Q5dLmZiZNBfpDgsa1mI dTIi55icMu7x6oO8oI6kZoZu3smsbT10f5/EcqDZp4BG4rvWx7qLQ8x4tTtvEqzLUmKN14J2EsXD6 Kpe2L/284fsTTIjvMSisqhe08g==; Received: from [10.45.79.71] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fpts2-Wxjt6T-4b; Wed, 15 Aug 2018 11:21:46 +0000 Received: from [10.162.213.37] (helo=takodana.opaxus.net) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fpts1-DuufZO-Av; Wed, 15 Aug 2018 11:21:45 +0000 Received: from dagobah.opaxus.net (173-28-113-92.client.mchsi.com [173.28.113.92]) by takodana.opaxus.net (Postfix) with ESMTPSA id C5E4B11A0F; Wed, 15 Aug 2018 06:21:43 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (grace under pressure) From: Jedi Tek'Unum In-Reply-To: Date: Wed, 15 Aug 2018 06:21:42 -0500 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> To: Warner Losh X-Mailer: Apple Mail (2.3445.9.1) X-Smtpcorp-Track: 1fpts1DIIfZOjv.dEzLLqk3S Feedback-ID: 207158m:207158azGM_-I:207158s4k39g8-gK:SMTPCORP X-Report-Abuse: Please forward a copy of this message, including all headers, to 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, 15 Aug 2018 11:21:49 -0000 On Aug 14, 2018, at 11:26 PM, Warner Losh wrote: >=20 > So I think what's well tuned for the gear that's in a server doing > traditional database and/or compute workloads may not be so well tuned = for > the RPi3 when you put NAND that can vary a lot in performance, as well = as > have fast reads and slow writes when the mix isn't that high. The = system > can be tuned to cope, but isn't tuned that way out of the box. When there are no-win situations due to restrictive hardware then the = best solution is likely documentation encouraging people to avoid such = hardware. I doubt this is worth the effort of developing a kludge as one would = expect that these limitations will go away as hardware evolves - = rapidly. If people want to do things like -j4 on this kind of hardware then they = are asking for trouble. Might as well recommend swap over nfs. Surely not something one would = recommend on normal hardware but in this case it probably isn=E2=80=99t = any worse than slow NAND. However, I remain of the opinion that when people try to use hardware = unable to achieve minimal behavior that they should just suffer the = unresponsiveness. Surely thresholds can be recognized and warning syslog = messages provided. I=E2=80=99d rather have it sluggish than dying at = random times. I=E2=80=99ve not looked at OOM details on FreeBSD=E2=80=A6 Is there a = special signal sent to the victim before its killed? A quick glance at = the signal list says no. Of course that would introduce even more = complexity as the victim would need some reprieve time to be able to do = something with it. Even AIX had this in the =E2=80=9880s. My experience = back then was that it was better than nothing but not terribly useful. From owner-freebsd-arm@freebsd.org Wed Aug 15 12:55:15 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 4F4A21083734 for ; Wed, 15 Aug 2018 12:55:15 +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 B203C8AED1 for ; Wed, 15 Aug 2018 12:55:14 +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 w7FCtDEC038754 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Aug 2018 05:55:13 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w7FCtDpo038753; Wed, 15 Aug 2018 05:55:13 -0700 (PDT) (envelope-from jmg) Date: Wed, 15 Aug 2018 05:55:13 -0700 From: John-Mark Gurney To: "Jedi Tek'Unum" Cc: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments (grace under pressure) Message-ID: <20180815125513.GT97145@funkthat.com> Mail-Followup-To: Jedi Tek'Unum , freebsd-arm@freebsd.org References: <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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]); Wed, 15 Aug 2018 05:55:13 -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: Wed, 15 Aug 2018 12:55:15 -0000 Jedi Tek'Unum wrote this message on Tue, Aug 14, 2018 at 17:17 -0500: > I have one question??? when was the last time anyone saw Solaris kill a process because the system was under memory stress? In my experience, NEVER! And I wouldn???t say that the system became unreasonably unresponsive either. At least for Solaris 2.5, they would not allow overallocation of swap... If you had pages that could be modified, you had to have enough swap storage to store a copy of those pages... If you didn't, you'd get an out of memory error when trying to allocate the memory, such as forking, sbrk or mmap'ing... FreeBSD has long allowed overallocation of swap because w/ early computers most people didn't have enough storage to handle it, and most memory won't be used... -- 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 Wed Aug 15 13:03: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 5D2E01083C05 for ; Wed, 15 Aug 2018 13:03:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B521E8B69E for ; Wed, 15 Aug 2018 13:03:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w7FD3Uxi007518 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Aug 2018 16:03:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w7FD3Uxi007518 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w7FD3UEU007517; Wed, 15 Aug 2018 16:03:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 15 Aug 2018 16:03:30 +0300 From: Konstantin Belousov To: "Jedi Tek'Unum" , freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments (grace under pressure) Message-ID: <20180815130330.GY2340@kib.kiev.ua> References: <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> <20180815125513.GT97145@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180815125513.GT97145@funkthat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-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, 15 Aug 2018 13:03:46 -0000 On Wed, Aug 15, 2018 at 05:55:13AM -0700, John-Mark Gurney wrote: > Jedi Tek'Unum wrote this message on Tue, Aug 14, 2018 at 17:17 -0500: > > I have one question??? when was the last time anyone saw Solaris kill a process because the system was under memory stress? In my experience, NEVER! And I wouldn???t say that the system became unreasonably unresponsive either. > > At least for Solaris 2.5, they would not allow overallocation of swap... > If you had pages that could be modified, you had to have enough swap > storage to store a copy of those pages... If you didn't, you'd get an > out of memory error when trying to allocate the memory, such as forking, > sbrk or mmap'ing... > > FreeBSD has long allowed overallocation of swap because w/ early > computers most people didn't have enough storage to handle it, and > most memory won't be used... There is a knob to disable overcommit in FreeBSD, see vm.overcommit description in tuning(7). It is not very popular exactly because forking large process requires reservation of twice memory comparing with the real use. I believe that the option is exercised by stress2, but I did not heard about real-life usage, except my own long time ago. From owner-freebsd-arm@freebsd.org Wed Aug 15 13:46: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 3DC6C1085351 for ; Wed, 15 Aug 2018 13:46:26 +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 68EC28D896 for ; Wed, 15 Aug 2018 13:46:25 +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 w7F0KFkx067502 for ; Wed, 15 Aug 2018 10:20:15 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: RPI3 swap experiments (grace under pressure) To: freebsd-arm@freebsd.org References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> From: Trev Message-ID: <2f3bed05-b27e-420b-e831-1c8286edf35e@sentry.org> Date: Wed, 15 Aug 2018 10:20:15 +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: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Wed, 15 Aug 2018 10:20:15 +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: Wed, 15 Aug 2018 13:46:26 -0000 George Mitchell wrote on 15/08/2018 08:33: > On 08/14/18 18:17, Jedi Tek'Unum wrote: >> I firmly disagree with the entire concept of out of memory killers. Th= ey are simply evil and in my opinion a complete cop-out. I first encounte= red this kind of kludge back in the =E2=80=9880s with AIX. It was bad the= n and it still is today. Frankly I find it ridiculous that they still exi= st. >> [...] >=20 > However: consider the subject (Raspberry Pi). -- George When researching whether 512M of RAM was considered "usable" for a=20 FreeBSD buildworld, I came across [https://reviews.freebsd.org/D8302]=20 from October 2016 where just 256M was considered a test case for i386=20 and amd64 (-j1 I'm assuming) buildworlds which should succeed. Regardless, my RPi3B+ OOMA issues were completely eliminated by=20 replacing the 16G SanDisk "Ultra" card with a "faster" 32G SanDisk=20 "Extreme" card which contains all file systems as well as a swap=20 partition and runs -j4 buildworld flawlessly. I think this lends some=20 support to Warner's view. From owner-freebsd-arm@freebsd.org Wed Aug 15 14:30: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 75A3B1055A20 for ; Wed, 15 Aug 2018 14:30:54 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 0C0CE8F9FB for ; Wed, 15 Aug 2018 14:30:54 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-qk0-x229.google.com with SMTP id x192-v6so883739qkb.3 for ; Wed, 15 Aug 2018 07:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IbtXgrDpxjN4p80m1IB5qvKj1kfMiflz23QT/DI0yhU=; b=ElDxS+zMLs8PRn1VaZZQVTU0hmUqSUMqSvRY2Le14v4nChH+t8K/80JqskRYAEAScQ HZzhk5L1oEeWG0HgN8Ft0vrbJj33hJPs6cKa8tKrEw7yLuz69LLtK4u6w1MKXXjdGmVt mQnW3dPM4NdxKgzIcjAROv1wNLY6O8/8Mh35QXYEP94C3jGQkzFHhHmwnX4hk7kHHOiD jlOWfysDoj8ln/gYYlGqmobvxRiSGQUZdBQ3JJ0dtFG4h60KSsvehcv7DiTqBCDlXcRE 4mp/XxrCeOuWoHeU2egiZQj/Ch2FgGq/f2yMfiO4G3fD4sN2udAKk/CwShT9DvzafWb3 y4Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IbtXgrDpxjN4p80m1IB5qvKj1kfMiflz23QT/DI0yhU=; b=nytfYhMJDFTCyhojMtxxm7TVK1aicZ0n1eAl1OxjFA+uzuzJhI87DaPahsl3Xmcd2g Xde7j0fD/Cp1e5xHFCOn6lu3A+6mSS1zSs7vz477pVQiwByPEcGqhzCaBDWVawPhMKA/ N1/61m+d3SQwfXwX4Xp3AEJ2/XeCCGrCu1KvbwWcHE9XW6qpvNbcrip+i6XB30kB+S33 +4Hb+GPYurFs5D+hP9x8Ytlp6kW7QFNFIrkVT5BvRPcoKxFZzuw4Xu2BwJAN9yMAfRWA lWXG3m2hYtWo9WOi+E0uYBkF4jFktKtJMyWGn87Dho/qEmPNNku9sszPyZo2rRh1IGtB zIoQ== X-Gm-Message-State: AOUpUlGxVCVjj7p2V2HLbAZQ9bOioKO4vepj3TTbq35BZchanne25+G9 l5tvdAUlZkfxROI0Olfi+cY6FZOF5mvJqHbM6qVFbg== X-Google-Smtp-Source: AA+uWPw895wAkxhXxEOF7MBGoWKgEfPOsBog9BQxNk9UPfnSA+/cy4N+riZttwMsuh19HMmHiF3cZcFfNTd6ZMSq2vE= X-Received: by 2002:a37:9242:: with SMTP id u63-v6mr23156777qkd.189.1534343453666; Wed, 15 Aug 2018 07:30:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:29c3:0:0:0:0:0 with HTTP; Wed, 15 Aug 2018 07:30:53 -0700 (PDT) In-Reply-To: <20180815105602.b106e1f55a3f839880b1b60e@bidouilliste.com> References: <1533577708.4175.0@hraggstad.unrelenting.technology> <1534253037.1656.0@hraggstad.unrelenting.technology> <20180815105602.b106e1f55a3f839880b1b60e@bidouilliste.com> From: Ganbold Tsagaankhuu Date: Wed, 15 Aug 2018 22:30:53 +0800 Message-ID: Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Emmanuel Vadot Cc: Greg V , freebsd-arm 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: Wed, 15 Aug 2018 14:30:54 -0000 On Wed, Aug 15, 2018 at 4:56 PM, Emmanuel Vadot wrote: > On Tue, 14 Aug 2018 21:30:11 +0800 > Ganbold Tsagaankhuu wrote: > > > Greg, > > > > On Tue, Aug 14, 2018 at 9:23 PM, Greg V > wrote: > > > > > > > > > > > On Tue, Aug 14, 2018 at 2:01 PM, Ganbold Tsagaankhuu < > ganbold@gmail.com> > > > wrote: > > > > > >> Greg, > > >> > > >> On Tue, Aug 7, 2018 at 1:48 AM, Greg V > > >> wrote: > > >> > > >>> Hi, > > >>> > > >>> I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64 > ROCKPro64 > > >>> board): > > >>> > > >>> https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 > > >>> > > >>> As with the ROCK64, boot is over the network. To boot, dd ayufan's > > >>> ubuntu image onto an sdcard and Ctrl-C the linux boot on the kernel > > >>> selection screen. U-Boot on SPI flash is not available yet. > > >>> > > >>> Unfortunately, performance is very disappointing ? I think the big > > >>> cluster's default frequency is very low. > > >>> (Everything runs faster if cpuset to the LITTLE cores.) > > >>> > > >>> Looks like we'll need a driver for the "rockchip,rk808" PMIC to make > > >>> cpufreq_dt work? > > >>> Also my attempt at the clock driver is very incomplete ;) > > >>> > > >> > > >> Can you change the patches according to style(9) for phabricator > review ( > > >> https://reviews.freebsd.org) and send them to me? > > >> I think full files should be fine too. > > >> > > > > > > My patches are rather incomplete and janky, don't do anything with > them. > > > manu@ got a ROCKPro64 recently https://twitter.com/manuvadot/ > > > status/1027152057051041793 so you can expect proper versions of these > > > "soon" :) > > > > > > > > > I meant to say that we can rather use your patches if no one did it yet. > > > > Emmanuel, > > > > Do you have proper patches yet? > > No and I'm not in a hurry to put everything up for RK3399 so close to > freeze. > Yes, I agree. > But if you want to clean them and put this in a review be my guest, > I'll review them. > Ok, I will see if I'll have some time to polish it unless someone else will do it. thanks, Ganbold > > > > > > > > > > > (btw is the style(9) thing about how I put the various clock setting > > > structs on one line? :D) > > > > > > > > Yes :) > > > > > > thanks, > > > > Ganbold > > _______________________________________________ > > 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" > > > -- > Emmanuel Vadot > From owner-freebsd-arm@freebsd.org Wed Aug 15 14:49: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 9E70B1058603 for ; Wed, 15 Aug 2018 14:49:00 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from hraggstad.unrelenting.technology (hraggstad.unrelenting.technology [IPv6:2605:2700:0:3:a800:ff:fee9:2feb]) (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 1D86D906FF for ; Wed, 15 Aug 2018 14:48:59 +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=WHX/iVYmh9rEFmJ6yxefOpMp9FEEvrZzbSVrxwG2DlY=; b=mBea4FawH2RR4pzIObpsVmKFNP7OjllmVEC1bQKCxmgajQc8id0Gr9+TqbcoZaNSAdXCTPn+OOMjB/8Jny+OS1wLaM+dF/K7UeIyE+MqjnkEa4zYn/e45mooReWR0ocL6U2QLbH2vtS63so5DUqxBoy6Hzlb6xYi4hCk2ROASNw= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id dc3e7756 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 15 Aug 2018 14:48:45 +0000 (UTC) Date: Wed, 15 Aug 2018 17:48:39 +0300 From: Greg V Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Ganbold Tsagaankhuu Cc: Emmanuel Vadot , freebsd-arm Message-Id: <1534344519.3897.0@hraggstad.unrelenting.technology> In-Reply-To: References: <1533577708.4175.0@hraggstad.unrelenting.technology> <1534253037.1656.0@hraggstad.unrelenting.technology> <20180815105602.b106e1f55a3f839880b1b60e@bidouilliste.com> 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: Wed, 15 Aug 2018 14:49:00 -0000 On Wed, Aug 15, 2018 at 5:30 PM, Ganbold Tsagaankhuu=20 wrote: >=20 >=20 > On Wed, Aug 15, 2018 at 4:56 PM, Emmanuel Vadot=20 > wrote: >> On Tue, 14 Aug 2018 21:30:11 +0800 >> Ganbold Tsagaankhuu wrote: >>=20 >> > Greg, >> > >> > On Tue, Aug 14, 2018 at 9:23 PM, Greg V=20 >> wrote: >> > >> > > >> > > >> > > On Tue, Aug 14, 2018 at 2:01 PM, Ganbold Tsagaankhuu=20 >> >> > > wrote: >> > > >> > >> Greg, >> > >> >> > >> On Tue, Aug 7, 2018 at 1:48 AM, Greg V=20 >> >> > >> wrote: >> > >> >> > >>> Hi, >> > >>> >> > >>> I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64=20 >> ROCKPro64 >> > >>> board): >> > >>> >> > >>>=20 >> https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 >> > >>> >> > >>> As with the ROCK64, boot is over the network. To boot, dd=20 >> ayufan's >> > >>> ubuntu image onto an sdcard and Ctrl-C the linux boot on the=20 >> kernel >> > >>> selection screen. U-Boot on SPI flash is not available yet. >> > >>> >> > >>> Unfortunately, performance is very disappointing ? I think the=20 >> big >> > >>> cluster's default frequency is very low. >> > >>> (Everything runs faster if cpuset to the LITTLE cores.) >> > >>> >> > >>> Looks like we'll need a driver for the "rockchip,rk808" PMIC=20 >> to make >> > >>> cpufreq_dt work? >> > >>> Also my attempt at the clock driver is very incomplete ;) >> > >>> >> > >> >> > >> Can you change the patches according to style(9) for=20 >> phabricator review ( >> > >> https://reviews.freebsd.org) and send them to me? >> > >> I think full files should be fine too. >> > >> >> > > >> > > My patches are rather incomplete and janky, don't do anything=20 >> with them. >> > > manu@ got a ROCKPro64 recently https://twitter.com/manuvadot/ >> > > status/1027152057051041793 so you can expect proper versions of=20 >> these >> > > "soon" :) >> > > >> > >> > >> > I meant to say that we can rather use your patches if no one did=20 >> it yet. >> > >> > Emmanuel, >> > >> > Do you have proper patches yet? >>=20 >> No and I'm not in a hurry to put everything up for RK3399 so close=20 >> to >> freeze. >=20 > Yes, I agree. >=20 >=20 >> But if you want to clean them and put this in a review be my guest, >> I'll review them. >=20 > Ok, I will see if I'll have some time to polish it unless someone=20 > else will do it. I'm currently trying to add more clocks, I'll change the style too=85 = From owner-freebsd-arm@freebsd.org Wed Aug 15 14:50: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 E9E1B10586A7 for ; Wed, 15 Aug 2018 14:50:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-13.consmr.mail.bf2.yahoo.com (sonic314-13.consmr.mail.bf2.yahoo.com [74.6.132.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 8D84A9079E for ; Wed, 15 Aug 2018 14:50:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: XbjPdd0VM1kT7tinzy9m8DMUiWoxqRlfPlMWW9rFBGaP5XuXEMyMFqAdJCWrizF ZpjzU3l8WMsu.R.6Y69Z6bmRURQCrQgnP__ueh.53qDGuwZiYb2n3V3MQuxdNv7nZpB.PRtV89OY YBh.vYB2xoaCL7N5kIsE9A3aKxdCByQ0WboZKClnlOKNOahK1vKnPOGmIh90WIdXCGZRmUfHnByN JEeOBvKVIWtslKFd5DKrLNCCtADUhn_f_swUMk1pq9Ydw9wC7rEQT_IKHuoPClf6WrZwgWOpwQdN CBoxGONwsYzlwgE6VVYf66FkEHzNcLSqjGpK8q8KwpTy7FO46L34bwY55t8m.5q_rz8MN41.EBly me47opMhDTjwV1IMPceQsIg_JtFlRzXZiSDfoPrSwJGIW_f.ILl_RRnZVIoSj9dzzrDVrrHTzAtU oGaoijC9fJtko0xBaN1N78yuFnaQskXg.hj4Z_lyxlfCmY.slgdtKhlgzOlTdEHh8ShKOyyiat4M P5R.Q0y0iOh0Kh_45cRznnVt1Go7JwMMu7IBb03uGur_Zk0tabJS8b79GVYSS6hMPn7yEY9oreBS TfYL7QXeQLuNIxs6KNsnYC3IqHl6D3O3AvSxYdmagREQgU175xDKXkO1z0c7ZdemMvXXQtAeMINq ZefFPaEH04KO2zzj8e.zcgS1Lg052MvMGt2RHRWEOWxglCNL3ioI3ZaaHa56voQnR7esiIIBgJcY kv.s4o1oZIuhWQlNoWHnnx7gkSDMDo80ZHWKpCDASMCCnZX.wQ_R712fb.Ycr2cZRLXv.rkaGz7x P0wqEq4GN48I5bcaf_78OEQvu7qBAHKi5NVpR6AP1vy9mUJn0KmViZj2FSb5erbwUX1W_2Gb27ZV e9dQsZ9LnclRwbEdl73AZoc8wbsbTPab9OVyOLMg.de2WaQ4iO6QzuxOH4xko99RaQtOVS6dPRoN AUGMooAAee650yWU4D6a0OIZv4vNYWGeTDdxyrGjkR0143VpMeQJ8duFKZTK0Q93DV80YRyELY3_ uK8M4x0y6FA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Wed, 15 Aug 2018 14:50:09 +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 de3df9046f936a108a33036fd93527c9; Wed, 15 Aug 2018 14:40:00 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (grace under pressure) From: Mark Millard In-Reply-To: <2f3bed05-b27e-420b-e831-1c8286edf35e@sentry.org> Date: Wed, 15 Aug 2018 07:39:58 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <16004AB0-B499-4F30-8C14-AAE5E45B0A3B@yahoo.com> References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> <2f3bed05-b27e-420b-e831-1c8286edf35e@sentry.org> To: Trev 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, 15 Aug 2018 14:50:16 -0000 On 2018-Aug-14, at 5:20 PM, Trev wrote: > George Mitchell wrote on 15/08/2018 08:33: >> On 08/14/18 18:17, Jedi Tek'Unum wrote: >>> I firmly disagree with the entire concept of out of memory killers. = They are simply evil and in my opinion a complete cop-out. I first = encountered this kind of kludge back in the =E2=80=9880s with AIX. It = was bad then and it still is today. Frankly I find it ridiculous that = they still exist. >>> [...] >> However: consider the subject (Raspberry Pi). -- George >=20 > When researching whether 512M of RAM was considered "usable" for a = FreeBSD buildworld, I came across [https://reviews.freebsd.org/D8302] = from October 2016 where just 256M was considered a test case for i386 = and amd64 (-j1 I'm assuming) buildworlds which should succeed. What I see there is pho writing: QUOTE I have run stress2 testes on i386 and amd64. I ran a buildkernel on both i386 and amd64 with 256MB RAM / UP. Buildworld was run with various small RAM configurations. END QUOTE It explicitly lists buildkernel for 256 MiBytes of RAM, not buildworld. I'm not sure what the "UP" is for. "RAM / UP" looks like it might be a ratio but may be it was indicating not SMP? It not clear if this buildkernel testing included kernel-toolchain as well. buildworld was listed separately with nothing explicit about what "small RAM" was considered to be. If stress2 is configurable, there is no information on what the specific test was for retrying the same test or knowing just what the test was. > Regardless, my RPi3B+ OOMA issues were completely eliminated by = replacing the 16G SanDisk "Ultra" card with a "faster" 32G SanDisk = "Extreme" card which contains all file systems as well as a swap = partition and runs -j4 buildworld flawlessly. I think this lends some = support to Warner's view. _______________________________________________ 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" =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 15 14:56: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 5ED401058AC4 for ; Wed, 15 Aug 2018 14:56:32 +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 C071390E18 for ; Wed, 15 Aug 2018 14:56:31 +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 w7FEuOC8041282 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Aug 2018 07:56: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 w7FEuOh9041281; Wed, 15 Aug 2018 07:56:24 -0700 (PDT) (envelope-from jmg) Date: Wed, 15 Aug 2018 07:56:24 -0700 From: John-Mark Gurney To: Mark Millard Cc: Trev , freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments (grace under pressure) Message-ID: <20180815145624.GU97145@funkthat.com> Mail-Followup-To: Mark Millard , Trev , freebsd-arm@freebsd.org References: <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> <2f3bed05-b27e-420b-e831-1c8286edf35e@sentry.org> <16004AB0-B499-4F30-8C14-AAE5E45B0A3B@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16004AB0-B499-4F30-8C14-AAE5E45B0A3B@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]); Wed, 15 Aug 2018 07:56: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: Wed, 15 Aug 2018 14:56:32 -0000 Mark Millard via freebsd-arm wrote this message on Wed, Aug 15, 2018 at 07:39 -0700: > On 2018-Aug-14, at 5:20 PM, Trev wrote: > > > George Mitchell wrote on 15/08/2018 08:33: > >> On 08/14/18 18:17, Jedi Tek'Unum wrote: > >>> I firmly disagree with the entire concept of out of memory killers. They are simply evil and in my opinion a complete cop-out. I first encountered this kind of kludge back in the ???80s with AIX. It was bad then and it still is today. Frankly I find it ridiculous that they still exist. > >>> [...] > >> However: consider the subject (Raspberry Pi). -- George > > > > When researching whether 512M of RAM was considered "usable" for a FreeBSD buildworld, I came across [https://reviews.freebsd.org/D8302] from October 2016 where just 256M was considered a test case for i386 and amd64 (-j1 I'm assuming) buildworlds which should succeed. > > What I see there is pho writing: > > QUOTE > I have run stress2 testes on i386 and amd64. > I ran a buildkernel on both i386 and amd64 with 256MB RAM / UP. > Buildworld was run with various small RAM configurations. > END QUOTE > > It explicitly lists buildkernel for 256 MiBytes of RAM, not > buildworld. I'm not sure what the "UP" is for. "RAM / UP" > looks like it might be a ratio but may be it was indicating > not SMP? It not clear if this buildkernel testing included > kernel-toolchain as well. UP mean Uniprocessor, or no -j flag... -- 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 Wed Aug 15 15:10: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 47591105B2B9 for ; Wed, 15 Aug 2018 15:10:37 +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 C3D8F918CC for ; Wed, 15 Aug 2018 15:10:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: wPAGRoIVM1lImj7nsvrDPkvDySLGPxRRk7M2WQ8rmZFngrdySaZ8iQonyYHdKFr CbTfJfAkpFPqO7HpkLjN4zt6XZa3yiUpJjPmimZGtHPqcwFhI00NCbgNcYMu._MvZg._gAwcF_1k TrusPNQO3rcBRVFvwp.IEnBi3QUllUp.4zXehbVN.tI_HrAe2sEA.9c4eVsXvy.LgVrPHVcRRlv0 ywbRSMuczopt.PC24_WrvPtowXj9YPUYAEEbM.V4TsLAOd.MN2iwhFcvritPcD8JLQJHJs_mo30P zvT7z4pjgSb_zP03fuN0KOmrW3hPsUuvVHE9M97sufgzLvbG0HZtFu0o3Vg6lxaQJxE6Q.3N1I4D dW_vYNLoFiOP1hU0SLIYQpUHJ1eeqUiGQswcI07T_4vkX.JDnFkTOK9HU7Sw6jhqEXT8w9AkB9QX qiZ9KIPEOzOynQNwAKiWHauMP_x6AWSzqbB9f00b1dNU8Mr9kbwINqX99eS2GB4tXUK5coX88x_i nItyLQhZRxBUCSx28tRMlZ_TRU7ZAbILdykINuhghFv6bfFJr7BppxhrNCcWpQic7IxnveygxjYT 6p_RSN25F980ZuT.gbaH5ZXC1x3z5jDp6V.BFELh1BsccV.Zk.QtQwbmg_.Gq3hjEVerFGqqd9cN _xcoA1tuTO1w4FN2vnVXtiM3tdEKzZHHsOEVgyWJhT192oqEgDADIDKAUYwSuZQkeDbVy4KCpaQg A7uHqH8Zo2T0Lj5LLKy9GDjWtY7szf_.pHU4mV6q.cKmCJhjtzigiXCUR.RHgyoi7ONCERi5yXFQ PmGpdbKBx.xzDoUfK3KkMX56327Eg8UH5Bi9j6C5F7ikfcd6JJcDRrfYa2Voko_llXbxejCDlfoy vN9Y56CLk56rTg4UpkVdxUVG9wH0VysmvzbZi1InBsiaZBl41MgFeOvBmLBJiZIaJkKbnD_LBz4s K1pkXDLpvqXq5MmNrq1f8W_OlGnUIuVwMnaC9ZEps9KVdcbqYZ..sPc1W3rPJbKWdFWlqNNYLS3b uaULIhBLYY4ik Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Wed, 15 Aug 2018 15:10:35 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp407.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 67b58e2ce7e63edd40e30a7fd13e71f4; Wed, 15 Aug 2018 15:10:32 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (grace under pressure) From: Mark Millard In-Reply-To: <16004AB0-B499-4F30-8C14-AAE5E45B0A3B@yahoo.com> Date: Wed, 15 Aug 2018 08:10:30 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <01136DB2-F635-4F2A-9167-C34195993914@yahoo.com> References: <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> <2f3bed05-b27e-420b-e831-1c8286edf35e@sentry.org> <16004AB0-B499-4F30-8C14-AAE5E45B0A3B@yahoo.com> To: Trev 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, 15 Aug 2018 15:10:37 -0000 [Add notes about the clan g versions around in 2016-Oct.] On 2018-Aug-15, at 7:39 AM, Mark Millard wrote: > On 2018-Aug-14, at 5:20 PM, Trev wrote: >=20 >> George Mitchell wrote on 15/08/2018 08:33: >>> On 08/14/18 18:17, Jedi Tek'Unum wrote: >>>> I firmly disagree with the entire concept of out of memory killers. = They are simply evil and in my opinion a complete cop-out. I first = encountered this kind of kludge back in the =E2=80=9880s with AIX. It = was bad then and it still is today. Frankly I find it ridiculous that = they still exist. >>>> [...] >>> However: consider the subject (Raspberry Pi). -- = George >>=20 >> When researching whether 512M of RAM was considered "usable" for a = FreeBSD buildworld, I came across [https://reviews.freebsd.org/D8302] = from October 2016 where just 256M was considered a test case for i386 = and amd64 (-j1 I'm assuming) buildworlds which should succeed. >=20 > What I see there is pho writing: >=20 > QUOTE > I have run stress2 testes on i386 and amd64. > I ran a buildkernel on both i386 and amd64 with 256MB RAM / UP. > Buildworld was run with various small RAM configurations. > END QUOTE >=20 > It explicitly lists buildkernel for 256 MiBytes of RAM, not > buildworld. I'm not sure what the "UP" is for. "RAM / UP" > looks like it might be a ratio but may be it was indicating > not SMP? It not clear if this buildkernel testing included > kernel-toolchain as well. >=20 > buildworld was listed separately with nothing explicit about > what "small RAM" was considered to be. >=20 > If stress2 is configurable, there is no information on what > the specific test was for retrying the same test or knowing > just what the test was. I'm not sure which toolchain was used for any buildworld or any kernel-toolchain activity. But looking around inside https://svnweb.freebsd.org/base/projects/ shows that https://svnweb.freebsd.org/base/projects/clang390-import/?view=3Dlog had a last check-in on 2016-Nov-24 and was created on 2016-Aug-16. So clang 3.9.0 or an earlier clang. (clang was the default for x86's so I've assumed that it was used.) I'm not sure how similar that was to now with clang 6. It might be interesting if pho's tests could be re-run but for modern head. >> Regardless, my RPi3B+ OOMA issues were completely eliminated by = replacing the 16G SanDisk "Ultra" card with a "faster" 32G SanDisk = "Extreme" card which contains all file systems as well as a swap = partition and runs -j4 buildworld flawlessly. I think this lends some = support to Warner's view. =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 15 19:30: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 1C37D106D705 for ; Wed, 15 Aug 2018 19:30:39 +0000 (UTC) (envelope-from jedi@jeditekunum.com) Received: from a1i76.smtp2go.com (a1i76.smtp2go.com [43.228.184.76]) (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 6CAD175BFB for ; Wed, 15 Aug 2018 19:30:39 +0000 (UTC) (envelope-from jedi@jeditekunum.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=m4fue0.a1-4.dyn; x=1534362339; h=Feedback-ID: X-Smtpcorp-Track:To:Message-Id:Date:From:Subject:Reply-To:Sender: List-Unsubscribe; bh=f1H5LPCUgxfVV3jpyPCy6CRfsMjFrBnEAimFnw1qAO8=; b=ZLugQaUW iZBzeIdiK3LlnupbeQRiGIbpz/4Lvlqf4caskGniEWrNidehRYsFm9ImKjFlCozCnzneoh6fTLWUp Edke2j3D6Ev0VeN8tmUjXuPaBCcpgmmwKZtQyt7AYL1+SKouUoh9HWii5EKa/a6+m8sCrJB4/Tcnn jPuuyN0WfAFzZaKJ1tFlQCys81nIG8sNRFIr++DkxGziOICUx6eJsdZef+ReHWMghz1JtlNA65khZ bGmlQSzeaVXb1yH0kafsU6wXXR7gRigpGbQi/GDCqk7t8vyFYjuDFqUFZ4ZtA2zMTBNXgkplCRKNK JtJ+kfyxFRRUQJ6fYfZUVDXoGw==; Received: from [10.45.33.53] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fq1V7-WxjwRQ-9M; Wed, 15 Aug 2018 19:30:37 +0000 Received: from [10.162.213.37] (helo=takodana.opaxus.net) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1fq1V6-rlZDTd-GO; Wed, 15 Aug 2018 19:30:36 +0000 Received: from dagobah.opaxus.net (173-28-113-92.client.mchsi.com [173.28.113.92]) by takodana.opaxus.net (Postfix) with ESMTPSA id 16E6111ABC; Wed, 15 Aug 2018 14:30:34 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (grace under pressure) From: Jedi Tek'Unum In-Reply-To: <20180815125513.GT97145@funkthat.com> Date: Wed, 15 Aug 2018 14:30:34 -0500 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> <20180814213107.GA51051@www.zefox.net> <20180815125513.GT97145@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3445.9.1) X-Smtpcorp-Track: 1fq1V6r_ZDTdGO.dD9d83zT- Feedback-ID: 207158m:207158azGM_-I:207158s4k39g8-gK:SMTPCORP X-Report-Abuse: Please forward a copy of this message, including all headers, to 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, 15 Aug 2018 19:30:40 -0000 On Aug 15, 2018, at 7:55 AM, John-Mark Gurney wrote: >=20 > Jedi Tek'Unum wrote this message on Tue, Aug 14, 2018 at 17:17 -0500: >> I have one question??? when was the last time anyone saw Solaris kill = a process because the system was under memory stress? In my experience, = NEVER! And I wouldn???t say that the system became unreasonably = unresponsive either. >=20 > At least for Solaris 2.5, they would not allow overallocation of = swap... > If you had pages that could be modified, you had to have enough swap > storage to store a copy of those pages... If you didn't, you'd get an > out of memory error when trying to allocate the memory, such as = forking, > sbrk or mmap'ing... That=E2=80=99s an entirely different situation. The process that wants = the memory gets the error from a syscall. The only =E2=80=9Ccrime=E2=80=9D that the OOM killer victim has is that = it was selected because of its state. Gets no chance to do anything = useful - just boom, gone. From owner-freebsd-arm@freebsd.org Wed Aug 15 19:41: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 10348106E23A for ; Wed, 15 Aug 2018 19:41:49 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from hraggstad.unrelenting.technology (hraggstad.unrelenting.technology [IPv6:2605:2700:0:3:a800:ff:fee9:2feb]) (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 76AE477601 for ; Wed, 15 Aug 2018 19:41:48 +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=jJOu5beiznVTd+piVy7yMtMJ44pfbsEbFpLwqUeoIng=; b=FXZhF/SLpKzwESGnEKZsQQfY2N0/LoEmTjr3spwhqohkB9eL21f7tR/5vVZXHoxz/eg34shToV7ReQ0iTSKJfY2wAluEU9sgNJrjKtNfIIgmZ9Ydh/hpKku15+czCCtSpt0+w9Ibs0eJrBWkhMXYRLvrdWL0m3MK3cWbKFej1Vc= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id 57168b9b TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 15 Aug 2018 19:41:41 +0000 (UTC) Date: Wed, 15 Aug 2018 22:41:34 +0300 From: Greg V Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Ganbold Tsagaankhuu Cc: Emmanuel Vadot , freebsd-arm Message-Id: <1534362095.3897.1@hraggstad.unrelenting.technology> In-Reply-To: References: <1533577708.4175.0@hraggstad.unrelenting.technology> <1534253037.1656.0@hraggstad.unrelenting.technology> <20180815105602.b106e1f55a3f839880b1b60e@bidouilliste.com> 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: Wed, 15 Aug 2018 19:41:49 -0000 On Wed, Aug 15, 2018 at 5:30 PM, Ganbold Tsagaankhuu=20 wrote: >=20 >=20 > On Wed, Aug 15, 2018 at 4:56 PM, Emmanuel Vadot=20 > wrote: >> On Tue, 14 Aug 2018 21:30:11 +0800 >> Ganbold Tsagaankhuu wrote: >>=20 >> > Greg, >> > >> > On Tue, Aug 14, 2018 at 9:23 PM, Greg V=20 >> wrote: >> > >> > > >> > > >> > > On Tue, Aug 14, 2018 at 2:01 PM, Ganbold Tsagaankhuu=20 >> >> > > wrote: >> > > >> > >> Greg, >> > >> >> > >> On Tue, Aug 7, 2018 at 1:48 AM, Greg V=20 >> >> > >> wrote: >> > >> >> > >>> Hi, >> > >>> >> > >>> I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64=20 >> ROCKPro64 >> > >>> board): >> > >>> >> > >>>=20 >> https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 >> > >>> >> > >>> As with the ROCK64, boot is over the network. To boot, dd=20 >> ayufan's >> > >>> ubuntu image onto an sdcard and Ctrl-C the linux boot on the=20 >> kernel >> > >>> selection screen. U-Boot on SPI flash is not available yet. >> > >>> >> > >>> Unfortunately, performance is very disappointing ? I think the=20 >> big >> > >>> cluster's default frequency is very low. >> > >>> (Everything runs faster if cpuset to the LITTLE cores.) >> > >>> >> > >>> Looks like we'll need a driver for the "rockchip,rk808" PMIC=20 >> to make >> > >>> cpufreq_dt work? >> > >>> Also my attempt at the clock driver is very incomplete ;) >> > >>> >> > >> >> > >> Can you change the patches according to style(9) for=20 >> phabricator review ( >> > >> https://reviews.freebsd.org) and send them to me? >> > >> I think full files should be fine too. >> > >> >> > > >> > > My patches are rather incomplete and janky, don't do anything=20 >> with them. >> > > manu@ got a ROCKPro64 recently https://twitter.com/manuvadot/ >> > > status/1027152057051041793 so you can expect proper versions of=20 >> these >> > > "soon" :) >> > > >> > >> > >> > I meant to say that we can rather use your patches if no one did=20 >> it yet. >> > >> > Emmanuel, >> > >> > Do you have proper patches yet? >>=20 >> No and I'm not in a hurry to put everything up for RK3399 so close=20 >> to >> freeze. >=20 > Yes, I agree. >=20 >=20 >> But if you want to clean them and put this in a review be my guest, >> I'll review them. >=20 > Ok, I will see if I'll have some time to polish it unless someone=20 > else will do it. >=20 > thanks, >=20 > Ganbold Alright everyone, good news =97 I managed to reclock the CPU!!! The patch is now at https://reviews.freebsd.org/D16732 (and I think the style is more correct now. Though it's really fscking=20 silly that the style doesn't like making "table-like" structures look=20 like tables, i.e. with one-line "rows".) Plus the hack you need to reclock the CPU right now at=20 https://gist.github.com/myfreeweb/88cb9340652f56498f4be770c77b9d61 (the hack allows cpufreq_dt to deal with clock only, no voltage =97=20 since we don't have all the drivers for voltage.) BTW, the sysctl cpufreq interface is a bit funny with big.LITTLE: dev.cpu.4/5 do not have any freq stuff, it's all on dev.cpu.0 =97 and=20 it displays only the LITTLE frequencies: dev.cpu.0.freq_levels: 1512/-1 1416/-1 1200/-1 1008/-1 816/-1 600/-1=20 408/-1 dev.cpu.0.freq: 1512 To maximize the big frequency, I need to set *that* to a big number=20 e.g. dev.cpu.0.freq=3D2000 =97 that results in 1512/1992. Setting 1512 there (which is what powerd does in this situation, since=20 it does not have any info about big) results in 1512/1608 =97 quite=20 underclocked on the big cores. = From owner-freebsd-arm@freebsd.org Wed Aug 15 20:20:33 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 D695B106F077 for ; Wed, 15 Aug 2018 20:20:33 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 6F3107927F; Wed, 15 Aug 2018 20:20:33 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id v71-v6so3672760itb.3; Wed, 15 Aug 2018 13:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=go6nfYkmQK88CbdKip54C0opmx8itrP2VpPjqWMES1E=; b=tkpb9uaZ2IWC0r3OyiSXsb3aq7jnCCSplNNliukgMtwoN7GyNfbzepYF4TBzFw9PUp 3j7dnhkkULB1An0eA1ox8NprPAcVPi0gUlIo6MdWvFYdLO74tbXObxeLNByg1UR5Zd0C kuMK0fp6eHP+CfF2TG9EezNsv70Ih3EfZCru0Ewk8y8Mv5+9UesKR/fTS87/UGWlTozn rqn2uU2S7AGC7PIKZnKlpnK9Vf7OL/hzxhCS4Ubc9mXTGk+/fcKvQw/4Ao/dZNQ5D/E4 HtP9pvHDPrtZhTSlPeSBDdC7o1Za4XXd1zQgC4FZtTnT6J1ZfTORgRqWlQOVwpHwxf9A aOOA== 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:from:date:message-id:subject :to; bh=go6nfYkmQK88CbdKip54C0opmx8itrP2VpPjqWMES1E=; b=rQGd2lmRr0IU+ID8IhqQISjq4XIG1+TpWmEz6PF6ozNyewGUia+PTE6PkJ72mb5KTb /lVoh/xIkWod7uSqhCzSjNL2ka2FPPFSpdFbRlQKVMZowFCQuucH98r0TvWH1mLN6uGc JIZnxdunDnlUJSXR9IXFxE3dwrFF+lufgRWGQWq7251c7sqOfP8/SPR4Sv+NBK4Z2fxR L1LGppUMhoP/KsNrijrAuf/OtniaBTZ8Y76RXHvDXySDpCHpPyVCgnsaSL2BAM8Day6L 6IYTXZ8uUOIEwpB36L9DjlNGMMn83o/osLgYwvTEDXiGyF1+oGhgK4Ck9fSyZsAXJiJZ 1ixQ== X-Gm-Message-State: AOUpUlGNqHGFqyVUpETcmQoF1DGMQ1bdG0YVS9cuB5Sq44MlVJirn/6I 9kd/31bHfTVg1PmaQwioT4YAjfcHUH/uLrqvde0wQA== X-Google-Smtp-Source: AA+uWPxm559sLDrzB1vFFrzAx2CWa6Tr4Srbh3qREp6Y6qY78sMuUTrgEPetFTu6YN2d/SvPmH9BzqLnRpODnWBNx7Y= X-Received: by 2002:a24:1fc7:: with SMTP id d190-v6mr18316388itd.52.1534364432726; Wed, 15 Aug 2018 13:20:32 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:4a08:0:0:0:0:0 with HTTP; Wed, 15 Aug 2018 13:20:12 -0700 (PDT) From: Ed Maste Date: Wed, 15 Aug 2018 21:20:12 +0100 X-Google-Sender-Auth: HHv8-u_z-ZYD9jejvBT0dluqp8A Message-ID: Subject: RFC: Switching armv7 to WITH_LLD_IS_LD for testing To: "portmgr@FreeBSD.org" , freebsd-arm 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: Wed, 15 Aug 2018 20:20:34 -0000 For amd64 I requested (and for i386 continue to request) multiple exp-runs with lld as the system linker (/usr/bin/ld) before switching the default in src.conf.5. I'd like to switch armv7 to WITH_LLD_IS_LD; unfortunately we don't have an easy way to execute an exp-run for arm (armv7 specifically). If there's no objection I would like to enable WITH_LLD_IS_LD for armv7, observe a cycle of ports build, with a plan to leave it enabled if the build is largely successful, or revert if not. Comments? From owner-freebsd-arm@freebsd.org Wed Aug 15 20:27:30 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 A4A15106F4AD for ; Wed, 15 Aug 2018 20:27:30 +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 3BCC279A58 for ; Wed, 15 Aug 2018 20:27:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id g141-v6so3690639ita.4 for ; Wed, 15 Aug 2018 13:27:30 -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=knyoIUkIbySHC3sk2S/cE6TFM1KFXvBbu0pD8IIEKsM=; b=HOsb7n61MgajNabTi0JSeCu21Q0LkQynxtDmZibhtYZsdaSN0EROAempAt4TtXf/0K CjJ1/IxSmLHl4tdh8q58l2Alkr7BW3ot+ha2F04XKzZiemP67zPk6/r9dSXMQ26du9yr 7VTDxzRz3jP8V3dFdij5LzRmbnlGXF+uOK8IMH2OgqAtwYFlmXyMAabkvI/4FPoIIwIW LSx05UnkxmBr5AsXeyU656hxchf1K5PsRACwkVpJcLPub2VCWBTkjFUUcF9M+Qk597Q/ za3UH6WQMoKkapbh/oxpSdCzn7qZ8hvWvKLKDqVX1KQuo5xRPOFgLXUzrVCxjad022fL LH7w== 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=knyoIUkIbySHC3sk2S/cE6TFM1KFXvBbu0pD8IIEKsM=; b=PGR/Bqvx3AW0zCPtl4gRT5StZcUQ+02bpFX4J6avYPE5I6nt1xGZN5h1NdRLKvI0FF bok2Zn2+3V9KP0l/WxTMj3dWYtdxV88qt/fzpT4qDBU1byI//ifCRKIjSh6ytvrR09F/ zXkn7Vuz9JJ0w8QKI8Hz9Ran3cwZhreh5Dru1crFXc6yBWMgucyW/hLSXHhO2IbvGJHO EWE+5SzqitiGrAqJESdwXMqs1bY4++HGz6mzQq9SXv7/bsaGoz3o+QiVeEQ8QVfhp5Jt +WEilV45iL8JgL4/aEeZnmqrmikOZYStHpGzXwl1XhrFAPAGDXia2Qx3Fwgkp0H7rJIE BCTA== X-Gm-Message-State: AOUpUlHwuToPMzIuu6oMhs+Yqhnk/UIJygNRWfIG5YWf6rgI4PN4zwZA f/c7xkEZ93L859qJwBHjeA2XGz/7bo12NA+AGgs72w== X-Google-Smtp-Source: AA+uWPwq8oC6EWCXn42UoX7NOtnyTzLzk1Ypb530zaKhbRa1u5oFqxMcOsceEPhdWHeQtLl0NgYtFsjEwb6/da1lFEY= X-Received: by 2002:a24:b211:: with SMTP id u17-v6mr18786251ite.1.1534364849391; Wed, 15 Aug 2018 13:27:29 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:257:0:0:0:0:0 with HTTP; Wed, 15 Aug 2018 13:27:28 -0700 (PDT) X-Originating-IP: [50.227.106.226] In-Reply-To: References: From: Warner Losh Date: Wed, 15 Aug 2018 14:27:28 -0600 X-Google-Sender-Auth: MHWrPAsxrdqmC9FSRloUc39o_3c Message-ID: Subject: Re: RFC: Switching armv7 to WITH_LLD_IS_LD for testing To: Ed Maste Cc: "portmgr@FreeBSD.org" , freebsd-arm 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: Wed, 15 Aug 2018 20:27:31 -0000 On Wed, Aug 15, 2018 at 2:20 PM, Ed Maste wrote: > For amd64 I requested (and for i386 continue to request) multiple > exp-runs with lld as the system linker (/usr/bin/ld) before switching > the default in src.conf.5. > > I'd like to switch armv7 to WITH_LLD_IS_LD; unfortunately we don't > have an easy way to execute an exp-run for arm (armv7 specifically). > If there's no objection I would like to enable WITH_LLD_IS_LD for > armv7, observe a cycle of ports build, with a plan to leave it enabled > if the build is largely successful, or revert if not. > > Comments? > My only issue with lld on arm is the bug I'm chasing wrt arm kernel builds somehow using lld... But I don't think that's going to affect this one way or another. I'm happy with it assuming the exp run doesn't reveal some show stopper Warner From owner-freebsd-arm@freebsd.org Wed Aug 15 20:44:55 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 0EDE7106FF88 for ; Wed, 15 Aug 2018 20:44:55 +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 86AEB7AA73 for ; Wed, 15 Aug 2018 20:44:54 +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 e5011398; Wed, 15 Aug 2018 22:44:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=nepH2egrnd6bza1Y4PEdpefhjvI=; b=LkWYoroWoHyPsZ1lv1mZXjxUbVoq 7RSn17HGpJuB8kXxIzLfN7O2Po6PJ6PFliXC9EBiSlZtKAHy+y2M9jruHmndYoSF 5oLv717vcK2G2lTVrmW6iEDuYdS3rEXkbkEZmPRxbJhsu+js0E8MHkpkuQEdGm1a Dn311n5waSa5GXQ= 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=n+GXPI6iH79+MYgyrwVNcswM49jCvV85SX5+a1U1ho7/3n0xktYYsmi2 nGIvnkOjVUM/9XluKVSzrrtaIIvVTBeEOZZ+M1edlQGpEltqbqFVz+IwZ/ZJwc3X goORWAYh/lEMAItT3vHtoggV5sE2SH/lDxWf1t8RtRWNE8CY6V8= Received: from knuckles.blih.net (global-5-53.nat-1.net.cam.ac.uk [131.111.5.53]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 821f1ff6 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 15 Aug 2018 22:44:51 +0200 (CEST) Date: Wed, 15 Aug 2018 22:44:49 +0200 From: Emmanuel Vadot To: Greg V Cc: Ganbold Tsagaankhuu , freebsd-arm Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser Message-Id: <20180815224449.98b920836c2c7f8610449835@bidouilliste.com> In-Reply-To: <1534362095.3897.1@hraggstad.unrelenting.technology> References: <1533577708.4175.0@hraggstad.unrelenting.technology> <1534253037.1656.0@hraggstad.unrelenting.technology> <20180815105602.b106e1f55a3f839880b1b60e@bidouilliste.com> <1534362095.3897.1@hraggstad.unrelenting.technology> 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: Wed, 15 Aug 2018 20:44:55 -0000 On Wed, 15 Aug 2018 22:41:34 +0300 Greg V wrote: >=20 >=20 > On Wed, Aug 15, 2018 at 5:30 PM, Ganbold Tsagaankhuu=20 > wrote: > >=20 > >=20 > > On Wed, Aug 15, 2018 at 4:56 PM, Emmanuel Vadot=20 > > wrote: > >> On Tue, 14 Aug 2018 21:30:11 +0800 > >> Ganbold Tsagaankhuu wrote: > >>=20 > >> > Greg, > >> > > >> > On Tue, Aug 14, 2018 at 9:23 PM, Greg V=20 > >> wrote: > >> > > >> > > > >> > > > >> > > On Tue, Aug 14, 2018 at 2:01 PM, Ganbold Tsagaankhuu=20 > >> > >> > > wrote: > >> > > > >> > >> Greg, > >> > >> > >> > >> On Tue, Aug 7, 2018 at 1:48 AM, Greg V=20 > >> > >> > >> wrote: > >> > >> > >> > >>> Hi, > >> > >>> > >> > >>> I managed to boot FreeBSD on the Rockchip RK3399 SoC (Pine64=20 > >> ROCKPro64 > >> > >>> board): > >> > >>> > >> > >>>=20 > >> https://gist.github.com/myfreeweb/5f5b9e56f9a0fd1d63a46c34886f5ad1 > >> > >>> > >> > >>> As with the ROCK64, boot is over the network. To boot, dd=20 > >> ayufan's > >> > >>> ubuntu image onto an sdcard and Ctrl-C the linux boot on the=20 > >> kernel > >> > >>> selection screen. U-Boot on SPI flash is not available yet. > >> > >>> > >> > >>> Unfortunately, performance is very disappointing ? I think the=20 > >> big > >> > >>> cluster's default frequency is very low. > >> > >>> (Everything runs faster if cpuset to the LITTLE cores.) > >> > >>> > >> > >>> Looks like we'll need a driver for the "rockchip,rk808" PMIC=20 > >> to make > >> > >>> cpufreq_dt work? > >> > >>> Also my attempt at the clock driver is very incomplete ;) > >> > >>> > >> > >> > >> > >> Can you change the patches according to style(9) for=20 > >> phabricator review ( > >> > >> https://reviews.freebsd.org) and send them to me? > >> > >> I think full files should be fine too. > >> > >> > >> > > > >> > > My patches are rather incomplete and janky, don't do anything=20 > >> with them. > >> > > manu@ got a ROCKPro64 recently https://twitter.com/manuvadot/ > >> > > status/1027152057051041793 so you can expect proper versions of=20 > >> these > >> > > "soon" :) > >> > > > >> > > >> > > >> > I meant to say that we can rather use your patches if no one did=20 > >> it yet. > >> > > >> > Emmanuel, > >> > > >> > Do you have proper patches yet? > >>=20 > >> No and I'm not in a hurry to put everything up for RK3399 so close=20 > >> to > >> freeze. > >=20 > > Yes, I agree. > >=20 > >=20 > >> But if you want to clean them and put this in a review be my guest, > >> I'll review them. > >=20 > > Ok, I will see if I'll have some time to polish it unless someone=20 > > else will do it. > >=20 > > thanks, > >=20 > > Ganbold >=20 > Alright everyone, good news ? I managed to reclock the CPU!!! >=20 > The patch is now at https://reviews.freebsd.org/D16732 Thanks a lot !! I'll have a deeper look when I'm back from BSDCam. > (and I think the style is more correct now. Though it's really fscking=20 > silly that the style doesn't like making "table-like" structures look=20 > like tables, i.e. with one-line "rows".) > > Plus the hack you need to reclock the CPU right now at=20 > https://gist.github.com/myfreeweb/88cb9340652f56498f4be770c77b9d61 >=20 > (the hack allows cpufreq_dt to deal with clock only, no voltage ?=20 > since we don't have all the drivers for voltage.) Are you able to switch to any frequency with that ? I would expect the cpu to hang if the voltage is too low or too high. (I encounter that on RK3328) > BTW, the sysctl cpufreq interface is a bit funny with big.LITTLE: > dev.cpu.4/5 do not have any freq stuff, it's all on dev.cpu.0 ? and=20 > it displays only the LITTLE frequencies: >=20 > dev.cpu.0.freq_levels: 1512/-1 1416/-1 1200/-1 1008/-1 816/-1 600/-1=20 > 408/-1 > dev.cpu.0.freq: 1512 >=20 > To maximize the big frequency, I need to set *that* to a big number=20 > e.g. dev.cpu.0.freq=3D2000 ? that results in 1512/1992. > Setting 1512 there (which is what powerd does in this situation, since=20 > it does not have any info about big) results in 1512/1608 ? quite=20 > underclocked on the big cores. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Aug 15 20:57: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 85D54107061C for ; Wed, 15 Aug 2018 20:57:18 +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 DDEA37B488 for ; Wed, 15 Aug 2018 20:57:17 +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=Xeyb4Zr4ZSgDg8+7KwbFKa0HuSuXM2NR6F2Pk2J4EwY=; b=QHuR7+EczWJEoP2rj/2IG89b22pVhHMrSh8vAZtSCtne3iGqzsT6wKTINDgfCBUEhOHfMbtvi5aVzTVxBsP3sulpKRyE42C2S7zgH3HgTDrdiA12iFVkJNWSFd34G0auJ4NMvPnk/Tdcv823BRVuhl6moPirHJY0yfYVvulrkOM= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id d273568a TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 15 Aug 2018 20:57:08 +0000 (UTC) Date: Wed, 15 Aug 2018 23:57:01 +0300 From: Greg V Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Emmanuel Vadot Cc: Ganbold Tsagaankhuu , freebsd-arm Message-Id: <1534366621.3897.2@hraggstad.unrelenting.technology> In-Reply-To: <20180815224449.98b920836c2c7f8610449835@bidouilliste.com> References: <1533577708.4175.0@hraggstad.unrelenting.technology> <1534253037.1656.0@hraggstad.unrelenting.technology> <20180815105602.b106e1f55a3f839880b1b60e@bidouilliste.com> <1534362095.3897.1@hraggstad.unrelenting.technology> <20180815224449.98b920836c2c7f8610449835@bidouilliste.com> 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: Wed, 15 Aug 2018 20:57:18 -0000 On Wed, Aug 15, 2018 at 11:44 PM, Emmanuel Vadot=20 wrote: > On Wed, 15 Aug 2018 22:41:34 +0300 > Greg V wrote: >> Alright everyone, good news ? I managed to reclock the CPU!!! >>=20 >> The patch is now at https://reviews.freebsd.org/D16732 >=20 > Thanks a lot !! > I'll have a deeper look when I'm back from BSDCam. >=20 >> (and I think the style is more correct now. Though it's really=20 >> fscking >> silly that the style doesn't like making "table-like" structures=20 >> look >> like tables, i.e. with one-line "rows".) >>=20 >> Plus the hack you need to reclock the CPU right now at >> https://gist.github.com/myfreeweb/88cb9340652f56498f4be770c77b9d61 >>=20 >> (the hack allows cpufreq_dt to deal with clock only, no voltage ? >> since we don't have all the drivers for voltage.) >=20 > Are you able to switch to any frequency with that ? > I would expect the cpu to hang if the voltage is too low or too high. > (I encounter that on RK3328) Yeah =97 I maxed the clocks for both big and LITTLE cores and got=20 pretty great performance. e.g. unixbench dhrystone index with cpuset to a big core: 804 =97 which=20 is more than the 737 I got on Scaleway's ThunderX VPS! ThunderX is still way better on unixbench's other tests though. Not that unixbench is a great test=85 Compiling neovim also took *way* less time than on RPi/ROCK64. So, I think the big cores' voltage regulator (silergy,syr827) might=20 just default to the highest voltage. The chip gets rather warm when just idling in FreeBSD=85 = From owner-freebsd-arm@freebsd.org Wed Aug 15 22:17:20 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 4403C107263B for ; Wed, 15 Aug 2018 22:17:20 +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 8FA697F326; Wed, 15 Aug 2018 22:17:19 +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 w7FMHTN1059183 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Aug 2018 15:17:30 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7FMHScU059182; Wed, 15 Aug 2018 15:17:28 -0700 (PDT) (envelope-from fbsd) Date: Wed, 15 Aug 2018 15:17:28 -0700 From: bob prohaska To: Mark Millard Cc: Mark Johnston , John Kennedy , freebsd-arm , bob prohaska Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180815221728.GA59074@www.zefox.net> References: <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@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, 15 Aug 2018 22:17:20 -0000 On Sun, Aug 12, 2018 at 08:36:01PM -0700, Mark Millard wrote: [snip] > > I'd keep multiplying by 10 until it works (or fails some > other way), then back off by smaller factors if you want > a narrower range to be known between failing and working > (or failing differently). > [snip] > > The factor of 10 rule makes the number of tests > logarithmic to find an sufficient upper bound (if > there is an upper bound). After that with high/low > bounds binary searching is a possibility. > Updated to r337688 with 2 GB of swap divided between USB and microSD. Using vm.pageout_oom_seq=1024, a -j4 buildworld failed with da0 errors reported, panic'd and rebooted. A -j3 buildworld ran to completion with several dozen "indefinite wait..." messages but no other complaints. IIRC, this swap configuration wouldn't even run -j2 to completion with vm.pageout_oom_seq=12, so the increase to 1024 clearly helps and the da0 errors suggest something else gives up if taxed to -j4. During the -j3 buildworld, at about the 26 MB point in the log file top reported ld.lld having "size" of 1037 MB, but only 60 MB of swap were in use. With only 1 GB of main memory, is that to be believed? The backtrace emitted by the -j4 panic is somewhat longer than usual, it's in the file named console at http://www.zefox.net/~fbsd/rpi3/swaptests/r337688/1gbsd_1gbusb/ in case it's of interest. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Wed Aug 15 22:54:51 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 EB32E107366D for ; Wed, 15 Aug 2018 22:54:50 +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 54A4481653; Wed, 15 Aug 2018 22:54:50 +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 w7FMt5rg059283 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Aug 2018 15:55:06 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7FMt40i059282; Wed, 15 Aug 2018 15:55:05 -0700 (PDT) (envelope-from fbsd) Date: Wed, 15 Aug 2018 15:55:04 -0700 From: bob prohaska To: Warner Losh Cc: Mark Millard , freebsd-arm , Mark Johnston , bob prohaska Subject: Re: RPI3 swap experiments (grace under pressure) Message-ID: <20180815225504.GB59074@www.zefox.net> References: <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@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: Wed, 15 Aug 2018 22:54:51 -0000 On Tue, Aug 14, 2018 at 10:26:39PM -0600, Warner Losh wrote: [eloquent VM discussion snipped] > So I think what's well tuned for the gear that's in a server doing > traditional database and/or compute workloads may not be so well tuned for > the RPi3 when you put NAND that can vary a lot in performance, as well as > have fast reads and slow writes when the mix isn't that high. The system > can be tuned to cope, but isn't tuned that way out of the box. > > tl;dr: these systems are enough different than the normal system that > additional tuning is needed where the normal systems work great out of the > box. Plus some code tuneups may help the algorithms be more dynamic than > they are today. > When I started this goose chase, after zero problems with RPI2, I thought the issue was arm64-related and might be of some fundamental importance. Thanks to many people I now understand it's a confluence of USB and flash memory artifacts, made evident by the demands of clang6. Elsewhere I noted that I'm seeking "the robustness of a Mars rover, using a rack server OS on a cellphone motherboard". 8-) With my thanks to all for much patient good counsel, bob prohaska From owner-freebsd-arm@freebsd.org Thu Aug 16 01:51: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 46C4A1078139 for ; Thu, 16 Aug 2018 01:51:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-14.consmr.mail.bf2.yahoo.com (sonic316-14.consmr.mail.bf2.yahoo.com [74.6.130.124]) (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 E033F888FB for ; Thu, 16 Aug 2018 01:51:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: sAjtLbcVM1mo5jTUjmJjvHwQFGJRLg7XKG1KD0mkyHec8gDfOuiFHGKWfof7Kcf ykV3dfkNLJ5y6ZmpVcAvm..4OBngEasuFVJd6d4QwcUMbFeVpUPP6LmnIu1zvmLCD0AdX5WL79vD A3BuIJ1Vtp5V7VETzKsjjDhAiTcCX67d2.wT04I4b45aTfoh9_.ZiuiYs1afhGi.CSU8VjMKPmBv S_ymOl8aG6hHqPE1R27.zCuHBcbIq9MpwTxrKKFKunosnKxrh0Gfp02mCloWM1R.QbFTDAaVOU5U ptih3pcZ7.3unHKD6yEvf6ZCIlrXEqm8i9XWlVGaDebN8GQTPFHGHYPFWmNuY.2NzsXsmpAn9fFv W6I4MGnNbqKoTcgOPQYtr0FYfXOvhonBIv6xk_D7YuZIMlQny3FnLJAaTJRSjja6uggjyt4dD1oP I7iewrXoyonUjJgRGA6zynW_6iRezKG_1VIhpstwOQm.pFWd.lm0bweeUHVje8idv2Hkl5Z_xe2. 0lpiLR0koeBN9ufzpy3nVlTvb2RNwNXrnVpZ.L7Z1cJ8.7d0OgujNI6ksREXE_Cc..6YkJRcIRHq C6RLrwE0Nheni1g6n4LvCKWngHynJ88wvxa94iYhSuY242g_OUhRK__RULUBg0DTAkjhBSSiXvu8 K_I_b4YC8Tc0q6wSMP.FxFNyR7fl3ieIJyaC0fqbdI1XP63pdY6KIESbffsAldwbcjAKDX.Aasdb gimTaUSs2MSjSrGZ6j0sCP_duVPZQAj3Js8RyYKnElXeMQXcHT_hRd_zqy9EBSQlgziZWc18.3sL sZ3X1JOFmit1Z5QXeWTi.YwB6tZuA4U230ml4lTjcwS7TKU.6LRuKnVVYviTgkTw4zQRs0DR077T aUMc_aDCqkjJ4uGXeK9sYB1JwYgmuHcnm784MyS3XZm2hXAIILMz0l9.AhtYsOkuyVWntV9N4mUS DIA75ImQCw3GO5Gs9vOg8S2PQ4uYGhDuaSm0dZcOL9HDzedDAzXC6Tq18RrLQQZspWMLRDS7MK_y 7FTIoDpO40Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Thu, 16 Aug 2018 01:51:16 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ccf5cb51266d94b5e223e9fbbff834fc; Thu, 16 Aug 2018 01:51: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: <20180815221728.GA59074@www.zefox.net> Date: Wed, 15 Aug 2018 18:51:12 -0700 Cc: Mark Johnston , John Kennedy , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <9EA5D75D-A03F-4B25-B65E-03E93DE30130@yahoo.com> References: <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180815221728.GA59074@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, 16 Aug 2018 01:51:23 -0000 On 2018-Aug-15, at 3:17 PM, bob prohaska wrote: > On Sun, Aug 12, 2018 at 08:36:01PM -0700, Mark Millard wrote: > [snip] >>=20 >> I'd keep multiplying by 10 until it works (or fails some >> other way), then back off by smaller factors if you want >> a narrower range to be known between failing and working >> (or failing differently). >>=20 > [snip] >>=20 >> The factor of 10 rule makes the number of tests >> logarithmic to find an sufficient upper bound (if >> there is an upper bound). After that with high/low >> bounds binary searching is a possibility. >>=20 > Updated to r337688 with 2 GB of swap divided between USB and microSD. > Using vm.pageout_oom_seq=3D1024, a -j4 buildworld failed with da0 = errors=20 > reported, panic'd and rebooted. A -j3 buildworld ran to completion = with=20 > several dozen "indefinite wait..." messages but no other complaints. >=20 > IIRC, this swap configuration wouldn't even run -j2 to completion with > vm.pageout_oom_seq=3D12, so the increase to 1024 clearly helps and the > da0 errors suggest something else gives up if taxed to -j4. You are likely subject to da0 failing sometimes for any -jN. But 4 buildworld form scratchs with -j1 might be less likely to have a failure than one from scratch buildworld with -j4, depending on why da0 fails. > During the -j3 buildworld, at about the 26 MB point in the log file=20 > top reported ld.lld having "size" of 1037 MB, but only 60 MB of swap > were in use. With only 1 GB of main memory, is that to be believed? I've no clue if FreeBSD gets into the concepts of reserved space vs. allocated space, some "space" being reserved but not allocated. In such a context, some of the space that is not allocated but is reserved might not need RAM allocated nor swap space allocated. top's figure seems to trace back to struct vm_map's size field, which is commented as /* virtual size */. The map entries are described as forming a binary search tree and a doubly-linked list. For all I know a map entry might always span a power of 2 bytes (for example) even when what is contained need not use all of it. There might be some binning sizes such that the minimum power of 2 that would hold the content need not be the power of 2 used (in the example). That extra might be a form of a reserved area in virtual space that is not allocated (yet). If something like that is going on then top's SIZE will tend to be bigger than what is allocated (summation of RAM and swap). (The power of 2 criteria is just an illustration. I've no clue of the actual criteria involved.) > The backtrace emitted by the -j4 panic is somewhat longer than > usual, it's in the file named console at=20 > http://www.zefox.net/~fbsd/rpi3/swaptests/r337688/1gbsd_1gbusb/ > in case it's of interest. I greatly doubt that FreeBSD is designed to survive the likes of: . . . (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 30 42 b8 00 00 20 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 30 42 b8 00 00 20 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted swap_pager: I/O error - pageout failed; blkno 133211,size 8192, error 5 swap_pager: I/O error - pageout failed; blkno 133213,size 8192, error 5 swap_pager: I/O error - pageout failed; blkno 133215,size 131072, error = 5 g_vfs_done():da0d[READ(offset=3D11492274176, length=3D4096)]error =3D 5 g_vfs_done():da0d[READ(offset=3D17284657152, length=3D4096)]error =3D 5 g_vfs_done():da0d[READ(offset=3D37422759936, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D805568512, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D827752448, length=3D32768)]error =3D 5 g_vfs_done():da0a[READ(offset=3D827916288, length=3D32768)]error =3D 5 swap_pager: I/O error - pagein failed; blkno 3780,size 8192, error 5 swap_pager: I/O error - pagein failed; blkno 11127,size 4096, error 5 swap_pager: I/O error - pagein failed; blkno 12162,size 4096, error 5 swap_pager: I/O error - pagein failed; blkno 128272,size 4096, error 5 vm_fault: pager read error, pid 1 (init) vm_fault: pager read error, pid 13373 (c++) vm_fault: pager read error, pid 13733 (c++) vm_fault: pager read error, pid 324 (devd) swap_pager: I/O error - pageout failed; blkno 133207,size 16384, error 5 (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 05 25 50 50 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 05 25 50 50 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 05 25 50 50 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain swap_pager: indefinite wait buffer: bufobj: 0, blkno: 200056, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3797, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 173323, size: = 36864 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3767, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3793, size: 4096 (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 05 25 50 50 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 05 25 50 50 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted . . . (There is a lot more, not quoted.) As I understand it the messages with "(da0:umass-sim0:0:0:0)" with retries exhausted are indicating that da0 simply failed to work, even with FreeBSD retrying the operation several times. As I understand, only the device reporting its own errors leads to those kind of messages by FreeBSD. (If Warner cares to, he should be able to correct any misimpression I might make here. There are others around that could as well.) So: then getting a panic such as . . . panic: vm_page_assert_unbusied: page 0xfffffd002e60ec40 busy @ = /usr/src/sys/vm/vm_object.c:736 may not be all that surprising. Your disk (or its power or connections or some such that is required) is not reliable overall: it is failing to operate correctly. (If I'm correct above.) If it is a connection problem, it could be on the rpi3/rpi2 side of things. If no powered hub is used, the same could be true for power. Expect that, no matter what you do (even -j1), you will likely see at least occasional failures in the environment that you have. Pushing the I/O system harder over the same time period would likely increase the observed failure rate over that duration. But I doubt there being a positive threshold below which there would be no failures for buildworld (on a time scale for the whole build that you would be willing to wait for). =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 16 09:31: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 284BF1083C03 for ; Thu, 16 Aug 2018 09:31:09 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 1C77E76BBC for ; Thu, 16 Aug 2018 09:31:07 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp118-210-251-92.bras1.adl4.internode.on.net (HELO midget.dons.net.au) ([118.210.251.92]) by ipmail06.adl6.internode.on.net with ESMTP; 16 Aug 2018 12:39:39 +0930 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.14.9) with ESMTPS id w7G39Qwh058503 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 16 Aug 2018 12:39:28 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.14.9/Submit) id w7G2ur46051181 for ; Thu, 16 Aug 2018 12:26:53 +0930 (ACST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [203.31.81.59] ([203.31.81.59]) by ppp118-210-251-92.bras1.adl4.internode.on.net (envelope-sender ) (MIMEDefang) with ESMTP id w7G2urXU051180; Thu, 16 Aug 2018 12:26:53 +0930 From: "O'Connor, Daniel" 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\)) Date: Thu, 16 Aug 2018 12:26:52 +0930 Subject: Beaglebone Black pinmuxing Message-Id: <13360A40-3381-4AF9-8EC5-C8E9B00CCABD@dons.net.au> To: freebsd-arm X-Mailer: Apple Mail (2.3445.9.1) X-Spam-Score: 1.5 (*) No, score=1.5 required=5.0 tests=HELO_MISC_IP, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.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, 16 Aug 2018 09:31:09 -0000 Hi, I have a BBB with a GPS engine attached to UART4 (P9_11 - UART4 Rx, = P9_13 - UART4 Tx) but I am having trouble communicating with it. I have tried both an overlay and editing the main DTS file directly but = while the UART is probed and attached I can't see any data coming in, = nor see any go out (by putting a 'scope probe on P9_13 while sending = data out cuau2). By my reading of the TRM and some googling P9_13 is gpmc_wait0 who's = pinmux offset is 0x870, P9_11 is gpmc_wpn, offset 0x874. The pinmuxes = get 0x800 subtracted from this (based on what is already in the DTS = file) This is the overlay source.. root@generic:/ # cat /boot/dtb/overlays/am335x-beaglebone-uart4a.dtso /dts-v1/; /plugin/; / { compatible =3D "ti,am335x-bone-black", "ti,am335x-bone", = "ti,am33xx"; fragment@1 { target =3D <&uart4>; __overlay__ { status =3D "okay"; pinctrl-names =3D "default"; pinctrl-0 =3D < 0x074 0x06 // = gpmc_wpn.uart4_txd_mux2 -> mode 6 0x070 0x2e // = gpmc_wait0.uart4_rxd_mux2 -> mode 6 >; }; }; }; Compiled with.. dtc -@ -I dts -O dtb -o am335x-beaglebone-uart4a.dtbo = am335x-beaglebone-uart4a.dtso And I put this in loader.conf fdt_overlays=3D"am335x-beaglebone-uart4a" After that didn't work I tried modifying the = /boot/msdos/dtb/am335x-boneblack.dts file directly with these diffs.. --- am335x-boneblack-orig.dts 2018-08-11 12:27:38.000000000 +0000 +++ am335x-boneblack.dts 2018-08-11 13:25:42.000000000 +0000 @@ -785,6 +785,13 @@ pinctrl-single,pins =3D = <0x170 0x30 0x174 0x0>; phandle =3D <0x4f>; }; + pinmux_uart4_pins { + pinctrl-single,pins =3D = < + 0x070 0x2e // P9_11 = gpmc_wait0.uart4_rxd_mux2 -> mode 6 + 0x074 0x06 // P9_13 = gpmc_wpn.uart4_txd_mux2 -> mode 6 + >; + phandle =3D <0x7a>; + }; pinmux_clkout2_pin { pinctrl-single,pins =3D = <0x1b4 0x3>; @@ -1153,7 +1160,7 @@ clock-frequency =3D <0x2dc6c00>; reg =3D <0x481a8000 0x2000>; interrupts =3D <0x2d>; - status =3D "disabled"; + status =3D "okay"; phandle =3D <0x7a>; }; serial@481aa000 { @@ -2189,6 +2196,7 @@ hdmi_0 =3D = "/ocp/i2c@44e0b000/tda19988/ports/port@0/endpoint@0"; gpio1 =3D "/ocp/gpio@4804c000"; uart0_pins =3D = "/ocp/l4_wkup@44c00000/scm@210000/pinmux@800/pinmux_uart0_pins"; + uart4_pins =3D = "/ocp/l4_wkup@44c00000/scm@210000/pinmux@800/pinmux_uart4_pins"; i2c2_pins =3D = "/ocp/l4_wkup@44c00000/scm@210000/pinmux@800/pinmux_i2c2_pins"; pm_sram_data =3D = "/ocp/ocmcram@40300000/pm-sram-data@1000"; sha0_fck =3D = "/ocp/l4_wkup@44c00000/scm@210000/scm_conf@0/clocks/sha0_fck"; And while in both cases the UART attaches.. uart2: mem 0x481a8000-0x481a9fff irq 15 on = simplebus0 .. I can't see any data from the GPS engine with.. ( stty clocal -crtscts 9600 ) < /dev/cuau2 Any help much appreciated, thanks! -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-arm@freebsd.org Thu Aug 16 12:24: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 A50821055AF2 for ; Thu, 16 Aug 2018 12:24:44 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 1410A7F4A4 for ; Thu, 16 Aug 2018 12:24:44 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: by mail-lf1-x131.google.com with SMTP id o72-v6so1092640lfk.1 for ; Thu, 16 Aug 2018 05:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nWDIuwODK484m2DC+HZC59qTYYON8868qcII4Hv50MI=; b=TpB4yw3XA6R1yAzgJCWVM3Vz4IT7KwzClho8gUepiXVKSO1jQiY7Scpc+y1mkD9AZu k3HZLTdmMKHeG2TWO+yQ8p6SuKc9+0QCJk9VY2r87vR/wd/+YofLo7x7pufGW1PX9r+2 qr80JU8ujKYJNOaJ+R1t/a6f/0ef7n4Bn8Ct9sfACcX27txfGd7Gu8bFh8XUnoQltLpF WQ6t3YO2v18YvDVCWbpAm1V98GR7Jj2ozUK9ZqpWwwM6mqXakymI/XP3Gc8CBLgpZOIc ackvMaoLsy4O/1dOW7vAHwD4XmfeyWQnljixYxqq2AkwFEX0LZ7MIxRK9VXEVNkHxei6 eCEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nWDIuwODK484m2DC+HZC59qTYYON8868qcII4Hv50MI=; b=p/FzZnbJjFzzMjnXaoEwb9omkCNhE+zgJs4ZlDlIg61dSVOMEATpxL2FuwCNMTH1Dn cjekMJAkMlMwd6T49fP6qCR1Q3Hf3LCeRoCez0eImb7BOlZ1/LPXdb4nVFzQiHtRcUhV +0aEQiE3vq5c+qYxWpQ835DrZecaK8Kxc3SjrhuaSrZKDsMhxPnKVPiANlaIDntZPi7+ p8/Gd25xwihw88QkBdNKZSI2ymaF7b+zE1mlHD4dOxR5gOe+LL7AZx1Aue9e8mLGpNJs mIZ1RxoSH0CLtReFVyNtdsikYz2/7MpOjz3OtH2JL13ay5PZIA+/j5yiXT4L1LbtSJB4 1NFQ== X-Gm-Message-State: AOUpUlF48O0E/xXxCHQhm0hVm1sJDd5EWGoGgT7TVMjFYe1I8QFsx7Jr HtXQ6eDTIVPdgFTy1hS89Bpf7orZ7NQ7ozmokF8P9uls X-Google-Smtp-Source: AA+uWPww0ZSTA0TIVDZr71rsbG4PFqni6YJdPhJghPPf/Mq9oddER+cUG5eZco/FJueXXTHbNc8XnEAsTk+qZWFLtGY= X-Received: by 2002:a19:124d:: with SMTP id h74-v6mr996934lfi.107.1534422282280; Thu, 16 Aug 2018 05:24:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8599:0:0:0:0:0 with HTTP; Thu, 16 Aug 2018 05:24:41 -0700 (PDT) From: Sleep Walker Date: Thu, 16 Aug 2018 15:24:41 +0300 Message-ID: Subject: To: 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, 16 Aug 2018 12:24:44 -0000 Hi! I'm trying to make a bootloader for NanoPi K1 Plus. I use as a sample a bootload from OrangePi PC2 Coming from https://wiki.freebsd.org/FreeBSD/arm/Allwinner/booting u-boot-sunxi-with-spl.bin should not exceed 557056 but it is more root@ast:/usr/local/share/u-boot # ls -lsa */*.bin 608 -rw-r--r-- 1 root wheel 568604 Aug 11 22:07 u-boot-nanopi-k1-plus/u-boot-sunxi-with-spl.bin 640 -rw-r--r-- 1 root wheel 619804 Aug 16 15:11 u-boot-orangepi-pc2/u-boot-sunxi-with-spl.bin This is normal? From owner-freebsd-arm@freebsd.org Thu Aug 16 12: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 A843710581CC for ; Thu, 16 Aug 2018 12:42:42 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.de (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 434E07FEB1 for ; Thu, 16 Aug 2018 12:42:41 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.de (Postfix) with ESMTPSA id DA5245E; Thu, 16 Aug 2018 14:42:33 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 64F551350F91D; Thu, 16 Aug 2018 09:42:29 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Beaglebone Black pinmuxing From: "Dr. Rolf Jansen" In-Reply-To: <13360A40-3381-4AF9-8EC5-C8E9B00CCABD@dons.net.au> Date: Thu, 16 Aug 2018 09:42:28 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <56756FA3-8FD7-44A4-A2D8-054E7C86744B@obsigna.com> References: <13360A40-3381-4AF9-8EC5-C8E9B00CCABD@dons.net.au> To: freebsd-arm 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, 16 Aug 2018 12:42:42 -0000 > Am 15.08.2018 um 23:56 schrieb O'Connor, Daniel : >=20 > Hi, > I have a BBB with a GPS engine attached to UART4 (P9_11 - UART4 Rx, = P9_13 - UART4 Tx) but I am having trouble communicating with it. >=20 > I have tried both an overlay and editing the main DTS file directly = but while the UART is probed and attached I can't see any data coming = in, nor see any go out (by putting a 'scope probe on P9_13 while sending = data out cuau2). >=20 > By my reading of the TRM and some googling P9_13 is gpmc_wait0 who's = pinmux offset is 0x870, P9_11 is gpmc_wpn, offset 0x874. The pinmuxes = get 0x800 subtracted from this (based on what is already in the DTS = file) >=20 > This is the overlay source.. > root@generic:/ # cat /boot/dtb/overlays/am335x-beaglebone-uart4a.dtso > /dts-v1/; > /plugin/; >=20 > / { > compatible =3D "ti,am335x-bone-black", "ti,am335x-bone", = "ti,am33xx"; >=20 > fragment@1 { > target =3D <&uart4>; > __overlay__ { > status =3D "okay"; > pinctrl-names =3D "default"; > pinctrl-0 =3D < > 0x074 0x06 // = gpmc_wpn.uart4_txd_mux2 -> mode 6 > 0x070 0x2e // = gpmc_wait0.uart4_rxd_mux2 -> mode 6 >> ; > }; > }; > }; >=20 > Compiled with.. > dtc -@ -I dts -O dtb -o am335x-beaglebone-uart4a.dtbo = am335x-beaglebone-uart4a.dtso > And I put this in loader.conf > fdt_overlays=3D"am335x-beaglebone-uart4a" Hello, Only recently I need to pass over all the very same obstacles as you = need to do now, in order to get a DAC-I2C module enabled and working on = my BBB. In my case, the curial point was to get the pinmuxing straight = and correctly linked to the respective I2C node. My BeableBone Black is = running on FreeBSD 12-ALPHA1. Note, there are major differences in the = DT between 11 and 12, and therefore depending on your FreeBSD version = the following hints may not fully apply. 1. The overlay needs 2 fragments, one for the pinmuxing node and another one for node which would use the pins 2. The overlay must contain a __local_fixups__ section, because this will let the dtbo loader to link the custom pinmux correctly to your customized node 3. I am almost sure, that MODE6 is incorrect in your case, however, I am ready to learn otherwise. I looked up the modes for my project in the Database of Pins of the bonescript project on GitHup (which is maintained by one of the BBB developers): https://github.com/jadonk/bonescript/ P9_13 starts on line 1271 of the bone.js file: https://github.com/jadonk/bonescript/blob/master/src/bone.js#L1271 P9_11 starts on line 1226 of the bone.js file: https://github.com/jadonk/bonescript/blob/master/src/bone.js#L1226 AFAIK, the field options contains the array of pinmux modes, starting at 0. MODE6 is NA in the case of P9_13 and urat4_rxd in the case of P9_11. You said, you need gpmc_wpn and gpmc_wait0 respectively, and this would be MODE0 for both pins. 4. In order to find out the input/output flags, I consulted the file: = https://svnweb.freebsd.org/base/head/sys/gnu/dts/include/dt-bindings/pinct= rl/am33xx.h?view=3Dco Now, I guess, that P9_13 would be simply PIN_OUTPUT, which means flag = 0x00, and P19_11 would be PIN_INPUT =3D =3D (INPUT_EN | PULL_DISABLE) =3D =3D ((1 << 5)| (1 << 3)) =3D 0x28 Said all this, I suggest to try the following overlay - note, I am = definitely not the authoritative expert: /dts-v1/; /plugin/; / { compatible =3D "ti,am335x-bone-black", "ti,am335x-bone", = "ti,am33xx"; exclusive-use =3D "P9.11","P9.13","uart4"; fragment@0 { target =3D <&am33xx_pinmux>; __overlay__ { gpmc_uart4_pins: pinmux_gpmc_uart4_pins { pinctrl-single,pins =3D < 0x74 0x00 /* UART4_TXD, = PIN_OUTPUT | MODE0 */ 0x70 0x28 /* UART4_RXD, = PIN_INPUT | MODE0 */ >; }; }; }; fragment@1 { target =3D <&uart4>; __overlay__ { status =3D "okay"; pinctrl-names =3D "default"; pinctrl-0 =3D <&gpmc_uart4_pins>; }; }; __local_fixups__ { fragment@1 { __overlay__ { pinctrl-0 =3D <0x0>; }; }; }; }; Best regards Rolf= From owner-freebsd-arm@freebsd.org Thu Aug 16 12:55: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 E00A810586E4 for ; Thu, 16 Aug 2018 12:55:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91D0E8059D for ; Thu, 16 Aug 2018 12:55:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (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)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 2E3C21D7FE for ; Thu, 16 Aug 2018 12:55:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f171.google.com with SMTP id r13-v6so3553008ljg.10 for ; Thu, 16 Aug 2018 05:55:23 -0700 (PDT) X-Gm-Message-State: AOUpUlE1ssPhRbWvSWeGbwJXp0yH8T87xxmozflxbO8LV8bTqqyBT+sB CRjrsgDO9su115eDw0j0VRInxC4Foya/KjCF3uU= X-Google-Smtp-Source: AA+uWPyLY8EwKiX3At80amLR+fvMG89fj1VwokAf7NWWcxkUX2vDzcXrVVHCm7yZEeWvO2oh2E+YEkSE8cinJBFs6Js= X-Received: by 2002:a2e:498:: with SMTP id a24-v6mr22044401ljf.27.1534424121672; Thu, 16 Aug 2018 05:55:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Thu, 16 Aug 2018 05:55:01 -0700 (PDT) In-Reply-To: <56756FA3-8FD7-44A4-A2D8-054E7C86744B@obsigna.com> References: <13360A40-3381-4AF9-8EC5-C8E9B00CCABD@dons.net.au> <56756FA3-8FD7-44A4-A2D8-054E7C86744B@obsigna.com> From: Kyle Evans Date: Thu, 16 Aug 2018 07:55:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Beaglebone Black pinmuxing To: "Dr. Rolf Jansen" , "Daniel O'Connor" Cc: freebsd-arm 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: Thu, 16 Aug 2018 12:55:24 -0000 On Thu, Aug 16, 2018 at 7:42 AM, Dr. Rolf Jansen wrote: >> Am 15.08.2018 um 23:56 schrieb O'Connor, Daniel : >> >> Hi, >> I have a BBB with a GPS engine attached to UART4 (P9_11 - UART4 Rx, P9_13 - UART4 Tx) but I am having trouble communicating with it. >> >> I have tried both an overlay and editing the main DTS file directly but while the UART is probed and attached I can't see any data coming in, nor see any go out (by putting a 'scope probe on P9_13 while sending data out cuau2). >> >> By my reading of the TRM and some googling P9_13 is gpmc_wait0 who's pinmux offset is 0x870, P9_11 is gpmc_wpn, offset 0x874. The pinmuxes get 0x800 subtracted from this (based on what is already in the DTS file) >> >> This is the overlay source.. >> root@generic:/ # cat /boot/dtb/overlays/am335x-beaglebone-uart4a.dtso >> /dts-v1/; >> /plugin/; >> >> / { >> compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; >> >> fragment@1 { >> target = <&uart4>; >> __overlay__ { >> status = "okay"; >> pinctrl-names = "default"; >> pinctrl-0 = < >> 0x074 0x06 // gpmc_wpn.uart4_txd_mux2 -> mode 6 >> 0x070 0x2e // gpmc_wait0.uart4_rxd_mux2 -> mode 6 >>> ; >> }; >> }; >> }; >> [Puts on overlay police hat =)] The above corresponds to: /dts-v1/; /plugin/; / { compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; }; &uart4 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = < 0x074 0x06 // gpmc_wpn.uart4_txd_mux2 -> mode 6 0x070 0x2e // gpmc_wait0.uart4_rxd_mux2 -> mode 6 >; }; > Said all this, I suggest to try the following overlay - note, I am definitely not the authoritative expert: > > /dts-v1/; > /plugin/; > > / { > compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; > > exclusive-use = "P9.11","P9.13","uart4"; > > fragment@0 { > target = <&am33xx_pinmux>; > __overlay__ { > gpmc_uart4_pins: pinmux_gpmc_uart4_pins { > pinctrl-single,pins = < > 0x74 0x00 /* UART4_TXD, PIN_OUTPUT | MODE0 */ > 0x70 0x28 /* UART4_RXD, PIN_INPUT | MODE0 */ > >; > }; > }; > }; > > fragment@1 { > target = <&uart4>; > __overlay__ { > status = "okay"; > pinctrl-names = "default"; > pinctrl-0 = <&gpmc_uart4_pins>; > }; > }; > > __local_fixups__ { > fragment@1 { > __overlay__ { > pinctrl-0 = <0x0>; > }; > }; > }; > }; > This one would be: /dts-v1/; /plugin/; / { compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; exclusive-use = "P9.11","P9.13","uart4"; }; &am33xx_pinmux { gpmc_uart4_pins: pinmux_gpmc_uart4_pins { pinctrl-single,pins = < 0x74 0x00 /* UART4_TXD, PIN_OUTPUT | MODE0 */ 0x70 0x28 /* UART4_RXD, PIN_INPUT | MODE0 */ >; }; }; &uart4 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&gpmc_uart4_pins>; }; Both of the above to be compiled with dtc -@ if you're using /usr/bin/dtc on x86 until [1] gets pulled upstream (though I may commit it to FreeBSD earlier if it doesn't get pulled before the freeze). -@ may not be a bad idea if you're planning on slapping other overlays on top so that they may also do symbol resolution on the overlay. We support this syntax for overlays now, and I highly recommend using it -- it's a pretty great quality of life improvement over hand-crafting fragments. =) [Takes off overlay police hat] Thanks, Kyle Evans [1] https://github.com/davidchisnall/dtc/pull/46 From owner-freebsd-arm@freebsd.org Thu Aug 16 13:46: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 C9558106686B for ; Thu, 16 Aug 2018 13:46:40 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 35BFE83396 for ; Thu, 16 Aug 2018 13:46:40 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: by mail-lj1-x22c.google.com with SMTP id u7-v6so3711988lji.3 for ; Thu, 16 Aug 2018 06:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=d9qhVD8P9OxoUEQmItRnVEQVS7XQTQn6EjxhN4nEaVk=; b=Ws+KfoGlf6XI7PyMJox5gvxZhJf6kYUxYNxiR8LUkikonh9/Yj4irpOFJe0ENNPM2c VRud8bYjn/6jvkQBhwc5qwdwxyCye1eKGZxW6xOt6Q9qNVwH+/cHd4BU8lFwZRISMHcF WPpryGsPzF8xyQeW0W/D88gS7uLodL9rsLCU8hBBoEuUfxF/DQzJZzK7mImNDUbq8plg PKmEm74DHmww8ioJtZBi24LaFDQwL1MN7bC495WA8J3MmgW86EFSY1hGZpto5GbKfmh/ 4yD35wAeIAS4zS1/pVruYmAeW/rkB1TIHKsai2mN7FOrukMbJletFJj6jc7+F/Ln/cES MlsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d9qhVD8P9OxoUEQmItRnVEQVS7XQTQn6EjxhN4nEaVk=; b=pCs5gpSOJKpYiUwxACPN5qf9SsDpGr3YEQyWbi9I8Xt4xF8E0/6HapmBgPoagOgnq3 yaPACQu7ctLlMOAr/kqvAOp9s6xHvehWFUwXDD6JQDtYlRPR/t2bwyQnEm3A0QOr5+vN RJRG0jT/3xEb9l4lXmUE0h0FTVZpqRHANZMru+grtH8gwNEWdBb1v7IaHnmPpwuJ1Rb/ ZbgUWcTa6AYMECVcmfYNd6mvHOawrDp3IJHrKepNUIrI8TSlWYr6rQ2OyB05wyl7C1ag /dcvzADVsSXADqm+snstZ3hEJNUFgggE2XT2vDYbQXE9Z/ASlL2D+lJSf2LJ/YzjWluI YB/Q== X-Gm-Message-State: AOUpUlGi3oiu2xbcGjEHSFsgFX4J2H/la0gXCAJc0ZHe5NRn19rZ52q9 YTki2K/tyNkAs117ZeVLPeHbdL2jCqpyo8SweyIgWAaM X-Google-Smtp-Source: AA+uWPwYZymQr4cRJ1eNkvIaGp5oh7ZRDGv7O0xBh8mAc1gQZw0jaQOc+JO2janWPdpmpRMt8P3/Kvl6kx2SsTRZf+o= X-Received: by 2002:a2e:52c3:: with SMTP id n64-v6mr22457362lje.90.1534427198326; Thu, 16 Aug 2018 06:46:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8599:0:0:0:0:0 with HTTP; Thu, 16 Aug 2018 06:46:37 -0700 (PDT) From: Sleep Walker Date: Thu, 16 Aug 2018 16:46:37 +0300 Message-ID: Subject: FreeBSD 12.0-CURRENT for OrangePi PC2 To: 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, 16 Aug 2018 13:46:41 -0000 ------------------------------ Hi! I'm trying to make a bootloader for NanoPi K1 Plus. I use as a sample a bootload from OrangePi PC2 Coming from https://wiki.freebsd.org/FreeBSD/arm/Allwinner/booting u-boot-sunxi-with-spl.bin should not exceed 557056 but it is more root at ast :/usr/local/share/u-boot # ls -lsa */*.bin 608 -rw-r--r-- 1 root wheel 568604 Aug 11 22:07 u-boot-nanopi-k1-plus/u-boot-sunxi-with-spl.bin 640 -rw-r--r-- 1 root wheel 619804 Aug 16 15:11 u-boot-orangepi-pc2/u-boot-sunxi-with-spl.bin This is normal? From owner-freebsd-arm@freebsd.org Thu Aug 16 17:14: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 4BA4B106F4DE for ; Thu, 16 Aug 2018 17:14:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (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 BA87E8E5B2 for ; Thu, 16 Aug 2018 17:14:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: xEeZBaUVM1kWTGVqtLj._eOA3HFM50Hh6G298mMpQgVLQrSkMG4Lev09Y9PH0mX LfXOCVFV6WEMB2_Dw0bxuHdB7RiQ4V0u.hu8FESj0oBwTwL8vEmfsruV1ybJ1q8Ai.UX7tPEjBd0 AKJRX8j749usBEHPIjL_RyOQngRwbWfYrBMvltU_IyxU2IgJCsRdUI02Sk4vdWFB9Yq_drmkgf6k QX3AblcdWsd0HFZtJ0UWRbvyjA7qB3eV1KgCZigeo__9q7sue2CfkCuKvLrqE7HQWSEr8AVY4wkF vS1zDYgw7ptKX7GMRNZTZ.wY.sJzvxWhJ7_IwiIooCMD4_ib.fdUTDwxt79d5F9yYqcGd5bBIvxf fyvFBBqIyHrkfvVly6PyIvFthuL.33PWe_LCJ5cwZCMhhvZU1aIz58uxK_ntgutTHO.woQL3SpPM sBXjgEbfwakAF8cId9dfSdw9G0mv1pRqw8NB94mq5PCjX8xgZTWkeXc13PR3nPdzBNJp40WRsY6m Y9HIYPaWdMFKRwhVCr98act5CR2_2B4u2EwMSMSRjytSabWRhD1xLquUqJGqYTcvTBHLZNF7Qw8b AniJr9W2oNY1oTmG77IHYnVLuMXlY4M_zm3kFDOKgVAfOt9ul2EOItx1BDJvMbe2QQKV4qQ9p_Er tn7.1CsiQ7Wb2gnOpIPqZK8eEAeIktXVUnDv01Lg0bZ26Gi6.mPeYbQfawjJEgbyWewuTGe6G5XS h6bAxR.2lq5rVAWUUSV.ujwJKPcZTrGwwh7depkWYav_txl0HWnY1bWPQtvZhQ1VF7w7UEY0I4J8 zEm5sM6KtEss0cyWo7WUzKNAfmBwQBgl8.AIhAD1caERP2r2_sLAlk0_JIi.GVpnLxgUkXybwD_B Y5dgzew6g.LrBC1xDe2.LPyVxG2lelqY9AdTkH0ZqO0U.nnMG89XqF_Bu2v3DlqJHv_mJ8ym21EE SLX92GkS3jJH8GcvS1HFeLaaJWmxllkOp7XzXJOL79OFg8H80yk.IqCLvMnBEfeOQwxoK9VSu.68 FwUniRg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Aug 2018 17:14:47 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp415.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID cea5871d9cf05597e6064f9609788204; Thu, 16 Aug 2018 17:04:37 +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: I've had a poudriere-devel bulk run on a Pine64+ 2GB get a: "Warning: Failed to acquire update_stats lock" Message-Id: <37754344-7C23-491C-B901-0C48AA8B7F75@yahoo.com> Date: Thu, 16 Aug 2018 10:04:35 -0700 To: Bryan Drewery , freebsd-arm , FreeBSD Ports 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, 16 Aug 2018 17:14:49 -0000 I've no clue if this is significant or not, so I figured I'd report it in case it is. I've never seen one of these before. See the "[10:59:31]" line below if you care about the warning. . . . [04:59:38] [01] [00:00:00] Building devel/llvm60 | llvm60-6.0.1_2 load: 4.53 cmd: sh 57158 [nanslp] 19949.18r 28.74u 71.38s 0% 1040k [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] = Queued: 117 Built: 67 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 50 = Time: 05:32:29 [01]: devel/llvm60 | llvm60-6.0.1_2 = build (00:23:53 / 00:34:35) [05:34:13] Logs: = /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_1= 7h46m18s load: 5.72 cmd: sh 46862 [runnable] 0.07r 0.00u 0.00s 0% 0k [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] = Queued: 117 Built: 67 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 50 = Time: 10:57:17 [01]: devel/llvm60 | llvm60-6.0.1_2 = build (05:48:41 / 05:59:23) [10:59:01] Logs: = /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_1= 7h46m18s [10:59:31] Warning: Failed to acquire update_stats lock load: 4.06 cmd: sh 65361 [piperd] 56707.61r 0.39u 0.65s 0% 408k [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] = Queued: 117 Built: 67 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 50 = Time: 15:48:05 [01]: devel/llvm60 | llvm60-6.0.1_2 = build (10:39:29 / 10:50:11) [15:49:49] Logs: = /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_1= 7h46m18s If it is significant, I do not know if it points at a poudriere-devel problem or an aarch64 problem or what. Note: This poudreire-devel bulk run is still running and may well be for, say, another 8 hours or some such if it completes normally. Some context details: # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r337400M arm64 = aarch64 1200076 1200076 # 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: 476715 Last Changed Rev: 476715 I did the ports-mgmt/poudriere-devel rebuild and pkg update and upgrade sequence based on -r476715 before again using poudreire-devel for the more general bulk build to update based on -r476715 . So the poudriere-devel is based on -r476715 instead of what I'm updating from. =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 16 17: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 622D6106F806; Thu, 16 Aug 2018 17:21:45 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03F7A8E905; Thu, 16 Aug 2018 17:21:45 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id C12265914; Thu, 16 Aug 2018 17:21:44 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 8277A87E; Thu, 16 Aug 2018 17:21:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 6erbjzKjUzbi; Thu, 16 Aug 2018 17:21:40 +0000 (UTC) Subject: Re: I've had a poudriere-devel bulk run on a Pine64+ 2GB get a: "Warning: Failed to acquire update_stats lock" DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 92A8A879 To: Mark Millard , freebsd-arm , FreeBSD Ports References: <37754344-7C23-491C-B901-0C48AA8B7F75@yahoo.com> From: Bryan Drewery Openpgp: preference=signencrypt Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAHNJEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPsLAgAQTAQoAKgIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZAQUCWujOIgUJCmB7NwAKCRA113G7bkaXz/xpB/9b /UWIPbieY1IeIuHF2pyYPE7Hytkh3HVsxMA0F5Ma2AYQsXZZeKNKWrF7RPyDyDwUklLHJkhm k3EfClBbHxf08kMIm1vWCJRtgxic9knY/bzYGiWMpHjg3cSd1XfrYH1autYqTZAjDwIkgOjU dR//Tbn4V36sY7y2jz+kdMVWvK53U32aZqiwBbCn4DPe1wSZcUs17mV/0uZdIoGdj74B1orN A/0py5vHYo6HcbBNoaR8pKRLf5VZNRsxqGIMhTucx4SJWcHpuRBWYyvJSFzwvxdK4ZD4Yqoc kFGPVtOXktVMai9exrLvP3G77fKMu8DI6j4QRU4wCesnHuIfRPFuzsBNBFJphmsBCACiVFPf kNfaFtUSuY0395ueo/rMyHPGPQ2iwvERFCpeFGSQSgagpenNHLpFQKTg/dl6FOoST5tqyxMq fyHGHDzzU51bvA/IfaGoNi/BIhTe/toZNMRvpcI3PLjiGcnJnuwCCbAVOAGdb+t5cZtpNdOI cKYmrYG3u9RiBpe6dTF+qLrD/8Bs1wjhduQ8fcNNgnkXu8xDH4ZxY0lIc3QgvYWp9vimlQe6 iKjUd2/DX28ETZcD5h6pYV331KMPTrEI0p0yvFijUZce8c1XHFyL1j9sBAha5qpszJl6Uq5i LolhKRcGfcdmtD72vHQjUYglUyudSJUVyo2gMYjdbiFKzJulABEBAAHCwGUEGAEKAA8FAlJp hmsCGwwFCQlmAYAACgkQNddxu25Gl89UPggA2mGQp28yCUKsJ6KHFVy/lpHfoQrKF+s7HfKT U2ObVeVNX4I8ZdW1UO48mRqxEOwY8r5YSH6X06OmiqCX2aSMXg3N06/l+ztlB0+UGGlkXBjv l9/nii+bC6b8XWuu0X7Qpb9oYBK9YtoaoyuVplAmjdj/cPou65meKIaS1yDTjHh450DrW8Qg he6l0bFX4BHKTSm99U90ML7EY19B6iI2BZSqWutVsyD71oAREY6NGgDpCOIO6FS41+WeYCDR j8vsa/BiaoX2d2SBDsCwsEwe9fg5PYMi2uVIhvL6OrxnwOdB+TkgvOy5zZSNO29UG/JilZKo Ndz2wpEaUzChGGqLvcLAZQQYAQoADwIbDAUCWujOKAUJCmB7PQAKCRA113G7bkaXz6bkB/9H dUR3E0wBwMh6z0AOFDKh+PbRI9Xd4IncdhE55tNK410650a3gADIDwqz3i72GIinkgaxzpEO xP1bs7a+BeF3p5Xd6Jjk6J/nEshisgNW7VjUbJHFGs8Sf9A6oM3q4VkI/ArVo5qkZxgKs72U HSAy5NV+AdqdTrWuAL20xfQ6gA7JF35Xf8zyUM2GMl0X8ik7dJ1jMp+TB27LipqbDgamFzH9 F9hC9gur94OQ/x3nQ+mFZ1uipYHA1EdrKuhb/Ts4bN/Ezl8nmYGxc9Bw7ZBxGOTId/rEIzoe LWpAvg6dcw0T9lNfSWc6PX+kf3dOXNIdkw9NqKID8wEPe8axcGYG Organization: FreeBSD Message-ID: Date: Thu, 16 Aug 2018 10:21:36 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <37754344-7C23-491C-B901-0C48AA8B7F75@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7ZKCyHs5M99GlVpQNUDsH28MTUfXQ1tMc" 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, 16 Aug 2018 17:21:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7ZKCyHs5M99GlVpQNUDsH28MTUfXQ1tMc Content-Type: multipart/mixed; boundary="en0RqUqQwHUsrZHkoXQV5OcFSh41PswXq"; protected-headers="v1" From: Bryan Drewery To: Mark Millard , freebsd-arm , FreeBSD Ports Message-ID: Subject: Re: I've had a poudriere-devel bulk run on a Pine64+ 2GB get a: "Warning: Failed to acquire update_stats lock" References: <37754344-7C23-491C-B901-0C48AA8B7F75@yahoo.com> In-Reply-To: <37754344-7C23-491C-B901-0C48AA8B7F75@yahoo.com> --en0RqUqQwHUsrZHkoXQV5OcFSh41PswXq Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 8/16/18 10:04 AM, Mark Millard wrote: > I've no clue if this is significant or not, so I figured I'd > report it in case it is. I've never seen one of these before. > See the "[10:59:31]" line below if you care about the warning. >=20 > . . . > [04:59:38] [01] [00:00:00] Building devel/llvm60 | llvm60-6.0.1_2 > load: 4.53 cmd: sh 57158 [nanslp] 19949.18r 28.74u 71.38s 0% 1040k > [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] Qu= eued: 117 Built: 67 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 50 = Time: 05:32:29 > [01]: devel/llvm60 | llvm60-6.0.1_2 build = (00:23:53 / 00:34:35) > [05:34:13] Logs: /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-= default/2018-08-15_17h46m18s > load: 5.72 cmd: sh 46862 [runnable] 0.07r 0.00u 0.00s 0% 0k > [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] Qu= eued: 117 Built: 67 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 50 = Time: 10:57:17 > [01]: devel/llvm60 | llvm60-6.0.1_2 build = (05:48:41 / 05:59:23) > [10:59:01] Logs: /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-= default/2018-08-15_17h46m18s > [10:59:31] Warning: Failed to acquire update_stats lock Not sure why it's happening exactly. It tries to create a directory in the internal tmpdir if it doesn't exist already wrapped basically by lockf(1) with a 30 second timeout. Anyway it's completely harmless. It just means the stats displayed there may not be accurate for another few seconds. What's likely happening is that the separate html json writer process is still working with the lock held and your SIGINFO timed out waiting for the lock - or the other way around. Harmless. > load: 4.06 cmd: sh 65361 [piperd] 56707.61r 0.39u 0.65s 0% 408k > [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] Qu= eued: 117 Built: 67 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 50 = Time: 15:48:05 > [01]: devel/llvm60 | llvm60-6.0.1_2 build = (10:39:29 / 10:50:11) > [15:49:49] Logs: /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-= default/2018-08-15_17h46m18s >=20 > If it is significant, I do not know if it points at a > poudriere-devel problem or an aarch64 problem or what. >=20 > Note: This poudreire-devel bulk run is still running > and may well be for, say, another 8 hours or some such > if it completes normally. >=20 > Some context details: >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r337400M arm64 aarch= 64 1200076 1200076 >=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: 476715 > Last Changed Rev: 476715 >=20 > I did the ports-mgmt/poudriere-devel rebuild and > pkg update and upgrade sequence based on -r476715 > before again using poudreire-devel for the more > general bulk build to update based on -r476715 . > So the poudriere-devel is based on -r476715 instead > of what I'm updating from. >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 --=20 Regards, Bryan Drewery --en0RqUqQwHUsrZHkoXQV5OcFSh41PswXq-- --7ZKCyHs5M99GlVpQNUDsH28MTUfXQ1tMc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+Rc8ssOq6npcih8JNddxu25Gl88FAlt1sqEACgkQNddxu25G l89B/AgAk1BB1h7be1kk1Gv98Oj+S/FSRoQTiEPEgKj0BEkcPgYmu9jsexqJGlp/ wX52vo7j5GP4aTEJOSrgIR3Be3TbG6bR5zD57pzrFcMKOI4NNSWGfKLQJDtMy0R3 B+bjGq6NIlsSseyWnWURQgWPtrqZJ8CTdL4NyXVH7WlXAYoXplI+xTClgeHg/pE/ w1HkjZKZNM7GGip5pCK4ygQr1HbnTs9DhzxYDyHEXNwUmNh9Ch2j6MxFQuCbiEAg L5ut+2foNDPnxp5BdJqenrmiOsQyCxsVpj0t/LgobMBioIiikUlGM8eQLCehVX53 SBG+nYBvVnTT28z0JxCol0XYqhbAxg== =YaS+ -----END PGP SIGNATURE----- --7ZKCyHs5M99GlVpQNUDsH28MTUfXQ1tMc-- From owner-freebsd-arm@freebsd.org Thu Aug 16 17:28: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 5A859106FAB2 for ; Thu, 16 Aug 2018 17:28:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-3.consmr.mail.bf2.yahoo.com (sonic303-3.consmr.mail.bf2.yahoo.com [74.6.131.42]) (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 EEE8C8ECCC for ; Thu, 16 Aug 2018 17:28:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: zXXSvUYVM1kWxjmxblAMsFlnK2J_QiWe1vJj4MGQDut4XUCLTrJW5_O9XSQpjqj ZzpTUKgnGkLSDhHiAmKF_T8l8_JRTzmcK9fQkTKqTH3VHuI5TkNDu6edDHA0RvQql5bTSxVMFsDh EVBcPox8BrN5tHNoeNEDS09b66YKprklY30uXNwDzpLEr6qN9VfwuHKrC7q.5y1b778L2RGpT1s. agmF5iH4hSB5PPSfeGN.reZyAJrNP_5jlUTe5LSQ0h..tTZF6mvdS0aPlq0ztHOPxWfNCFRcLh3_ ijOc7eiW8gu_8yZUU1_ai9fhRkcxdXHWxBBPTbu3LYx1Ju3Wz_uCMqVj4JqTxyUOSE5i4lARQTgO 4d6Yr599xqI0QlNIPU8.dAToafPGKD6eqh3l4qyiXgNTkWMBQo_cy.OvodysW6_0rXHaicD29RBA yukmWso0uiCIzD7IdFCqlXaOxAdWi4s_XCHXWYLlKxRH9t65DY3p9C0EvWMlRm51MA8nqRc7trgv 8itBPB.MZRKoSLcS5.VUaDnhwTJI83ePurZJxZXtQFQJ4UWlk_KCGejnV29v_bP5K4ZodRKGzeSB mmNiUWXgBzcf_e71gUbJKYy1tqq7SNgsQLP4ncAZ2DBzLbHrfpwAb9fiovc5z_1j3agGPuySuTjE ighrI2b5vflefp8Ck8uEz5t2cCHH7HDaKEH4o2kMKPgr8cTwn10Fy1qduVrekfkqg86o0aeRi6RZ XD7J8BEwZcQlo1lHd1h1gyvzv61r39My6j6J1RArKvl5Schi4Il1uWDYkqUXZbMkkG1Bm8_Fu.qi GAH6gcW._VsP4pMbaKLZ3.tZDIw7LvpofHIYB1r77C.7W19fiHvKYN8sopaYBS4py.vGOyNbZMI0 le5BROKP.zZPQQm5E8Px9z9vkAb3gr_oDc_mXEoylr3_lq79WUF6R6uQKEWJjU0XhChD0ZRbkI_2 amSg_jPZYu7Hsnsml9KAMWw_ZwpaWikv0gLxykwxy0L3p281KVq6TFhRmD2fhNLFhWoHajrFLRta .BWS2wDM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Thu, 16 Aug 2018 17:28:15 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp403.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 079330711ca97b1840e5928973996ab4; Thu, 16 Aug 2018 17:28:10 +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: I've had a poudriere-devel bulk run on a Pine64+ 2GB get a: "Warning: Failed to acquire update_stats lock" Date: Thu, 16 Aug 2018 10:28:08 -0700 References: <37754344-7C23-491C-B901-0C48AA8B7F75@yahoo.com> To: Bryan Drewery , freebsd-arm , FreeBSD Ports In-Reply-To: <37754344-7C23-491C-B901-0C48AA8B7F75@yahoo.com> Message-Id: <257A646B-8CDA-4E82-AA2E-12380D55E34E@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: Thu, 16 Aug 2018 17:28:17 -0000 [Some more notes after looking around.] On 2018-Aug-16, at 10:04 AM, Mark Millard wrote: > I've no clue if this is significant or not, so I figured I'd > report it in case it is. I've never seen one of these before. > See the "[10:59:31]" line below if you care about the warning. >=20 > . . . > [04:59:38] [01] [00:00:00] Building devel/llvm60 | llvm60-6.0.1_2 > load: 4.53 cmd: sh 57158 [nanslp] 19949.18r 28.74u 71.38s 0% 1040k > [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] = Queued: 117 Built: 67 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 50 = Time: 05:32:29 > [01]: devel/llvm60 | llvm60-6.0.1_2 = build (00:23:53 / 00:34:35) > [05:34:13] Logs: = /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_1= 7h46m18s > load: 5.72 cmd: sh 46862 [runnable] 0.07r 0.00u 0.00s 0% 0k > [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] = Queued: 117 Built: 67 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 50 = Time: 10:57:17 > [01]: devel/llvm60 | llvm60-6.0.1_2 = build (05:48:41 / 05:59:23) > [10:59:01] Logs: = /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_1= 7h46m18s > [10:59:31] Warning: Failed to acquire update_stats lock > load: 4.06 cmd: sh 65361 [piperd] 56707.61r 0.39u 0.65s 0% 408k > [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] = Queued: 117 Built: 67 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 50 = Time: 15:48:05 > [01]: devel/llvm60 | llvm60-6.0.1_2 = build (10:39:29 / 10:50:11) > [15:49:49] Logs: = /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_1= 7h46m18s >=20 > If it is significant, I do not know if it points at a > poudriere-devel problem or an aarch64 problem or what. >=20 > Note: This poudreire-devel bulk run is still running > and may well be for, say, another 8 hours or some such > if it completes normally. >=20 > Some context details: >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r337400M arm64 = aarch64 1200076 1200076 >=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: 476715 > Last Changed Rev: 476715 >=20 > I did the ports-mgmt/poudriere-devel rebuild and > pkg update and upgrade sequence based on -r476715 > before again using poudreire-devel for the more > general bulk build to update based on -r476715 . > So the poudriere-devel is based on -r476715 instead > of what I'm updating from. Some 2016-April material around indicated that csh vfork SAVESIGVEC code was leaking signal masks after spawn. FYI: my root account is set up with a default of /bin/sh . I do not normally use csh or tcsh: # more /etc/master.passwd | grep root root:. . .:/root:/bin/sh (some material replaced with ". . ."). There are poudriere-devel related reports from back then, such as: https://lists.freebsd.org/pipermail/freebsd-pkg/2016-April/001575.html and its continuation at: https://lists.freebsd.org/pipermail/freebsd-pkg/2016-April/001578.html which, in turn, points to the bugzilla report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208132 with the csh detail. Note: The bugzilla was started from other evidence of a problem in 2016-March for a context not involving poudreire-devel. As stands, I've no other evidence of problems. =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 17 02:11: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 4C72B107E2D1 for ; Fri, 17 Aug 2018 02:11:02 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 3A64984E91 for ; Fri, 17 Aug 2018 02:11:00 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp121-45-39-162.bras2.adl4.internode.on.net (HELO midget.dons.net.au) ([121.45.39.162]) by ipmail06.adl6.internode.on.net with ESMTP; 17 Aug 2018 11:39:40 +0930 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.14.9) with ESMTPS id w7H29RKj001479 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 17 Aug 2018 11:39:35 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.14.9/Submit) id w7H1ku0i087592 for ; Fri, 17 Aug 2018 11:16:56 +0930 (ACST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.0.2.26] ([10.0.2.26]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id w7H1kuaN087590; Fri, 17 Aug 2018 11:16:56 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Beaglebone Black pinmuxing From: "O'Connor, Daniel" In-Reply-To: <56756FA3-8FD7-44A4-A2D8-054E7C86744B@obsigna.com> Date: Fri, 17 Aug 2018 11:16:54 +0930 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <3B199FD0-479D-49C5-8E6F-DDE3D447EB03@dons.net.au> References: <13360A40-3381-4AF9-8EC5-C8E9B00CCABD@dons.net.au> <56756FA3-8FD7-44A4-A2D8-054E7C86744B@obsigna.com> To: "Dr. Rolf Jansen" X-Mailer: Apple Mail (2.3445.9.1) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.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, 17 Aug 2018 02:11:02 -0000 > On 16 Aug 2018, at 22:12, Dr. Rolf Jansen wrote: >> Am 15.08.2018 um 23:56 schrieb O'Connor, Daniel : >=20 > Only recently I need to pass over all the very same obstacles as you = need to do now, in order to get a DAC-I2C module enabled and working on = my BBB. In my case, the curial point was to get the pinmuxing straight = and correctly linked to the respective I2C node. My BeableBone Black is = running on FreeBSD 12-ALPHA1. Note, there are major differences in the = DT between 11 and 12, and therefore depending on your FreeBSD version = the following hints may not fully apply. >=20 > 1. The overlay needs 2 fragments, one for the pinmuxing node and > another one for node which would use the pins > 2. The overlay must contain a __local_fixups__ section, because this > will let the dtbo loader to link the custom pinmux correctly to your > customized node OK, I'll go back to trying an overlay once I get it working by editing = am335x-boneblack.dts > 3. I am almost sure, that MODE6 is incorrect in your case, however, I > am ready to learn otherwise. I looked up the modes for my project > in the Database of Pins of the bonescript project on GitHup (which > is maintained by one of the BBB developers): > https://github.com/jadonk/bonescript/ >=20 > P9_13 starts on line 1271 of the bone.js file: > https://github.com/jadonk/bonescript/blob/master/src/bone.js#L1271 >=20 > P9_11 starts on line 1226 of the bone.js file: > https://github.com/jadonk/bonescript/blob/master/src/bone.js#L1226 >=20 > AFAIK, the field options contains the array of pinmux modes, = starting > at 0. MODE6 is NA in the case of P9_13 and urat4_rxd in the case of > P9_11. You said, you need gpmc_wpn and gpmc_wait0 respectively, and > this would be MODE0 for both pins. I had a look at http://www.ti.com/lit/ds/symlink/am3358.pdf (section = 4.2) and it shows GPMC_WAIT0 is uart4_rxd in mode 6, and GPMC_WPn is = uart4_txd in mode 6. I think bone.js is incorrect for UART4_TXD - it certainly differs from = UART4_RXD. Other UART pins look correct. > 4. In order to find out the input/output flags, I consulted the file: > = https://svnweb.freebsd.org/base/head/sys/gnu/dts/include/dt-bindings/pinct= rl/am33xx.h?view=3Dco >=20 > Now, I guess, that P9_13 would be simply PIN_OUTPUT, which means = flag 0x00, > and P19_11 would be PIN_INPUT =3D > =3D (INPUT_EN | PULL_DISABLE) =3D > =3D ((1 << 5)| (1 << 3)) > =3D 0x28 I think the UART receiver should have a pull up otherwise it would be = susceptible to noise if uncommitted, so I used 0x36 (because mode 6) > Said all this, I suggest to try the following overlay - note, I am = definitely not the authoritative expert: >=20 > /dts-v1/; > /plugin/; >=20 > / { > compatible =3D "ti,am335x-bone-black", "ti,am335x-bone", = "ti,am33xx"; >=20 > exclusive-use =3D "P9.11","P9.13","uart4"; Does FreeBSD used these names? I noticed Linux has them as #defines for pinmuxing which makes things = simpler. Thanks. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-arm@freebsd.org Fri Aug 17 04:16: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 37FA1108194E for ; Fri, 17 Aug 2018 04:16:37 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [150.101.137.141]) by mx1.freebsd.org (Postfix) with ESMTP id 5DCEB8B594 for ; Fri, 17 Aug 2018 04:16:36 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp121-45-39-162.bras2.adl4.internode.on.net (HELO midget.dons.net.au) ([121.45.39.162]) by ipmail03.adl2.internode.on.net with ESMTP; 17 Aug 2018 13:39:46 +0930 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.14.9) with ESMTPS id w7H49RoP084723 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 17 Aug 2018 13:39:40 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.14.9/Submit) id w7H46Wkf084632 for ; Fri, 17 Aug 2018 13:36:32 +0930 (ACST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.0.2.26] ([10.0.2.26]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id w7H46VEB084630; Fri, 17 Aug 2018 13:36:32 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Beaglebone Black pinmuxing From: "O'Connor, Daniel" In-Reply-To: <3B199FD0-479D-49C5-8E6F-DDE3D447EB03@dons.net.au> Date: Fri, 17 Aug 2018 13:36:30 +0930 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <72D8FE35-EE57-4E40-A604-4DF9DC8FEE05@dons.net.au> References: <13360A40-3381-4AF9-8EC5-C8E9B00CCABD@dons.net.au> <56756FA3-8FD7-44A4-A2D8-054E7C86744B@obsigna.com> <3B199FD0-479D-49C5-8E6F-DDE3D447EB03@dons.net.au> To: "Dr. Rolf Jansen" X-Mailer: Apple Mail (2.3445.9.1) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.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, 17 Aug 2018 04:16:37 -0000 > On 17 Aug 2018, at 11:16, O'Connor, Daniel wrote: > OK, I'll go back to trying an overlay once I get it working by editing = am335x-boneblack.dts So, I got it working (without an overlay as yet) with this diff.. --- am335x-boneblack-orig.dts 2018-08-11 12:27:38.000000000 +0000 +++ am335x-boneblack.dts 2018-08-12 10:10:24.000000000 +0000 @@ -785,6 +785,13 @@ pinctrl-single,pins =3D = <0x170 0x30 0x174 0x0>; phandle =3D <0x4f>; }; + pinmux_uart4_pins { + pinctrl-single,pins =3D = < + 0x070 0x2e // P9_11 = gpmc_wait0.uart4_rxd_mux2 -> mode 6 + 0x074 0x06 // P9_13 = gpmc_wpn.uart4_txd_mux2 -> mode 6 + >; + phandle =3D <0xce>; + }; pinmux_clkout2_pin { pinctrl-single,pins =3D = <0x1b4 0x3>; @@ -1153,8 +1160,10 @@ clock-frequency =3D <0x2dc6c00>; reg =3D <0x481a8000 0x2000>; interrupts =3D <0x2d>; - status =3D "disabled"; + status =3D "okay"; phandle =3D <0x7a>; + pinctrl-names =3D "default"; + pinctrl-0 =3D <0xce>; }; serial@481aa000 { @@ -2189,6 +2198,7 @@ hdmi_0 =3D = "/ocp/i2c@44e0b000/tda19988/ports/port@0/endpoint@0"; gpio1 =3D "/ocp/gpio@4804c000"; uart0_pins =3D = "/ocp/l4_wkup@44c00000/scm@210000/pinmux@800/pinmux_uart0_pins"; + uart4_pins =3D = "/ocp/l4_wkup@44c00000/scm@210000/pinmux@800/pinmux_uart4_pins"; i2c2_pins =3D = "/ocp/l4_wkup@44c00000/scm@210000/pinmux@800/pinmux_i2c2_pins"; pm_sram_data =3D = "/ocp/ocmcram@40300000/pm-sram-data@1000"; sha0_fck =3D = "/ocp/l4_wkup@44c00000/scm@210000/scm_conf@0/clocks/sha0_fck"; Next step is to make an overlay version - hopefully I can look at that = tonight :) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-arm@freebsd.org Fri Aug 17 06:42: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 0BFDA1084A68 for ; Fri, 17 Aug 2018 06:42:50 +0000 (UTC) (envelope-from ml@vishwin.info) Received: from varun.vishwin.info (varun.vishwin.info [46.101.93.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "varun.vishwin.info", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C5EA8F96C for ; Fri, 17 Aug 2018 06:42:49 +0000 (UTC) (envelope-from ml@vishwin.info) Received: from varun.vishwin.info (fd35:9eae:7575::2 [IPv6:fd35:9eae:7575::2]) by varun.vishwin.info (OpenSMTPD) with ESMTP id 92313f37 for ; Fri, 17 Aug 2018 02:42:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=vishwin.info; h=subject :references:from:to:message-id:date:mime-version:in-reply-to :content-type; s=fuccboi12; bh=Hn1A4Jkxr1vr+8JvLN7r9fBOnVjBBKFjg czRcSf4DIA=; b=vWxFtXQUMeldU6UiigheLJ8t2Yg1/3PQjV9+wzuvz7oKSCLSq caA3/6lRrIxyjcqEZqEVI3b5uoH3YP/9vImlgVq7QR8c9xC3EheITIfhIkEkAp+H 3C+x4jp+rtsIMFN6kwgRZdCMxVkyIdaDY0Ph1J1Eggemgc97O98o7N2RGUFxBQtN mx/dX+iXgQgVcFv8TYUuR+DiT/EEcuU9/Azh9ph7ymXmeGHgCBc/C7koU5XBuEeS G22j3jOO03R11NSxgIn01/2QxSKvqYkYi3xi/3bgSVrjPjo6O0D87j64ITTbeZSv k/IXBCtMH0blzL3zZQjXpvO58CAvZNf4tDG1Q== Received: from [IPv6:2001:470:8:6ca:cad7:19ff:fec0:a06d] (2001:470:8:6ca:cad7:19ff:fec0:a06d [IPv6:2001:470:8:6ca:cad7:19ff:fec0:a06d]) by varun.vishwin.info (OpenSMTPD) with ESMTPSA id a2812e6a TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Fri, 17 Aug 2018 02:42:43 -0400 (EDT) Subject: Re: RFC: Switching armv7 to WITH_LLD_IS_LD for testing References: From: Charlie Li Openpgp: preference=signencrypt Autocrypt: addr=ml@vishwin.info; keydata= xsFNBFe4p7sBEADHSqa7WkWYRhRiAYsECn4Ek29AkNS7SF4YAbZTzg+3xkPL5cM5zbNCR4U4 o99wC0Y5wQn9y9X9wM16k1AxBkeQ7Dgh+AjxYGnwDjyrVdx9fcId8dQvLV/xw4V2b5CtU0Et M9IE3MDOkgLtWJamTWIL/MfrNgWk5nRZDBhDcygkTO87t0Pi4WC/QQ3TrrDya6FbBPI7I5Y2 0arX2LAeXqJ6pF7uPfjqogKy3UL+t++9nTG6FNR2oftlts1AB+kGHXJf1GiewXLpPEJTGlXx P+XGhjALqJkFw6azELYKjZcd9zGEOWiKJKp2c2RUDdEJHy+cm6cJ8g7dabVA4ZXs5O7NzeMr on7xFbBx/l/0qHux+d7gS4Z+GJ9WGvzvuj4L8MLgA0eaNzn564RJ5FCtPpaulMhcSc78LhZs NCN3rq8VxsxNrIFTlvnLdLsTNITZOKXnyalE9WlM3cK6UlQaagShhO3FliI2hIOW7j4QWJZC Thynnnj5wIAOgKv1WKFwnKJsMfsohIME6uqmt5AcH5okXGZCcBJx30+enqsoEYOvg0pi5oY7 6F/bQdvHzY2prjeujo0oJhVSeRpv5tjEUBDjX525SPNqvr4uddHiavrFBkesOh7nnOjsEMZ1 i5Q6iZrQpteoafFZTld7tfLw8gMwyiSleKN+x7tJG1H3d1Bd7QARAQABzSFDaGFybGllIExp IDx2aXNod2luQHZpc2h3aW4uaW5mbz7CwYAEEwEIACoCGwMFCQPCZwAFCwkIBwIGFQgJCgsC BBYCAwECHgECF4AFAlfq/VYCGQEACgkQtQ4IJhNZSS0i+g//fRJwTJHY/sjK0T0Mh0PzwSnm OSYEcscxTuMR9BQaXPMFjEPpArtms0Wd9S29BgzLB+F7To9MCFGiDB6yvF5fba4Zz+oJ9hB8 lJ3lvY1Hr/hxdxK6Etzl/oXM8LN08Hi9XrHDWm1yuLLJvpaynoOGotZYDLoh0hPomPp3j1w/ BcVK6cRCUArAhXwH0HWTKYlZcRsL/paTXvVgi0TKqF29u2ADhjukQh7qAwcZebC+FfxV9On4 1gCkco144JJX77Ak7g/IWeJy7MJCzbwH41PNyn/X5lwv5N+4cKcGlSOi1ndJuySY2G2Pr1Wu rRyUQ/BF70/laaQOsd5Eg4QimzhOJ3G7QqtYOCZdFBvRs4i3ht0tyKgh4NIr9Zl6FaX/AsDJ d1PBdaWdUaY3NHEDFHtntL9xWxdc+UM21fMqAh+TK4zY+FhaudZO1MdBjrMd8ukjpveaoWZJ NgFageX28AWqxFpOhcPDchkUnydqmEEnl87zuZ8OS+HilDH4JzVGAnYrCG4+/h0b9V4QGevS Jp5lnmSXv2/YFkTDHSXmyBTXrVCjfZM3zH9I+3unYxwio0iAhj8sE4gD2Mx53fmBzoS/3ckf dbG0rZ2lecEFiWez4wn7YTHWLl2ujmeBbhjoyY5JPjvOCkn2Gbcy7tJZqTW7ajkWzZQcexyW 7lLoCkCXz9zOwU0EV7inuwEQAOaRmAfkM3cDXbGYr+8QZ08T037xFyTx3pPtfg74BaL1DF5o 4nr7XG410rHT3biOUxH3Gk7NILQibA746zm/TKjj8m/S4xc+aGA8l/Wx34C/6UO+zUNg0Cpz Vynmwtvj6oh/guoPuO2mELf0tQTXEP8vo4nRVcuYlDm0VKHS5OFadlZuYc8vlCx3jOC0vXyC DUKSZu5HdcP3a75OUrHFa7fS6A6n4J8/OKyiXXO9+tUielafHv0zF4Enl7pJgRXLPoJm5FZk RQWNdltVXtfPeOvhM8Plwk5XXjkNShGhsCzTF56f2DUlHCXJQAVDHAbYuscifUY+2HrA41SY SMM1nS5YpQXRWOMuxeh1xwia1GNvgaJdaucCKZ4Fff1F6YuTPKGCOEOifRPoLfO6Te93o2Fs NvNWutiCO0jJj1rlLLdV44chMbiOIsdMtsMpj5/T/Jrm7aD2NvWXJy5+aDyqjmE529oVBYha ouX9XEeWzUL5MxdqgT2LlmBv/y6XbXhXTOUHBBQyCBbqDqiQOWPtOkusiCajTyY0lsM3gR24 +igkJEMND+kJmMdn7G8pSKy7LgRlW4haGmz+80xfMf593APbzlnGB8gD0aH7/ejYCMkGaYz+ ZwFopkl0I4QQxSc3tvVljDhWNyGZxz2Dw4DNALHiG6xmESX00itf2zMPABMrABEBAAHCwWUE GAEIAA8FAle4p7sCGwwFCQPCZwAACgkQtQ4IJhNZSS3BIxAAsXD7PgkrQWu1DunaiPlL0MbR gv2evjY+2cLdpMt8Je3+e25r8JTbPKIV1QY3q0ju0yXgWLW0dM1hWSVpsQURLNyFYnivXt4q rLuDv4T/xTUo/xuV0rUOXp+oTDVKQ7KhpvKtaZFkP0a1z0pVFJbk7AI5UkQ4+lcuyTqzawxd vxn41s/FNKIxXTtj0PAgthzE0ZivAIj4USRaULC20ZvOYFW6rc10UPmrkLsrfXepakGBc0KJ EajF8LiOUqPE4c4BH2CoeEFu+e5OJAAl4kjj/CuNvtlko1Qjd31HPpMaha4l/WAd4kKPmMeW WuRxFkOwkkJFKW2ycH837Njl8Jn6dFSpgZ5/DPBvRdBXjAgDhySr2h9Zn5b6svtnh1ByKJKv ovzp+64IRqfotlLK3J9X1eKHlq10SyprH6IlxsGyXi987ZeV6/04UUAdmPXio/Enxbtna7D2 Cvo+aXTGM9Yu/YwxfmkWRJvEUUzqCOq63Z0Aa5ckOi+8FLUj3ZryS3ctmph/x/flN+ab4R22 pDL8LW1kwMH4Y4krv7l4GBgJPzkBGmonMclGf19i9zwC3TV8oSQ26cyi5d6QmuE3KN9NuLrD CJo3QQ3fpqQrnJbtd0M6fjuKWN0o7UTVEkcOXWWRF85d33VXG8XTDXEJmAJsELG7txDPNZ9o FqGGsWKHymE= To: freebsd-arm@freebsd.org Message-ID: Date: Fri, 17 Aug 2018 02:42:36 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PG8zOnm2Xw6Vz3yDi7ULA7AoFAtQmtsBn" 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, 17 Aug 2018 06:42:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PG8zOnm2Xw6Vz3yDi7ULA7AoFAtQmtsBn Content-Type: multipart/mixed; boundary="yKRURaan9bNCATEcFcInr9XhEV2o7HkJW"; protected-headers="v1" From: Charlie Li To: freebsd-arm@freebsd.org Message-ID: Subject: Re: RFC: Switching armv7 to WITH_LLD_IS_LD for testing References: In-Reply-To: --yKRURaan9bNCATEcFcInr9XhEV2o7HkJW Content-Type: text/plain; charset=utf-8 Content-Language: en-GB-large Content-Transfer-Encoding: quoted-printable On 15/08/2018 16:20, Ed Maste wrote: > I'd like to switch armv7 to WITH_LLD_IS_LD; unfortunately we don't > have an easy way to execute an exp-run for arm (armv7 specifically). > If there's no objection I would like to enable WITH_LLD_IS_LD for > armv7, observe a cycle of ports build, with a plan to leave it enabled > if the build is largely successful, or revert if not. >=20 I have WITH_LLD_IS_LD set in my 12-CURRENT armv7 crossbuild poudriere jail; at least multimedia/libx264 is broken in a similar fashion to PR 230214 ("R_ARM_ABS32 against local symbol" instead of "R_386_PC32 against symbol: memcpy"). --=20 Charlie Li Can't think of a witty .sigline today=E2=80=A6 (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) --yKRURaan9bNCATEcFcInr9XhEV2o7HkJW-- --PG8zOnm2Xw6Vz3yDi7ULA7AoFAtQmtsBn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE/RdyC3Asy49czZEGtQ4IJhNZSS0FAlt2bmIACgkQtQ4IJhNZ SS3TsxAAqUiXZbIISUylXZelma3sphNPkDUxNSNQd3G55oz+gmL+ffpmzsIfmIpJ 1LY/jNdfFSuiOaJZwqwlpOoQgPHTTQDvFbcgl1lpm0C+gcPg9veGyoGe8Yb+JFBh RsTQATgt6C7RAwEeyi0xDZk8n2eUDfTcHVlXfVjXqlI0vXFqhO7uLm07F2rbh0ns y227W5GkJCbcH8NBmVgLWka0HGYiDncGgb67ACqhHfp29DQ0q2sMUfQnrsmUZ1mU fBKQ6UV65iMKIKn6GT4G7+eY9gGimmCuqLPA5U/c+aiB8KGtSgTP96+t97Fya+Fw HsBZXx02/wRIUH74GMpaeDnVRokT3mwnSquZfewijfzCeGwrnS9TotrfN/GzxGp3 GHhgmItkU5NbOJCMeydJEVrjjtibQzRcJFa6CI17t7PHPBAXJGqRFmRQhE1QJskh 8IVnNHf0bk34jDnT8fdJTXbno6ougO0ppQFKVyfmybxDNQ3Jqr0/bzfBV851gteW SVmRYiZSlIqhXLB3frqY78vevyBYcQ2r/zczc8latH4MuvbQprDvk+gCbeUueQzu qSW9tqi5qwcg8ZPlKckZo+OwOIZ1y8C5U/KK1xNuRK4lhYPtLQzrC+t89LgLI38G x60L7CxButdMYJo7eHparCubrh+eaE2KlSg5ZG4pjH+cZOxAc7k= =C6/x -----END PGP SIGNATURE----- --PG8zOnm2Xw6Vz3yDi7ULA7AoFAtQmtsBn-- From owner-freebsd-arm@freebsd.org Fri Aug 17 07:46: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 164DE1085D22 for ; Fri, 17 Aug 2018 07:46:02 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail03.adl6.internode.on.net (ipmail03.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id 3039671201 for ; Fri, 17 Aug 2018 07:46:00 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp121-45-39-162.bras2.adl4.internode.on.net (HELO midget.dons.net.au) ([121.45.39.162]) by ipmail03.adl6.internode.on.net with ESMTP; 17 Aug 2018 17:09:40 +0930 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.14.9) with ESMTPS id w7H7dQPr028881 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 17 Aug 2018 17:09:33 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.14.9/Submit) id w7H7Qkun021913 for ; Fri, 17 Aug 2018 16:56:46 +0930 (ACST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.0.2.26] ([10.0.2.26]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id w7H7Qklu021911; Fri, 17 Aug 2018 16:56:46 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Beaglebone Black pinmuxing From: "O'Connor, Daniel" In-Reply-To: <72D8FE35-EE57-4E40-A604-4DF9DC8FEE05@dons.net.au> Date: Fri, 17 Aug 2018 16:56:44 +0930 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <13360A40-3381-4AF9-8EC5-C8E9B00CCABD@dons.net.au> <56756FA3-8FD7-44A4-A2D8-054E7C86744B@obsigna.com> <3B199FD0-479D-49C5-8E6F-DDE3D447EB03@dons.net.au> <72D8FE35-EE57-4E40-A604-4DF9DC8FEE05@dons.net.au> To: "Dr. Rolf Jansen" X-Mailer: Apple Mail (2.3445.9.1) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.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, 17 Aug 2018 07:46:02 -0000 > On 17 Aug 2018, at 13:36, O'Connor, Daniel wrote: > Next step is to make an overlay version - hopefully I can look at that = tonight :) Another thing would be to capture the PPS signal - it is connected to = timer 4 but I can't see how to enable it. Naively adding status =3D "okay" to timer@48044000 {} and/or = timer4_fck@510 {} does not result in it showing up in dmesg. I had a = look at timer@48042000 {} which does show up in dmesg but can't see a = likely difference to explain why one works and the other doesn't. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-arm@freebsd.org Fri Aug 17 09:28: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 97E311088092 for ; Fri, 17 Aug 2018 09:28:10 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 12B6D74119 for ; Fri, 17 Aug 2018 09:28:10 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x236.google.com with SMTP id d16-v6so1090760itj.0 for ; Fri, 17 Aug 2018 02:28:10 -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:cc; bh=2+6457fjvYYlTVLZXzuXCooD0rC1ig29UXhm2kjXMvU=; b=oUIqsggWQzAzb8xtCX4poCZp8jLE1RxetwtQtpxSs+xIHieCmDWaO4bhn1srfMxtVa ons/M5LGtWVOgTzlLxhjrkCXrCUYVjOMhM9jPD+Q7YNdwIW0/tqMfxt5G4/EIzX3uIj3 VKHAwKFa/Y+P8AZ34BBjajxvR0YcHd4XROjnttygp2wEZENZAhCxfz4uSSim92RjL6Kd Mrhn0jnr6sUjXa+BMb4IVIjHIw2btcJUGGFjZ7n5okeHj0xvfJQWRyJNTPmp7H+HflZz w/WMJ8W4tmtWQ8hp1YffRDoHjy3esXjYq56JpSyyinIyg8GjvdraUeuSLEnCZmJit42V hh7A== 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=2+6457fjvYYlTVLZXzuXCooD0rC1ig29UXhm2kjXMvU=; b=WKUrs7uGGnF3ovr+VFWO75M23cxNDwa7Li79/odXMt+jDm733ynXwy6+yYdj3h/rRC FXGFpZy7knIVROSr5C/+YoocSqgPmOD4/E1XcapmhqA9KJgCpKSxgkWnbNsnYtnGPq2w 0MXtKLltafK5SXxBUmvLmHeVTuL9ggJ5Gul+5phgzUpHSNZS8u57PaQN8WISngtKspOt 5aLxOAiBXohYa0D89/mS4RCEmVywZH6dYbH8N6d2aVpKEdDuSaOxK8P1Qrv2jrWaH584 39yFG3RydAlyJHKCYJt5is3PASIp4ad0hYR95s1u7jG/7KwLC+S9xZ8527gJtqO6PkN7 hTTw== X-Gm-Message-State: AOUpUlFZsE/nSi7t5d3H9wzige/KV8voleR0LlmiPJ4bewUo6WUaSK0u 4j90ZzVz8h2zkpYgl9LXb8umw1pJbce4+1QfLJvBGg== X-Google-Smtp-Source: AA+uWPx2wC0LKVI3r6RPVbnb2ZBp69ELeAg4WgVHUa0XpM6F9d/sLCByovCHqpcSJOxaIHrsxGYXoD+gEWp4nD1mTts= X-Received: by 2002:a02:6c45:: with SMTP id w66-v6mr30562015jab.87.1534498089507; Fri, 17 Aug 2018 02:28:09 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:4a08:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 02:27:49 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Fri, 17 Aug 2018 05:27:49 -0400 X-Google-Sender-Auth: n6mk9yOjSVyrScSmvORbFMHoj2w Message-ID: Subject: Re: RFC: Switching armv7 to WITH_LLD_IS_LD for testing To: Charlie Li Cc: "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: Fri, 17 Aug 2018 09:28:10 -0000 On 17 August 2018 at 02:42, Charlie Li wrote: > > I have WITH_LLD_IS_LD set in my 12-CURRENT armv7 crossbuild poudriere > jail; at least multimedia/libx264 is broken in a similar fashion to PR > 230214 ("R_ARM_ABS32 against local symbol" instead of "R_386_PC32 > against symbol: memcpy"). Would you be able to try with LLD_UNSAFE=yes added to the port's Makefile? From owner-freebsd-arm@freebsd.org Fri Aug 17 15:47:51 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 1FA2510730A0 for ; Fri, 17 Aug 2018 15:47:51 +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 A75DA8459D for ; Fri, 17 Aug 2018 15:47:50 +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=D+t0+TTq6wKQWZWk2Gn69aR+vscwlMREnlEvhewPbws=; b=mY01Iv4mny9q1t/rbM72s3pVbopcRLTehatThBXB9h7RMGbYTxpUlqzs9BzIrpDdVhPJh39YOm2F+xHFH/oXbSVAt3EapeYFhgFWZKqVcnL0/yYNnCc4YZ0pUBXbxwOz6HPSJzTZjvfh51kSwvKHJGMbFD+PPxGiZ9n9M8suwi8= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id 2b9bf57b TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 17 Aug 2018 15:47:46 +0000 (UTC) Date: Fri, 17 Aug 2018 18:47:40 +0300 From: Greg V Subject: Re: Rockchip RK3399 (ROCKPro64) boots to multiuser To: Emmanuel Vadot Cc: freebsd-arm Message-Id: <1534520860.4036.0@hraggstad.unrelenting.technology> In-Reply-To: <1534366621.3897.2@hraggstad.unrelenting.technology> References: <1533577708.4175.0@hraggstad.unrelenting.technology> <1534253037.1656.0@hraggstad.unrelenting.technology> <20180815105602.b106e1f55a3f839880b1b60e@bidouilliste.com> <1534362095.3897.1@hraggstad.unrelenting.technology> <20180815224449.98b920836c2c7f8610449835@bidouilliste.com> <1534366621.3897.2@hraggstad.unrelenting.technology> X-Mailer: geary/0.12.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; 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: Fri, 17 Aug 2018 15:47:51 -0000 On Wed, Aug 15, 2018 at 11:57 PM, Greg V =20 wrote: >=20 >=20 > On Wed, Aug 15, 2018 at 11:44 PM, Emmanuel Vadot=20 > wrote: >> On Wed, 15 Aug 2018 22:41:34 +0300 >> Greg V wrote: >>> Alright everyone, good news ? I managed to reclock the CPU!!! >>>=20 >>> The patch is now at https://reviews.freebsd.org/D16732 >>=20 >> Thanks a lot !! >> I'll have a deeper look when I'm back from BSDCam. >>=20 >>> (and I think the style is more correct now. Though it's really=20 >>> =7F=7Ffscking >>> silly that the style doesn't like making "table-like" structures=20 >>> =7F=7Flook >>> like tables, i.e. with one-line "rows".) >>>=20 >>> Plus the hack you need to reclock the CPU right now at >>> https://gist.github.com/myfreeweb/88cb9340652f56498f4be770c77b9d61 >>>=20 >>> (the hack allows cpufreq_dt to deal with clock only, no voltage ? >>> since we don't have all the drivers for voltage.) >>=20 >> Are you able to switch to any frequency with that ? >> I would expect the cpu to hang if the voltage is too low or too=20 >> high. >> (I encounter that on RK3328) >=20 > Yeah =E2=80=94 I maxed the clocks for both big and LITTLE cores and got=20 > pretty great performance. >=20 > e.g. unixbench dhrystone index with cpuset to a big core: 804 =E2=80=94=20 > which is more than the 737 I got on Scaleway's ThunderX VPS! > ThunderX is still way better on unixbench's other tests though. > Not that unixbench is a great test=E2=80=A6 >=20 > Compiling neovim also took *way* less time than on RPi/ROCK64. >=20 > So, I think the big cores' voltage regulator (silergy,syr827) might=20 > just default to the highest voltage. > The chip gets rather warm when just idling in FreeBSD=E2=80=A6 Update: tried porting the fanpwr driver from OpenBSD: https://gist.github.com/myfreeweb/584de9b746a328e10c904395afe8a48f Reports 1.0V on boot. For some reason, cpufreq doesn't see the=20 regulator though =E2=80=94 any idea why could that be?? (cpufreq_dt shouldn't require the controller and regulator to be=20 separate nodes, right? There are other drivers like sy8106a where it's=20 all one node=E2=80=A6) Also, overclocked to 2.184GHz, still works great (benchmark score went=20 up again.) I guess either the syr827 is not actually running 1.0 V, or the=20 provided table is waaaay overvolted, or I won the silicon lottery and=20 my chip is just that good. Maybe I should write an efuse driver to look at the leakage=20 measurements=E2=80=A6 = From owner-freebsd-arm@freebsd.org Fri Aug 17 16:41: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 4B1D21075255 for ; Fri, 17 Aug 2018 16:41:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-21.consmr.mail.ne1.yahoo.com (sonic303-21.consmr.mail.ne1.yahoo.com [66.163.188.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 DB4B189695 for ; Fri, 17 Aug 2018 16:41:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: IV0WVFMVM1m1GDCoKwqsq_H1.aYARzl3DK8wmZ0.8AkRTfZ1aNHNyurogAy9_FQ YS5sQCodVK_oeG2wSuUgmhUTdh5IamZThkEg9DWUfkjClA7OqYHGlOrJp2kLkDaUsMknHj9zYi5N cl.xbQca6hIGPTwXK3JAoPo9gaXI1iW0gT3E_U78HO1qtvWi_Z_HA6XH1PWiv8QRFdBFb1B4A8n_ Gi_KYPIxZBmsyelnlDuObmNIWX29ZmHoLXEVi0o.Fw271h2UdxOq05h0AWl2i5o1.3jLJQ3OKO1l UyVXkHrWoZZzbCKNZe9VljDo5GCDiDot7fTAUJIFpxMIm1crciphf7u.fJykVIkV0_0xWiTMfEKY ek3r3XYJ3LmqLvILUX.Q9jGFCe4pu_LTnOH6Mp3Y8mr8e_duRIglz6XbjgoqC9mzFTyntK1euaX5 Vs0wSV8i_CMZBEVccGprr6KqygY7Hh3D1.tZrNIPA1gm8_D3Ob4H3i.Nw4PovqSZ.nxVrs_Md2n7 hvtfNUm3Zv9JmE3fkmJ4KFA88Hg7np4EE7uIoKICw1hR8WL1hZVka_a74VZmdLLpwflVgxqkfPLh .4zacg3RH0hSIy5W20rJxP6em90d7VlJMlJznEcj4nrNaJPZ1lXoD.Tc1VkfecDUiv8bPoJxsv.A 7OofOV0Dqb06FqvnMew4ERrtwOn1BBAUcCgYCUsqb9vyry3rpVgOoNBjDczcTmxSFgPFKG4HiMCd etoneQ_HhOQ.Ot1dGvVoz3WAElwIJBFZndXA_awL55Fwdtq8ZQFVAtXPrh1JeA.IETl.CgbbtgZP WFTxaXCLqLXvo01xazMWOTezjf5XptgBuQpSKFgJHrlYBjTJqHa0TtNK2IIDo1ho9KuAepVUgTL2 G5c3G07q6lizB4Yvuhs6p.s4EnWs.eomoiobvgWAjhdKcOsprK1amWWkXnnfUQWSWBKpYkLv23pF 8SGusp_EEFcu6NrLRDVqB_2D2AdTlkm_gdzCGsRR1zb3CZ.O7jLLPScg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Fri, 17 Aug 2018 16:41:12 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp409.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 32a6836bd10065a8bda5dca9c5e4459f for ; Fri, 17 Aug 2018 16:41:06 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: An odd example of the Pine64+ 2GB time jump? Or an interesting one? Message-Id: Date: Fri, 17 Aug 2018 09:41:05 -0700 To: freebsd-arm 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, 17 Aug 2018 16:41:19 -0000 The oddity is the timing of that 1st no_sys_peer reported at 17 Aug 07:24:09 (before the time is adjusted) in what is later reported below: timing relative to other things going on that had not been going on just before. The sequence establishing context follows . . . Henri Hennebert asked me to do some time monitoring during the long running poudriere-devel involving, for example, building lang/gcc8 with a full bootstrap. This was started during that lang/gcc8 build the 2nd /var/log/ntp.log content below was discovered during the package stage of what turned out to be a 12:32:45 or so for lang/gcc8 overall. Earlier was during the build stage. Notes: The laptop has 2 ssh sessions in to the Pine64+ 2GB, including the one with material below and the one running poudriere-devel. The laptop is also what is monitoring the serial console. I've not applied any patches for the time issue. (Note: there were prior instances of the date ; more command sequence that are not shown.) # date ; more /var/log/ntp.log Fri Aug 17 03:04:12 PDT 2018 17 Aug 01:02:20 ntpd[49765]: Listen and drop on 0 v6wildcard [::]:123 17 Aug 01:02:20 ntpd[49765]: Listen and drop on 1 v4wildcard 0.0.0.0:123 17 Aug 01:02:20 ntpd[49765]: Listen normally on 2 awg0 192.168.0.100:123 17 Aug 01:02:20 ntpd[49765]: Listen normally on 3 lo0 [::1]:123 17 Aug 01:02:20 ntpd[49765]: Listen normally on 4 lo0 [fe80::1%2]:123 17 Aug 01:02:20 ntpd[49765]: Listen normally on 5 lo0 127.0.0.1:123 17 Aug 01:02:20 ntpd[49765]: Listening on routing socket on fd #26 for = interface updates 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c01d 0d kern kernel time sync = enabled 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c011 01 freq_not_set 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c016 06 restart 17 Aug 01:02:21 ntpd[49765]: Soliciting pool server 103.105.51.156 17 Aug 01:02:22 ntpd[49765]: Soliciting pool server 45.77.78.241 17 Aug 01:02:23 ntpd[49765]: Soliciting pool server 198.98.57.16 17 Aug 01:02:24 ntpd[49765]: Soliciting pool server 173.230.152.251 17 Aug 01:02:30 ntpd[49765]: 0.0.0.0 c614 04 freq_mode 17 Aug 01:05:46 ntpd[49765]: Soliciting pool server 74.207.240.206 17 Aug 01:07:58 ntpd[49765]: 0.0.0.0 0612 02 freq_set kernel 36.141 PPM 17 Aug 01:07:58 ntpd[49765]: 0.0.0.0 0615 05 clock_sync pine64# fg top -CawSores . . . (I go to bed during this time; the laptop screen locks) . . . . . . (when I get back in I read an Email from Henri H. before the = below) . . . [1] + Suspended top -CawSores # date ; more /var/log/ntp.log Fri Aug 17 07:23:04 PDT 2018 17 Aug 01:02:20 ntpd[49765]: Listen and drop on 0 v6wildcard [::]:123 17 Aug 01:02:20 ntpd[49765]: Listen and drop on 1 v4wildcard 0.0.0.0:123 17 Aug 01:02:20 ntpd[49765]: Listen normally on 2 awg0 192.168.0.100:123 17 Aug 01:02:20 ntpd[49765]: Listen normally on 3 lo0 [::1]:123 17 Aug 01:02:20 ntpd[49765]: Listen normally on 4 lo0 [fe80::1%2]:123 17 Aug 01:02:20 ntpd[49765]: Listen normally on 5 lo0 127.0.0.1:123 17 Aug 01:02:20 ntpd[49765]: Listening on routing socket on fd #26 for = interface updates 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c01d 0d kern kernel time sync = enabled 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c011 01 freq_not_set 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c016 06 restart 17 Aug 01:02:21 ntpd[49765]: Soliciting pool server 103.105.51.156 17 Aug 01:02:22 ntpd[49765]: Soliciting pool server 45.77.78.241 17 Aug 01:02:23 ntpd[49765]: Soliciting pool server 198.98.57.16 17 Aug 01:02:24 ntpd[49765]: Soliciting pool server 173.230.152.251 17 Aug 01:02:30 ntpd[49765]: 0.0.0.0 c614 04 freq_mode 17 Aug 01:05:46 ntpd[49765]: Soliciting pool server 74.207.240.206 17 Aug 01:07:58 ntpd[49765]: 0.0.0.0 0612 02 freq_set kernel 36.141 PPM 17 Aug 01:07:58 ntpd[49765]: 0.0.0.0 0615 05 clock_sync 17 Aug 07:24:09 ntpd[49765]: 0.0.0.0 0618 08 no_sys_peer 17 Aug 07:24:42 ntpd[49765]: Soliciting pool server 162.254.66.243 17 Aug 07:24:43 ntpd[49765]: Soliciting pool server 129.250.35.251 17 Aug 07:24:44 ntpd[49765]: Soliciting pool server 173.255.206.154 17 Aug 07:24:45 ntpd[49765]: Soliciting pool server 74.6.168.72 17 Aug 07:24:46 ntpd[49765]: Soliciting pool server 45.79.111.114 17 Aug 07:24:47 ntpd[49765]: Soliciting pool server 69.195.159.158 17 Aug 07:24:48 ntpd[49765]: Soliciting pool server 199.223.248.98 17 Aug 07:25:53 ntpd[49765]: 0.0.0.0 0613 03 spike_detect -178.954593 s 17 Aug 07:25:56 ntpd[49765]: 0.0.0.0 061c 0c clock_step -178.956586 s 17 Aug 07:22:57 ntpd[49765]: 0.0.0.0 0615 05 clock_sync 17 Aug 07:22:58 ntpd[49765]: 0.0.0.0 c618 08 no_sys_peer 17 Aug 07:22:58 ntpd[49765]: 198.98.57.16 local addr 192.168.0.100 -> = The oddity is the timing of that 1st no_sys_peer reported at 17 Aug 07:24:09 (before the time is adjusted): it appears to be very closely timed with activity near my logging in on the laptop and starting to do things before the 2nd "date" above. It is almost like my new activity "kicked" the Pine64+ 2GB and ended up with the 1st no_sys_peer as a result. Looking around about no_sys_peer: "Indicates that there is no server that satisfies ntpd=E2=80=99s = stability criteria" So it might be tied ntpd noticing the time being odd and the later activity is ntpd gaining independent evidence of the from a set of servers and finally accepting the error is likely real and adjusting for it. [This suggests that the "no_sys_peer" is the best indicator of when the time difference was noted.] The second no_sys_peer could fit with this based on its having adjusted the clock and needing to re-certify. It appears that either I was very lucky in the timing of waking up and taking a look at the status or that activity somehow contributed to the timing of the no_sys_peer and related activity. I wonder if these notes should be referenced in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229644 (The "Affects Only Me" status there could be updated as well, not that I could do that.) For reference: head -r337400 is in use on the Pine64+ 2GB. I've not applied any patches for the time issue. The Pine64+ 2GB has a case, heat sinks, and a fan. UFS, not ZFS is in use. Ethernet is in use. Other than the serial console connection, nothing else is connected. As stands I'm using an e.MMC for the root file system and swap partition. But it is on a microsd adapter, plugged into a USB 3.0 capable reader, that in turn is plugged in to the bottom USB port on the Pine64+ 2GB. (I've used other USB media before. (Most types are more reliable with a powered hub but the e.MMC/USB combination has never shown evidence of needing such.) (It used to be the Pine64+ 2GB would boot from the e.MMC on the microsd adpater. But that is not true now based on what FreeBSD tries to do with the e.MCC that the Pine64+ 2GB can not actually do: a voltage change. Thus the USB involvement these days.) =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 17 17:12:33 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 F20891075E82 for ; Fri, 17 Aug 2018 17:12:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-32.consmr.mail.ne1.yahoo.com (sonic301-32.consmr.mail.ne1.yahoo.com [66.163.184.201]) (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 8F36F8A885 for ; Fri, 17 Aug 2018 17:12:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: fxbfZyEVM1m1KKO4.2da2CIPcY6BE.3gjhiJ2eETwFDKDLxIkiHOD_K_7W3iK_0 _xhp4.U2hWsGGf_gXQRKlMKNmI0KlWqoEEVQhsJE1CoNIngeyBq1_X8JICvDJnAaz7y6oAerFzxi is8oOeZLeysFwL5oVRWobxBgLCkyDimXbNORd5cV_N1bFBZ_wkSkp3ptwY3fX12O38L_sRWXj5lz gvUSjRxKqqP04wpp7laPXCOSyHPlvV4sxbWMa3BH8s70HbfgZQsd_H28xsfml4s8iQTvcz4ydcL6 7U9oQw_9xvCcK1pHZcxK7sIMnNXSmdaVxsLG0LLoj85OHROZ6q_tehf8R_Ns3vqmttQlvRuh3VTq XUszZ84YHv5cgk.QGZclEAC1GxHn8GL07IhuNWXVZICOLMwaDP.fS1rgcdXsuzGfRtAe14UEb9s5 GV3hALJB8hiPFlZOS2O7VlNUs9qQq6SnO6L59Uyg5_ROPjfsYPcTo.8mQ.LnHuEyawWoWX2Wt8aI 8yWaroj_lM9aEaQ0KzVRLU.tuLRP999tcZ9QKjN1E2jzSkXSGamNXLWXJNvxMd386vIXVe_MdPpC OR_1..VmRgWx1krVeayCMVgwCeDYaYqvtYoj7HOuzHaTFkVfDgJEHhltr6Nut4DLU.kPsEpNfN90 nJPYJjnDUFYVu.pFtE.wjP84p71duXO3kTCQEqJw2UjyT3p4nzGHnzmmnoM_BGzMRf1EHznvtSm3 xIxncJAZnAUzE8iiTnSKgqvd07S5ul0abM6Nyi_XZvVSw_nHnFaQvt33mUbZEpyB7c8cju1CTo93 g0utcN6VTt9vOiOWVWkrDTzZMN7TnUwpNamnd2sZkGBMHQEaXV1ZGTY1OZxcOTUU6X3X6hWyXdSC jQPKeRHVxC0MJnLfA75sGgq0qA6ugogfgWL8OoFsCH9mrhyQC4Evo5cuYkZuBGjEiB.aCpy5iHIo f29Hmh5E2qKr_OVred_4K6c1puJ9cdSQaLmH6aCU9Jrwxzvjh1WoLrLscoU071bEGnEzxlQ.O Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Fri, 17 Aug 2018 17:12:31 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp421.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 132f62f0be2dacdef42ea720af1cc5d4 for ; Fri, 17 Aug 2018 17:12:23 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Does anyone use sysutils/mmc-utils? How about on a Pine64+ 2GB? Does it work if you do? Message-Id: <830F7182-B664-4177-A40B-25AA235F27F1@yahoo.com> Date: Fri, 17 Aug 2018 10:12:22 -0700 To: freebsd-arm 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, 17 Aug 2018 17:12:33 -0000 I tried building (via poudriere-devel) and installing sysutils/mmc-utils on the Pine64+ 2GB that I have access to. But when I tried using it I got: # mmc extcsd read /dev/mmcsd0 | more ioctl: Operation timed out Could not read EXT_CSD from /dev/mmcsd0 (There is an sdhc card in the slot, it provided the kernel and earlier stage materials that the Pine64+ 2GB used to boot that far.) Is this surprising? Expected? (I currently do not have access to other contexts with an sdcard reader built in. So I can not test if the issue is unique to Pine64+ 2GB in some way.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Aug 17 18:26:15 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 3C56A1077CB1 for ; Fri, 17 Aug 2018 18:26:15 +0000 (UTC) (envelope-from ml@vishwin.info) Received: from varun.vishwin.info (varun.vishwin.info [46.101.93.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "varun.vishwin.info", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9734A8D12D for ; Fri, 17 Aug 2018 18:26:14 +0000 (UTC) (envelope-from ml@vishwin.info) Received: from varun.vishwin.info (fd35:9eae:7575::2 [IPv6:fd35:9eae:7575::2]) by varun.vishwin.info (OpenSMTPD) with ESMTP id 1a3d7792 for ; Fri, 17 Aug 2018 14:26:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=vishwin.info; h=subject :references:to:from:message-id:date:mime-version:in-reply-to :content-type; s=fuccboi12; bh=0nreXCDY2581cWxAhK4iyukxdEg23sdhQ GSaGBLAFIw=; b=sIlUBKWKyTDInZEiIi3iKAl4xK44HTQVV6of6U00h/jm4drXq jmglp9dWgMqclaXHFWtBfWmQl9qO/JFjpyDw79wEXNxkVp/BDYSk/L5vLaIvV3iZ xs3knDTHNJo/n5Cb33wZxgyULyP+YBouBm9q5exx9ItuEXnu9geRpoN1UqscW8nb tCYBjC2hy82yxeAO+L3sNQwamohcmeujwB6eRhBcpvtMMR1whAio6vpymckcE0GC KKsWOJE4f+v/D/40KJA/7SaElrO8hjrg+tvJRkmFhWLJvqak770OO4zM8vz4d0mf opeQ3RP6r0NGB3BSF8PbcYtmKaqwhAGbcp5/A== Received: from [IPv6:2001:470:8:6ca:cad7:19ff:fec0:a06d] (2001:470:8:6ca:cad7:19ff:fec0:a06d [IPv6:2001:470:8:6ca:cad7:19ff:fec0:a06d]) by varun.vishwin.info (OpenSMTPD) with ESMTPSA id 148ddbb1 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Fri, 17 Aug 2018 14:26:03 -0400 (EDT) Subject: Re: RFC: Switching armv7 to WITH_LLD_IS_LD for testing References: To: freebsd-arm@freebsd.org From: Charlie Li Openpgp: preference=signencrypt Autocrypt: addr=ml@vishwin.info; keydata= xsFNBFe4p7sBEADHSqa7WkWYRhRiAYsECn4Ek29AkNS7SF4YAbZTzg+3xkPL5cM5zbNCR4U4 o99wC0Y5wQn9y9X9wM16k1AxBkeQ7Dgh+AjxYGnwDjyrVdx9fcId8dQvLV/xw4V2b5CtU0Et M9IE3MDOkgLtWJamTWIL/MfrNgWk5nRZDBhDcygkTO87t0Pi4WC/QQ3TrrDya6FbBPI7I5Y2 0arX2LAeXqJ6pF7uPfjqogKy3UL+t++9nTG6FNR2oftlts1AB+kGHXJf1GiewXLpPEJTGlXx P+XGhjALqJkFw6azELYKjZcd9zGEOWiKJKp2c2RUDdEJHy+cm6cJ8g7dabVA4ZXs5O7NzeMr on7xFbBx/l/0qHux+d7gS4Z+GJ9WGvzvuj4L8MLgA0eaNzn564RJ5FCtPpaulMhcSc78LhZs NCN3rq8VxsxNrIFTlvnLdLsTNITZOKXnyalE9WlM3cK6UlQaagShhO3FliI2hIOW7j4QWJZC Thynnnj5wIAOgKv1WKFwnKJsMfsohIME6uqmt5AcH5okXGZCcBJx30+enqsoEYOvg0pi5oY7 6F/bQdvHzY2prjeujo0oJhVSeRpv5tjEUBDjX525SPNqvr4uddHiavrFBkesOh7nnOjsEMZ1 i5Q6iZrQpteoafFZTld7tfLw8gMwyiSleKN+x7tJG1H3d1Bd7QARAQABzSFDaGFybGllIExp IDx2aXNod2luQHZpc2h3aW4uaW5mbz7CwYAEEwEIACoCGwMFCQPCZwAFCwkIBwIGFQgJCgsC BBYCAwECHgECF4AFAlfq/VYCGQEACgkQtQ4IJhNZSS0i+g//fRJwTJHY/sjK0T0Mh0PzwSnm OSYEcscxTuMR9BQaXPMFjEPpArtms0Wd9S29BgzLB+F7To9MCFGiDB6yvF5fba4Zz+oJ9hB8 lJ3lvY1Hr/hxdxK6Etzl/oXM8LN08Hi9XrHDWm1yuLLJvpaynoOGotZYDLoh0hPomPp3j1w/ BcVK6cRCUArAhXwH0HWTKYlZcRsL/paTXvVgi0TKqF29u2ADhjukQh7qAwcZebC+FfxV9On4 1gCkco144JJX77Ak7g/IWeJy7MJCzbwH41PNyn/X5lwv5N+4cKcGlSOi1ndJuySY2G2Pr1Wu rRyUQ/BF70/laaQOsd5Eg4QimzhOJ3G7QqtYOCZdFBvRs4i3ht0tyKgh4NIr9Zl6FaX/AsDJ d1PBdaWdUaY3NHEDFHtntL9xWxdc+UM21fMqAh+TK4zY+FhaudZO1MdBjrMd8ukjpveaoWZJ NgFageX28AWqxFpOhcPDchkUnydqmEEnl87zuZ8OS+HilDH4JzVGAnYrCG4+/h0b9V4QGevS Jp5lnmSXv2/YFkTDHSXmyBTXrVCjfZM3zH9I+3unYxwio0iAhj8sE4gD2Mx53fmBzoS/3ckf dbG0rZ2lecEFiWez4wn7YTHWLl2ujmeBbhjoyY5JPjvOCkn2Gbcy7tJZqTW7ajkWzZQcexyW 7lLoCkCXz9zOwU0EV7inuwEQAOaRmAfkM3cDXbGYr+8QZ08T037xFyTx3pPtfg74BaL1DF5o 4nr7XG410rHT3biOUxH3Gk7NILQibA746zm/TKjj8m/S4xc+aGA8l/Wx34C/6UO+zUNg0Cpz Vynmwtvj6oh/guoPuO2mELf0tQTXEP8vo4nRVcuYlDm0VKHS5OFadlZuYc8vlCx3jOC0vXyC DUKSZu5HdcP3a75OUrHFa7fS6A6n4J8/OKyiXXO9+tUielafHv0zF4Enl7pJgRXLPoJm5FZk RQWNdltVXtfPeOvhM8Plwk5XXjkNShGhsCzTF56f2DUlHCXJQAVDHAbYuscifUY+2HrA41SY SMM1nS5YpQXRWOMuxeh1xwia1GNvgaJdaucCKZ4Fff1F6YuTPKGCOEOifRPoLfO6Te93o2Fs NvNWutiCO0jJj1rlLLdV44chMbiOIsdMtsMpj5/T/Jrm7aD2NvWXJy5+aDyqjmE529oVBYha ouX9XEeWzUL5MxdqgT2LlmBv/y6XbXhXTOUHBBQyCBbqDqiQOWPtOkusiCajTyY0lsM3gR24 +igkJEMND+kJmMdn7G8pSKy7LgRlW4haGmz+80xfMf593APbzlnGB8gD0aH7/ejYCMkGaYz+ ZwFopkl0I4QQxSc3tvVljDhWNyGZxz2Dw4DNALHiG6xmESX00itf2zMPABMrABEBAAHCwWUE GAEIAA8FAle4p7sCGwwFCQPCZwAACgkQtQ4IJhNZSS3BIxAAsXD7PgkrQWu1DunaiPlL0MbR gv2evjY+2cLdpMt8Je3+e25r8JTbPKIV1QY3q0ju0yXgWLW0dM1hWSVpsQURLNyFYnivXt4q rLuDv4T/xTUo/xuV0rUOXp+oTDVKQ7KhpvKtaZFkP0a1z0pVFJbk7AI5UkQ4+lcuyTqzawxd vxn41s/FNKIxXTtj0PAgthzE0ZivAIj4USRaULC20ZvOYFW6rc10UPmrkLsrfXepakGBc0KJ EajF8LiOUqPE4c4BH2CoeEFu+e5OJAAl4kjj/CuNvtlko1Qjd31HPpMaha4l/WAd4kKPmMeW WuRxFkOwkkJFKW2ycH837Njl8Jn6dFSpgZ5/DPBvRdBXjAgDhySr2h9Zn5b6svtnh1ByKJKv ovzp+64IRqfotlLK3J9X1eKHlq10SyprH6IlxsGyXi987ZeV6/04UUAdmPXio/Enxbtna7D2 Cvo+aXTGM9Yu/YwxfmkWRJvEUUzqCOq63Z0Aa5ckOi+8FLUj3ZryS3ctmph/x/flN+ab4R22 pDL8LW1kwMH4Y4krv7l4GBgJPzkBGmonMclGf19i9zwC3TV8oSQ26cyi5d6QmuE3KN9NuLrD CJo3QQ3fpqQrnJbtd0M6fjuKWN0o7UTVEkcOXWWRF85d33VXG8XTDXEJmAJsELG7txDPNZ9o FqGGsWKHymE= Message-ID: <88a66cb8-cd71-af32-e9a8-b6ee7a23848b@vishwin.info> Date: Fri, 17 Aug 2018 14:25:55 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I7QPsozcKIiU2DN1Mv6BMEzFsPP40WSSM" 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, 17 Aug 2018 18:26:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I7QPsozcKIiU2DN1Mv6BMEzFsPP40WSSM Content-Type: multipart/mixed; boundary="uGrEUYmG0Y2huPbMTPfQ9yYWisSMc3bcN"; protected-headers="v1" From: Charlie Li To: freebsd-arm@freebsd.org Message-ID: <88a66cb8-cd71-af32-e9a8-b6ee7a23848b@vishwin.info> Subject: Re: RFC: Switching armv7 to WITH_LLD_IS_LD for testing References: In-Reply-To: --uGrEUYmG0Y2huPbMTPfQ9yYWisSMc3bcN Content-Type: text/plain; charset=utf-8 Content-Language: en-GB-large Content-Transfer-Encoding: quoted-printable On 17/08/2018 05:27, Ed Maste wrote: > On 17 August 2018 at 02:42, Charlie Li wrote: >> >> I have WITH_LLD_IS_LD set in my 12-CURRENT armv7 crossbuild poudriere >> jail; at least multimedia/libx264 is broken in a similar fashion to PR= >> 230214 ("R_ARM_ABS32 against local symbol" instead of "R_386_PC32 >> against symbol: memcpy"). >=20 > Would you be able to try with LLD_UNSAFE=3Dyes added to the port's Make= file? >=20 LLD_UNSAFE has the port building successfully. It may be wise to check at least all the ports cited in PR 214864 needing adjustments for LLD since you said there's no easy way to exp-run armv7 just yet. I have a feeling at least those ports on armv7 would also fail similarly to LLD on i386 before adding LLD_UNSAFE or LDFLAGS+=3D-Wl,-z,notext . --=20 Charlie Li Can't think of a witty .sigline today=E2=80=A6 (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) --uGrEUYmG0Y2huPbMTPfQ9yYWisSMc3bcN-- --I7QPsozcKIiU2DN1Mv6BMEzFsPP40WSSM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE/RdyC3Asy49czZEGtQ4IJhNZSS0FAlt3EzQACgkQtQ4IJhNZ SS1WVw//X5+fCEsuwc5LQMIEB+M6tHC5ndPdgTos2cA2oSYYHdUZS6CCABoCsWnY 9lUp1bbWGo7YfkBiDmmfiZJmhoYQTmQ+bml1mCt+1ooeD1SM3MVPx2ImlqTD968z F1TYq+jjaBLQB/ScjQSAtcM3LQ99WS8emPoeLBRLiLBZfBNuxx9T3Utgk5SVXr9+ aufjjU9qlYt5hFqAsHGd3PxqdPmnBu6wTPmNve/quRa5xKq42lcy1YGCFd/UpzND Y8vnWHhaHL/8YIEyHVRisL1UDOcMU44boUh8bzqUAiqNzQQCxevWcS+smfnzPWW5 DhUQpKLnAAe31iKQr1QCzy/QYNXclNB1Y2D7f0A4w/s1YYu+U78ZhuTYX1nPv+ew vXHdvtTjaPU1pPrRx7Dteq9xeSPPfNgGC0dxVMU80e3iaD+dVpPvMgAG13ECJ8fv 9rYaARKqpWCFKcaElonJaFChnZTn0hPA2WsWXI4UHGcmEPIkTgOLbGTKHF/DCQFY TyNBWy/ToaDgbVr0xkCVH4oJwwYyLlLrYx9k1A35yaGSzRp2DiuNWl1KZ5J8wOLJ KmGRMYT3iaxZ8rSOtzoEZKvqTw8OLjWnFVEr6XCDcorVNl8yCstHqYmypVmAJRKB 1D+XEvqIXNWBFDHFxrQu+WmNMSNLz8QCTLDWBgkoPxNE3Mpvepw= =BsrU -----END PGP SIGNATURE----- --I7QPsozcKIiU2DN1Mv6BMEzFsPP40WSSM-- From owner-freebsd-arm@freebsd.org Fri Aug 17 22:42: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 CF432107DC84 for ; Fri, 17 Aug 2018 22:42:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (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 7B58F75FA9 for ; Fri, 17 Aug 2018 22:42:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: jTFyirwVM1nBony8LypVu8dn5OchLnrxhs.LCfzQBEo8R.D6dhA_JH_w66WdodW gy5g3uTrPSooW.3Ia9AeRyb8tyP0UFduJNbMOnv.CRpA.zqnRAfxiL._yH7ZftDW95cCLIpb9O.V i6bD4BK12WKHo_H4I7AHfqzEq3NY4Vwe320T6ujpKH0ndBCTtoAFU_5sSFF5jtY1d5iItnRLIDdx 5AeKrQLYbVENmrKAgc2x3GmBAKrPfIahr9Zs9mjOILKpGiKRtVL1qdZ7rN0V7Nu2Di0MzE3WKwT. lZeoFywSJMi7bghz7F6VQnRhHy9FMH_.ud0yoltOBeL4A2Hki6i_bBKQylQ_TcuOSzEySHdt20d6 bvOvlOPEI6Xn0R6BJCxXxeTrRRLs74P0xrQesRseSI9XzQauXxfaZHyn5RotI5SUaZL8TjibwBK6 zAAdN8CTBYaKlN1l0Di7pxdT0avpAvHw_BLtA9rMKJN02G.fPRminCzVbvEVyAsJHxasWfHXjG.r NwFws7_OzCb1HCPFbLiaNKb.qrW67JWopz0ELcrEIC1kHNFRhcmW0SOSAQaMPpn5ccJ5qM2vEGxN yoB4QJeom18Q.6gjySYHeVIh9jXI.AWsrcNX6pXLGvQTUb0kMtMNGxKDDK0yek86q_lbTSce7DZ. zTHoCwggvtVCqUsFOyLDrAJBrLL4hdB7acdD6PGQAfRWmpK.dVw_lc4YIRGvfgEbXtb6tmyXd0Hz pXhKW_.daLPl8hBKhZcKupT4QkhZgULn9VnpipVQ2ejIFiO3d7xwjg8p4FyCoBndRSTRZxVu7PDt lKTCwnjh_Uf_f9af19D6SVm9MSfncpc0kVrA7Na6AQLBuWJUOFoljamL29LVaEeOrX1lcC9icXh0 gd9AiTGACCWjt6EYkjMNcWUiroMaPsc6vqc5xIb4meLT6_wq8l0QWGdBeF9QhEg.KY3AvfSvs0Dz 0Ivu6iKivYFQutTjBKBl.aCixJAj6sSHsQHE4HQT0xXsq7xcNtKgptcorPjOYUuKFuasNALKqE4T 4Q.IEtr9WtGU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Fri, 17 Aug 2018 22:42:53 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp413.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ced4bc16d12630bd4728c6a8ec7d60f0; Fri, 17 Aug 2018 22:42:51 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: MACCHIATObin Message-Id: <4DCCA5C9-C156-4080-A8F9-035478AC2FF7@yahoo.com> Date: Fri, 17 Aug 2018 15:42:49 -0700 To: mw@semihalf.com, freebsd-arm 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, 17 Aug 2018 22:43:00 -0000 Marcin Wojtas mw at semihalf.com wrote on Fri May 11 07:55:40 UTC 2018 : > Short status of the support - last year we enabled most of the > platform functionalities (core support, USB, AHCI, RTC). Three big > items remained left: > - PCIE root complex (this should work soon with the work done for > another SoC, not merged yet) > - Network PPv2 > - Xenon SD/MMC controller I noticed a check in that deals with that "Xenon" SD/MMC controller: Author: loos Date: Tue Aug 14 16:33:30 2018 New Revision: 337772 URL: https://svnweb.freebsd.org/changeset/base/337772 Log: Add support to the Marvell Xenon SDHCI controller. Tested on Espresso.bin (37x0) and Macchiato.bin (8k) with SD cards and eMMCs. Obtained from: pfSense Sponsored by: Rubicon Communications, LLC (Netgate) Added: head/sys/dev/sdhci/sdhci_xenon.c (contents, props changed) head/sys/dev/sdhci/sdhci_xenon.h (contents, props changed) Modified: head/sys/arm64/conf/GENERIC head/sys/conf/files.arm64 . . . But I've not noticed check-ins for the other of the "big items" going by. (Though they may have.) Care to comment-on/update-the actual status for the Macchiato.bin(s)? (Someday I expect to again have access to a Macchiato.bin, but it will not be a while. So this is just for my background information at this point.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Aug 17 23:10: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 2B88F107E1DD for ; Fri, 17 Aug 2018 23:10:57 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 B908576A92 for ; Fri, 17 Aug 2018 23:10:56 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-oi0-x22d.google.com with SMTP id d189-v6so16718226oib.6 for ; Fri, 17 Aug 2018 16:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y4LiKF7HSbqv45ninexG1e6e1fvJmO2o9qrBqOhDk7Y=; b=GdoQsXoVTGNjLcMH86dq7EXYw8cFRflSaulfxbnGdahhP8juYlf7RXfB+ePeWVApi3 l4ES+/nvY0FvBzp3IcTmOTphTdwNMwTdxz3FMsvvP7JoDrwE45l5q9qj3/CuAiqcOb2q i2KZFD+k3IAoAj8zjVfH/yi37zm3Q/EexUyiY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y4LiKF7HSbqv45ninexG1e6e1fvJmO2o9qrBqOhDk7Y=; b=uM0LNl24Ylei6xvbzQJDEpopQyu+zWMJWwVmeUVRiJ+3clnu+Oi3444g+wnaHjfeVm 5bsgi9wqFhHbNWs1rAd1vogcyhUDPf4ggNdhTReBdO+e75aJ4ZnkkfJGESTzp57ZnwAv cFpBYfZ9UHVTx4oScT9lbzpHJ7Hncmq2nHG4rtSCJVToAFcj6I2CQvYONkXuzrsw8QgJ 4BUR+zU4NncPWZo7BTRCgD8h8Wt99yhNeGHshF8hzBmYwtH7pPbCs4qqaXGueD1/tvmI o/4POEhBlVpVDnJ7SS+JO+sgdiKWOW6o0WJ+xetKqRpsje2IOotfYh/KTI6aqr88/8rY IECg== X-Gm-Message-State: AOUpUlEqSjCA/FAiesKq+dt3IbqvboB8Pj67cfmOC0vRHXRuelYrBQyg jyhLQ5Wh9OrUmZvHXqeuJ7K7cg== X-Google-Smtp-Source: AA+uWPzC8uMR4EwxNaX9EF8EO8NzNpGjwrGo02JjRqRwaPs9PO3Xyi/ULiMC8CTDNdNt3b7fP4W/qg== X-Received: by 2002:aca:90d:: with SMTP id 13-v6mr4125901oij.300.1534547455567; Fri, 17 Aug 2018 16:10:55 -0700 (PDT) Received: from [10.10.10.206] ([66.196.5.190]) by smtp.gmail.com with ESMTPSA id d191-v6sm6013294oig.16.2018.08.17.16.10.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Aug 2018 16:10:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: MACCHIATObin From: Jim Thompson In-Reply-To: <4DCCA5C9-C156-4080-A8F9-035478AC2FF7@yahoo.com> Date: Fri, 17 Aug 2018 18:10:53 -0500 Cc: mw@semihalf.com, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DCCA5C9-C156-4080-A8F9-035478AC2FF7@yahoo.com> To: Mark Millard 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, 17 Aug 2018 23:10:57 -0000 On Aug 17, 2018, at 5:42 PM, Mark Millard via freebsd-arm = wrote: > Marcin Wojtas mw at semihalf.com wrote on > Fri May 11 07:55:40 UTC 2018 : >=20 >> Short status of the support - last year we enabled most of the >> platform functionalities (core support, USB, AHCI, RTC). Three big >> items remained left: >> - PCIE root complex (this should work soon with the work done for >> another SoC, not merged yet) >> - Network PPv2 >> - Xenon SD/MMC controller >=20 >=20 > I noticed a check in that deals with that "Xenon" > SD/MMC controller: >=20 > Author: loos > Date: Tue Aug 14 16:33:30 2018 > New Revision: 337772 > URL:=20 > https://svnweb.freebsd.org/changeset/base/337772 >=20 >=20 > Log: > Add support to the Marvell Xenon SDHCI controller. >=20 > Tested on Espresso.bin (37x0) and Macchiato.bin (8k) with SD cards = and > eMMCs. >=20 > Obtained from: pfSense > Sponsored by: Rubicon Communications, LLC (Netgate) >=20 > Added: > head/sys/dev/sdhci/sdhci_xenon.c (contents, props changed) > head/sys/dev/sdhci/sdhci_xenon.h (contents, props changed) > Modified: > head/sys/arm64/conf/GENERIC > head/sys/conf/files.arm64 > . . . >=20 > But I've not noticed check-ins for the other of the "big > items" going by. (Though they may have.) >=20 > Care to comment-on/update-the actual status for the > Macchiato.bin(s)? tl;dr: It=E2=80=99s not =E2=80=98there=E2=80=99 yet. Specifics: - loos@ has done a lot of work to get the espresso.bin working, and some = of this carries over to the 8k/7k. - We have another internal developer working on an EIP-97 driver for = crypto offload. This should be a foundation for the EIP-197 in the 8K. - I know manu@is working on pin controllers and clocks specific to = Machiatto.bin (80x0/70x0). - Getting the NICs, PCIe, etc working still remains to be done. Jim From owner-freebsd-arm@freebsd.org Sat Aug 18 06:43: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 D88241087849 for ; Sat, 18 Aug 2018 06:43:45 +0000 (UTC) (envelope-from mw@semihalf.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 6096384BB0 for ; Sat, 18 Aug 2018 06:43:45 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-io0-x22a.google.com with SMTP id q4-v6so8650172iob.8 for ; Fri, 17 Aug 2018 23:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ii3Xh7AiY+0JnLcLWjX9qYlo1wvvhb0fPXTplBq5Dm8=; b=ueU/EfeCF1sq+OPnWP5xbw1ydu4CxrBYUKWW//fkeBmMS6WDtCogWKjaj3LsfFU6qP dNBto9NcooyghK0OOko5x3VmLlH6QqZU9FiSbek2ND+bJ+1fNZhQ/oRtbaLsbt+aqpr9 0vYoJhV7i0+8c55eiIyKw/o9/LRjEr0pQd0795iaooGmUJVVGQDsovzr9nQ5LSr0+u9X 2Sudbh1H0/gAuU4C9B1t1Iho2GNdL5yEizWtZa2a0uFh/FY5nQWYoifm8MmHIJ77vrTI jShfPruPtykuyBF6mRz2FVxpARXGo2g2lkJhq5F+IhEedvT9EEGG1HBpuvgXaIRSd/zL tm4A== 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:content-transfer-encoding; bh=ii3Xh7AiY+0JnLcLWjX9qYlo1wvvhb0fPXTplBq5Dm8=; b=LEWZ7/IELz6SvMp3Zr7p74cIAI0EFATw0MgPogOf/mgfldHRXWcJZjgOcduD+gK3dq 0ShWijnyphAQ3bP+9Tf9tBIKSSdD8xUQLMbXvZLapWBREwJOj9DtTfXtaqSzf3JAuwOt FO6/smSRj92FrTeZukqhzqSL/y/tPzmbg8bCsfLmS11PwXe8SWzXBaT6h6mZUHEDnxTG up7nOPK4F5QEHE/xw1+uJMSzG30FNkeYPBCsRSpJFHw99HJk10pXuOxwzwhsd9vj3MY6 h5uCTQb8Z83vTzNatuJBhIKwmlV9H78SlL8mYeqikcbZkQWpTN6Y2EKi5smZXlOL3gtJ uJWw== X-Gm-Message-State: AOUpUlEFFDNESqtrNfhrNRy3m6daA7CrTZz1CxW/37Zb8jvb1Oj6y4LI zb23bv0iKH0vx/ENQjF+R9hCfQqbuLLWFLov3y+/bw== X-Google-Smtp-Source: AA+uWPz6yxHMYumFE1sJcZ0Fko9XTukSfzTruYZrmDoo1dC+2MwpS4fmU1HBlawaqluHujam2ei+YVvKLUbfq2k/Z18= X-Received: by 2002:a5e:c649:: with SMTP id s9-v6mr30058828ioo.108.1534574624404; Fri, 17 Aug 2018 23:43:44 -0700 (PDT) MIME-Version: 1.0 References: <4DCCA5C9-C156-4080-A8F9-035478AC2FF7@yahoo.com> In-Reply-To: From: Marcin Wojtas Date: Sat, 18 Aug 2018 08:43:32 +0200 Message-ID: Subject: Re: MACCHIATObin To: marklmi@yahoo.com Cc: freebsd-arm , Jim Thompson 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: Sat, 18 Aug 2018 06:43:46 -0000 sob., 18 sie 2018 o 01:10 Jim Thompson napisa=C5=82(a): > > > > On Aug 17, 2018, at 5:42 PM, Mark Millard via freebsd-arm wrote: > > > Marcin Wojtas mw at semihalf.com wrote on > > Fri May 11 07:55:40 UTC 2018 : > > > >> Short status of the support - last year we enabled most of the > >> platform functionalities (core support, USB, AHCI, RTC). Three big > >> items remained left: > >> - PCIE root complex (this should work soon with the work done for > >> another SoC, not merged yet) > >> - Network PPv2 > >> - Xenon SD/MMC controller > > > > > > I noticed a check in that deals with that "Xenon" > > SD/MMC controller: > > > > Author: loos > > Date: Tue Aug 14 16:33:30 2018 > > New Revision: 337772 > > URL: > > https://svnweb.freebsd.org/changeset/base/337772 > > > > > > Log: > > Add support to the Marvell Xenon SDHCI controller. > > > > Tested on Espresso.bin (37x0) and Macchiato.bin (8k) with SD cards and > > eMMCs. > > > > Obtained from: pfSense > > Sponsored by: Rubicon Communications, LLC (Netgate) > > > > Added: > > head/sys/dev/sdhci/sdhci_xenon.c (contents, props changed) > > head/sys/dev/sdhci/sdhci_xenon.h (contents, props changed) > > Modified: > > head/sys/arm64/conf/GENERIC > > head/sys/conf/files.arm64 > > . . . > > > > But I've not noticed check-ins for the other of the "big > > items" going by. (Though they may have.) > > > > Care to comment-on/update-the actual status for the > > Macchiato.bin(s)? > > > tl;dr: It=E2=80=99s not =E2=80=98there=E2=80=99 yet. > > Specifics: > > - loos@ has done a lot of work to get the espresso.bin working, and some = of this carries over to the 8k/7k. > - We have another internal developer working on an EIP-97 driver for cryp= to offload. This should be a foundation for the EIP-197 in the 8K. > - I know manu@is working on pin controllers and clocks specific to Machia= tto.bin (80x0/70x0). > - Getting the NICs, PCIe, etc working still remains to be done. > About the latter - the NIC is pretty complex, however we (Semihalf) have really huge experience with all its support implementations and the platform itself. I'll put it straightforward - it's only a matter of development funding, if it's guaranteed, we will do it with pleasure :) As well as the NIC support (DW Synopsys driver for DT and verify/improve on pcie-host-generic with ACPI). Best regards, Marcin From owner-freebsd-arm@freebsd.org Sat Aug 18 07:07: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 35F2C1087D03 for ; Sat, 18 Aug 2018 07:07:23 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A66D2853FF for ; Sat, 18 Aug 2018 07:07:22 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-io0-x234.google.com with SMTP id q4-v6so8675333iob.8 for ; Sat, 18 Aug 2018 00:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=phQLoDxaixhv5/DQWxqzbVmiAH0CmX67PtS8CrEgPOk=; b=iStmSMdayx45fxvQlMTaCfAV1C2bb/b8TT1aJ89bCyshXEYavoXDID39zd1fpw4mdp u+8GWZ2Rq8UoCi6aatkADIyls6InAlgRnTMo4O/9jHKwXjVCuQuHbzN15jSFdoDDTrMZ ZEvjrrzN4F1ZPTe6mGa+BC9oin1iRRgmx4zRknR2/Cearps2Cp8KyZuTcAP8IE28sNkb NHtf8BGPvXq4T1W1cvSDg1XBa3pej4c9FfKE8A/19b16pyRI1zD/avHuE1SnvOrH60uF mwNdbiPKvzh+sWwLIr0uqzEpOHhLJdZVLTc2WI6ffcZyBJSsp13lnKLWsK6I+j9Po2du nvMw== 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:content-transfer-encoding; bh=phQLoDxaixhv5/DQWxqzbVmiAH0CmX67PtS8CrEgPOk=; b=ELRPj9ZupupWwjOB5hAn8Kyz8ir1p6/O9N9yL2NPV+So0UAQLh/p9hwAkzlSDac9Ip rUz5RU3bAVXzBnIzK41tiDMuDCvgd++a4a1qsmlaAyxIdzvEYqejl4zm3TNvG3ruGaov uUrsfI9hTulyDFX9SDfIvtYC4BFMu8bukk3r2fvB0mEWUOx/6N3AoBB7BTW0KmSM0ITS 32eFOrsq1L22gcgj2fFw+meT4pH5/mv/WpZgR9hi+EXkDRtxR6RIgJvcbM0lXuYByOgr NI/oi5ZDcm2jDR3MlUcV6ENkQYuaqGJLFexkceSH6WoSqa5kxMg+J5oMwT6LJa5fNMF5 GT3A== X-Gm-Message-State: APzg51A42SDNju3z2kSJt4bC0daDhAsynaD5lcGz9ox+fpbRDfrfhtD9 otv8wEzi7R5pom9o2ltWJYa7jitExB4UYKouIbulXg== X-Google-Smtp-Source: ANB0Vdb358PAYDZ8uM/f8/bTL3eF1ko00Y/9R05AQAWUc0gs+Yt61e1HO8BwpPf34ieacsugQ7BGZCde1F+ry/oyktU= X-Received: by 2002:a6b:198e:: with SMTP id 136-v6mr2201726ioz.248.1534576041910; Sat, 18 Aug 2018 00:07:21 -0700 (PDT) MIME-Version: 1.0 References: <4DCCA5C9-C156-4080-A8F9-035478AC2FF7@yahoo.com> In-Reply-To: From: Marcin Wojtas Date: Sat, 18 Aug 2018 09:07:10 +0200 Message-ID: Subject: Re: MACCHIATObin To: marklmi@yahoo.com Cc: freebsd-arm , Jim Thompson 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: Sat, 18 Aug 2018 07:07:23 -0000 sob., 18 sie 2018 o 08:43 Marcin Wojtas napisa=C5=82(a): > > sob., 18 sie 2018 o 01:10 Jim Thompson napisa=C5=82(a): > > > > > > > > On Aug 17, 2018, at 5:42 PM, Mark Millard via freebsd-arm wrote: > > > > > Marcin Wojtas mw at semihalf.com wrote on > > > Fri May 11 07:55:40 UTC 2018 : > > > > > >> Short status of the support - last year we enabled most of the > > >> platform functionalities (core support, USB, AHCI, RTC). Three big > > >> items remained left: > > >> - PCIE root complex (this should work soon with the work done for > > >> another SoC, not merged yet) > > >> - Network PPv2 > > >> - Xenon SD/MMC controller > > > > > > > > > I noticed a check in that deals with that "Xenon" > > > SD/MMC controller: > > > > > > Author: loos > > > Date: Tue Aug 14 16:33:30 2018 > > > New Revision: 337772 > > > URL: > > > https://svnweb.freebsd.org/changeset/base/337772 > > > > > > > > > Log: > > > Add support to the Marvell Xenon SDHCI controller. > > > > > > Tested on Espresso.bin (37x0) and Macchiato.bin (8k) with SD cards a= nd > > > eMMCs. > > > > > > Obtained from: pfSense > > > Sponsored by: Rubicon Communications, LLC (Netgate) > > > > > > Added: > > > head/sys/dev/sdhci/sdhci_xenon.c (contents, props changed) > > > head/sys/dev/sdhci/sdhci_xenon.h (contents, props changed) > > > Modified: > > > head/sys/arm64/conf/GENERIC > > > head/sys/conf/files.arm64 > > > . . . > > > > > > But I've not noticed check-ins for the other of the "big > > > items" going by. (Though they may have.) > > > > > > Care to comment-on/update-the actual status for the > > > Macchiato.bin(s)? > > > > > > tl;dr: It=E2=80=99s not =E2=80=98there=E2=80=99 yet. > > > > Specifics: > > > > - loos@ has done a lot of work to get the espresso.bin working, and som= e of this carries over to the 8k/7k. > > - We have another internal developer working on an EIP-97 driver for cr= ypto offload. This should be a foundation for the EIP-197 in the 8K. > > - I know manu@is working on pin controllers and clocks specific to Mach= iatto.bin (80x0/70x0). > > - Getting the NICs, PCIe, etc working still remains to be done. > > > > About the latter - the NIC is pretty complex, however we (Semihalf) > have really huge experience with all its support implementations and > the platform itself. I'll put it straightforward - it's only a matter > of development funding, if it's guaranteed, we will do it with > pleasure :) As well as the NIC support (DW Synopsys driver for DT and > verify/improve on pcie-host-generic with ACPI). "As well as PCIE support..." of course. Marcin