From owner-freebsd-arm@freebsd.org Sun Apr 23 13:36:28 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82311D4B077 for ; Sun, 23 Apr 2017 13:36:28 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4488E1CA2 for ; Sun, 23 Apr 2017 13:36:27 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x231.google.com with SMTP id u75so2823742qka.3 for ; Sun, 23 Apr 2017 06:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=Cao9zfnBvzpbOrpGE7Tdha8BAV7v0RkEkX+g8Y0lXB8=; b=XszsOfnHvpAtlNZFABpKOKrMgFHaKLTh48kErRynrP+5hPYhgs2HcypSb82DMPDqAm xVWgpkVMqDnt/+gy87dLI3mzuF+xAcx0aMhKz5mgrPP7q/x0U8pTAjB+7+9rMjaDPzdK 6GXIb70zAaMbnqsSeL/1J4+R+9F/oZ3mQ2yN4= 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Cao9zfnBvzpbOrpGE7Tdha8BAV7v0RkEkX+g8Y0lXB8=; b=eHEAHnPybbbctkNNL0eW6sdb8DIjmQOu30jbqfp3tZuAGrl9oTo/d2mUWn6naJPKid qJlDb0wwEMUaPDakTgYrfzWBa6ge+w3+M4NNgDXFNOQA1IEU7ECIsSKDX18H99hWmwCK JZV0cKZNx9htUbORNTYWMeuTkmZvxp1n+Z+cenMBX9JONpaz8TBnckh1doLPs7P5Id7k zlg9SsNIgkXoBEnVPFcd3umLVotFT8XkHvblUuzFXQGAW4ixBssQnnYBSGWnkFSY/fz9 fmLDhVM2bF7nq03JRxrCvL9Aqvvh1mdYmhHPF86BAMoZbeUi+LuXUZOAGjpYYeeVAKXI dJGg== X-Gm-Message-State: AN3rC/6pgg7KeQrV21ZYD1uQfKWsvRRnG35yB1AseOLGQvZevjGnwE8j SBobzPAdD2Yru3yI X-Received: by 10.55.167.72 with SMTP id q69mr15107778qke.193.1492954586624; Sun, 23 Apr 2017 06:36:26 -0700 (PDT) Received: from [192.168.0.11] ([177.89.67.185]) by smtp.googlemail.com with ESMTPSA id n195sm10735890qke.28.2017.04.23.06.36.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Apr 2017 06:36:25 -0700 (PDT) Subject: Re: HEAD on RPI3 To: Mark Millard References: <244BD33F-67B0-4C47-84E4-FD4B485689D1@dsl-only.net> Cc: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: Date: Sun, 23 Apr 2017 10:35:35 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <244BD33F-67B0-4C47-84E4-FD4B485689D1@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 13:36:28 -0000 Em 19/04/2017 22:26, Mark Millard escreveu: > On 2017-Apr-18, at 8:10 PM, Otacílio wrote: > >> Dears >> >> Someone that is using HEAD on a Raspberry PI3 can tell me the revision that is using? >> >> Thank you very much >> >> []'s >> >> -Otacilio > Starting with the sysutils/u-boot-rpi3 installed: > > # ls -l /boot/efi > total 7540 > drwxr-xr-x 1 root wheel 4096 Mar 18 05:26 EFI > -rwxr-xr-x 1 root wheel 1494 Mar 18 05:26 LICENCE.broadcom > -rwxr-xr-x 1 root wheel 123 Mar 18 05:26 README > -rwxr-xr-x 1 root wheel 6144 Mar 18 05:26 armstub8.bin > -rwxr-xr-x 1 root wheel 17480 Mar 18 05:26 bcm2710-rpi-3-b.dtb > -rwxr-xr-x 1 root wheel 17932 Mar 18 05:26 bootcode.bin > -rwxr-xr-x 1 root wheel 137 Mar 18 05:26 config.txt > -rwxr-xr-x 1 root wheel 6482 Mar 18 05:26 fixup.dat > -rwxr-xr-x 1 root wheel 2504 Mar 18 05:26 fixup_cd.dat > -rwxr-xr-x 1 root wheel 9716 Mar 18 05:26 fixup_x.dat > drwxr-xr-x 1 root wheel 4096 Mar 18 05:26 overlays > -rwxr-xr-x 1 root wheel 2747896 Mar 18 05:26 start.elf > -rwxr-xr-x 1 root wheel 618296 Mar 18 05:26 start_cd.elf > -rwxr-xr-x 1 root wheel 3879416 Mar 18 05:26 start_x.elf > -rwxr-xr-x 1 root wheel 9 Mar 18 05:26 startup.nsh > -rwxr-xr-x 1 root wheel 369456 Mar 18 05:26 u-boot.bin > > # ls -l /boot/efi/overlays/ > total 8 > -rwxr-xr-x 1 root wheel 1053 Mar 18 05:26 mmc.dtbo > -rwxr-xr-x 1 root wheel 818 Mar 18 05:26 pi3-disable-bt.dtbo > > So this is from before the sysutils/u-boot-rpi3 -r436197 > (2017-Mar-29) that was for: > > Do not overwrite WRKSRC when USE_GITHUB=nodefault. > > but is from -r433351 instead (2017-Feb-5 check-in). > > To update I generally buildworld and buildkernel from source > and install them, not doing anything with sysutils/u-boot-rpi3 > unless something significant seems to have come along for > u-boot. > > I just updated from head -r314687 to -r317015 : > > # uname -paKU > FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT r317015M arm64 aarch64 1200028 1200028 > > > > === > Mark Millard > markmi at dsl-only.net > I updated the fonts to r317063. I removed /usr/obj, removed the work folder from the crochet folder. I recompiled using both the GENERIC kernel r317063 and an older version of RPI3 r307565. I recorded on two different SD cards on two different computers and still the error persists. In this image you get the error message because that's all that I can do. http://pt-br.tinypic.com/view.php?pic=6hu6tt&s=9#.WPyq5Ma1thE From owner-freebsd-arm@freebsd.org Sun Apr 23 14:21:41 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46528D4C040 for ; Sun, 23 Apr 2017 14:21:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-20.reflexion.net [208.70.210.20]) (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 06F6E1193 for ; Sun, 23 Apr 2017 14:21:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18870 invoked from network); 23 Apr 2017 14:24:40 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 23 Apr 2017 14:24:40 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 23 Apr 2017 10:21:32 -0400 (EDT) Received: (qmail 1625 invoked from network); 23 Apr 2017 14:21:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 Apr 2017 14:21:32 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D8CA1EC904C; Sun, 23 Apr 2017 07:21:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: HEAD on RPI3 From: Mark Millard In-Reply-To: Date: Sun, 23 Apr 2017 07:21:31 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <244BD33F-67B0-4C47-84E4-FD4B485689D1@dsl-only.net> To: =?utf-8?B?T3RhY8OtbGlv?= X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 14:21:41 -0000 On 2017-Apr-23, at 6:35 AM, Otac=C3=ADlio = wrote: >=20 > Em 19/04/2017 22:26, Mark Millard escreveu: >> On 2017-Apr-18, at 8:10 PM, Otac=C3=ADlio >> wrote: >>=20 >>=20 >>> Dears >>>=20 >>> Someone that is using HEAD on a Raspberry PI3 can tell me the = revision that is using? >>>=20 >>> Thank you very much >>>=20 >>> []'s >>>=20 >>> -Otacilio >>>=20 >> Starting with the sysutils/u-boot-rpi3 installed: >>=20 >> # ls -l /boot/efi >> total 7540 >> drwxr-xr-x 1 root wheel 4096 Mar 18 05:26 EFI >> -rwxr-xr-x 1 root wheel 1494 Mar 18 05:26 LICENCE.broadcom >> -rwxr-xr-x 1 root wheel 123 Mar 18 05:26 README >> -rwxr-xr-x 1 root wheel 6144 Mar 18 05:26 armstub8.bin >> -rwxr-xr-x 1 root wheel 17480 Mar 18 05:26 bcm2710-rpi-3-b.dtb >> -rwxr-xr-x 1 root wheel 17932 Mar 18 05:26 bootcode.bin >> -rwxr-xr-x 1 root wheel 137 Mar 18 05:26 config.txt >> -rwxr-xr-x 1 root wheel 6482 Mar 18 05:26 fixup.dat >> -rwxr-xr-x 1 root wheel 2504 Mar 18 05:26 fixup_cd.dat >> -rwxr-xr-x 1 root wheel 9716 Mar 18 05:26 fixup_x.dat >> drwxr-xr-x 1 root wheel 4096 Mar 18 05:26 overlays >> -rwxr-xr-x 1 root wheel 2747896 Mar 18 05:26 start.elf >> -rwxr-xr-x 1 root wheel 618296 Mar 18 05:26 start_cd.elf >> -rwxr-xr-x 1 root wheel 3879416 Mar 18 05:26 start_x.elf >> -rwxr-xr-x 1 root wheel 9 Mar 18 05:26 startup.nsh >> -rwxr-xr-x 1 root wheel 369456 Mar 18 05:26 u-boot.bin >>=20 >> # ls -l /boot/efi/overlays/ >> total 8 >> -rwxr-xr-x 1 root wheel 1053 Mar 18 05:26 mmc.dtbo >> -rwxr-xr-x 1 root wheel 818 Mar 18 05:26 pi3-disable-bt.dtbo >>=20 >> So this is from before the sysutils/u-boot-rpi3 -r436197 >> (2017-Mar-29) that was for: >>=20 >> Do not overwrite WRKSRC when USE_GITHUB=3Dnodefault. >>=20 >> but is from -r433351 instead (2017-Feb-5 check-in). >>=20 >> To update I generally buildworld and buildkernel from source >> and install them, not doing anything with sysutils/u-boot-rpi3 >> unless something significant seems to have come along for >> u-boot. >>=20 >> I just updated from head -r314687 to -r317015 : >>=20 >> # uname -paKU >> FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT r317015M arm64 = aarch64 1200028 1200028 >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >>=20 > I updated the fonts to r317063. I removed /usr/obj, removed the work = folder from the crochet folder. I recompiled using both the GENERIC = kernel r317063 and an older version of RPI3 r307565. I recorded on two = different SD cards on two different computers and still the error = persists. In this image you get the error message because that's all = that I can do. >=20 > http://pt-br.tinypic.com/view.php?pic=3D6hu6tt&s=3D9#.WPyq5Ma1thE [I do not normally run with debug kernels and I normally boot with the root file system being from an external SSD off a powered hub. But I doubt that either of these points matter. I also do not use a file for my swap space: I use a swap partition. See Bugzilla 206048 and its Comment 7 specifically. It is too bad that crochet uses a file for swap space by default. But even this I doubt matters.] I've no clue what your problem is but I do see something that seems odd compared to what I'm used to. I normally see: Release APs CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <0> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 Trying to mount root from . . . But in your screen shot I do not see any of the 3 CPU affinity lines spanning "CPU"s 1-3 after the CPU 0 information that can be seen. (I assume it is CPU 0 since not all the text is shown.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Apr 23 17:08:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C1F4D4D45C for ; Sun, 23 Apr 2017 17:08:43 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BF0BF1DEF for ; Sun, 23 Apr 2017 17:08:41 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from crayon2.yoonka.com (crayon2.yoonka.com [10.70.7.20]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id v3NH8XUS062736 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 23 Apr 2017 17:08:34 GMT (envelope-from list1@gjunka.com) To: freebsd-arm@freebsd.org From: Grzegorz Junka Subject: ARM and IPMI Message-ID: <1d4ae412-c0d1-c67d-f8e9-ccb0c22008be@gjunka.com> Date: Sun, 23 Apr 2017 17:08:33 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB-large X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 17:08:43 -0000 Does anyone know of any ARM boards that can be managed remotely (e.g. through IPMI)? If not then what people usually use to manage ARM-based servers? Grzegorz From owner-freebsd-arm@freebsd.org Mon Apr 24 11:49:18 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7DF4D4DFDE for ; Mon, 24 Apr 2017 11:49:18 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.246.96.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 767B1242 for ; Mon, 24 Apr 2017 11:49:17 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.4] (188-127-209-196.cust.suomicom.net [188.127.209.196]) (authenticated bits=0) by mail.kronometrix.org (8.15.2/8.15.2) with ESMTPSA id v3OBVq6k093210 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 24 Apr 2017 11:31:52 GMT (envelope-from sparvu@kronometrix.org) Date: Mon, 24 Apr 2017 14:31:35 +0300 From: "kronometrix.org" To: freebsd-arm@freebsd.org Message-ID: <463b05bf-eed5-485d-9a85-01108b08110c@Spark> Subject: FreeBSD 12.0 Current & hardware clock X-Readdle-Message-ID: 463b05bf-eed5-485d-9a85-01108b08110c@Spark MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 11:49:19 -0000 Hi, Im currently testing this image:=C2=A0=46reeBSD-armv6-12.0-RPI2-310476.im= g.gz =5B1=5D on my RBPI2. I need a hardware clock which will work with this image. Cou= ple of questions: 1. If I understood right I need to recompile the kernel since there is no= hardware clock support on the mentioned image =E2=80=A6 Right =3F 2. Is there support for Rasclock =5B2=5D based on=C2=A0NXP PC=462127AT ch= ipset =3F 3. Still there the regarding NTP and hardware clock when OS was dying on = such setup =3F (you need to enable=C2=A0sysctl machdep.rtc=5Fsave=5Fperiod=3D0= =C2=A0to=C2=A0workaround) Thanks, Stefan =5B1=5D http://www.raspbsd.org/raspberrypi.html =5B2=5D=C2=A0https://afterthoughtsoftware.com/products/rasclock From owner-freebsd-arm@freebsd.org Mon Apr 24 18:46:40 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8ED03D4D4F9 for ; Mon, 24 Apr 2017 18:46:40 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AC0E16E9 for ; Mon, 24 Apr 2017 18:46:40 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id u65so4510352wmu.1 for ; Mon, 24 Apr 2017 11:46:40 -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:content-transfer-encoding; bh=AAQ0Q2q7nsvxx/uxi7gilIaZzdDB9DkFNutWVv0SXlU=; b=UO/UqJLBwlmk1kq+6OukI+2iCO2Tv5GoSUg0dSCIY6xWEaSRG8hR1lFsxPLmWHUvlm cFhG8jnGZHjS/NAaX6SQKkIEA6mItVTq6IKf0Ejo4YlaXgjRWaxu/kS6lGwg4s+WdTy0 hQwF3VSjMn+f1ZjfkIKYTnDPZmtP0U2i316KFLghj4g/6thZ1rW8Cu2DLdZaqwzuOz4Y oB492OwM6aOeO3uqsAgZ1DQL6tKf1RPs68+/cDhvoUn/YvID/cslvUJ08y3aslCFUEhL W1Y+BFbfZakvQJXCj2KhORAJLdX44NhJx0fMxMEQ455fK+JEzrVDwS1mrfo52/F3rcVJ D9TQ== 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:content-transfer-encoding; bh=AAQ0Q2q7nsvxx/uxi7gilIaZzdDB9DkFNutWVv0SXlU=; b=JtGREz3e0t2ATQefYjqEiioWCasayn/D1xx/WdjyS2Itj6QtaqRl7+4II0BVnPGbSm Cr3PvWbkemh/L65arMHAh81p6p696/3u1bYApxyjWm18XSe2kp/rVmgwzdFe4RSGDLR2 YlkMC0MQRqTJAxqkxY4GyGwKIlVSrChiCINoRMTfmca79tgzmVIRFrZONjlMZFcVBaWg cUq/T8WFdguX0fZAkKPPWNAypZGYlw3CMs2L2kVwYYt6eoLsxOxPTXN1EBCx/Rvu010G zQ+TzBX9MEgdaknAYEnpmMl9hRN8Qwo5fBrWCmfbndeg7856Xn62OCmmwGD84xrNZm8p TgAA== X-Gm-Message-State: AN3rC/52lNP0bq01WgnJG4iVSjSH4rXfU4SmY2+bcsgSpSS7UoJbajk8 C2EGOpWec2sYms8Q5qiEry9pVoY5fw== X-Received: by 10.80.181.161 with SMTP id a30mr2144015ede.85.1493059598117; Mon, 24 Apr 2017 11:46:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.148.148 with HTTP; Mon, 24 Apr 2017 11:46:37 -0700 (PDT) In-Reply-To: <463b05bf-eed5-485d-9a85-01108b08110c@Spark> References: <463b05bf-eed5-485d-9a85-01108b08110c@Spark> From: Luiz Otavio O Souza Date: Mon, 24 Apr 2017 15:46:37 -0300 Message-ID: Subject: Re: FreeBSD 12.0 Current & hardware clock To: "kronometrix.org" Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:46:40 -0000 On 24 April 2017 at 08:31, kronometrix.org wrote: > Hi, > > Im currently testing this image: FreeBSD-armv6-12.0-RPI2-310476.img.gz [1= ] > on my RBPI2. I need a hardware clock which will work with this image. Cou= ple > of questions: > > 1. If I understood right I need to recompile the kernel since there is no= hardware > clock support on the mentioned image =E2=80=A6 Right ? Yes, you have to add your RTC device and rebuild the kernel. > > 2. Is there support for Rasclock [2] based on NXP PCF2127AT chipset ? No, we only have the driver for the pcf2123 (spi only RTC), but should not be hard to add support for it. > > 3. Still there the regarding NTP and hardware clock when OS was dying on = such > setup ? (you need to enable sysctl machdep.rtc_save_period=3D0 to workaro= und) Yes, or you can use the gpioiic/gpiospi which don't use interrupts (and will not cause any issues with NTP -> RTC time updates). Luiz From owner-freebsd-arm@freebsd.org Mon Apr 24 23:58:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3481FD4EE40 for ; Mon, 24 Apr 2017 23:58:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-25.reflexion.net [208.70.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3235B8F for ; Mon, 24 Apr 2017 23:58:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32544 invoked from network); 24 Apr 2017 23:32:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Apr 2017 23:32:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 24 Apr 2017 19:31:52 -0400 (EDT) Received: (qmail 11984 invoked from network); 24 Apr 2017 23:31:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Apr 2017 23:31:52 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 66F8FEC88B5; Mon, 24 Apr 2017 16:31:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: <7D72C3EF-8F77-4701-93C9-1488072215FC@dsl-only.net> Date: Mon, 24 Apr 2017 16:31:50 -0700 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <7BE9D35E-2F53-49B6-ADE0-60570D01892D@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> <585B43F7-D4C8-431A-BFFE-68B48C3214AE@dsl-only.net> <7D72C3EF-8F77-4701-93C9-1488072215FC@dsl-only.net> To: Jia-Shiun Li , freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 23:58:34 -0000 On 2017-Apr-19, at 10:28 AM, Mark Millard wrote: > On 2017-Apr-18, at 11:16 AM, Jia-Shiun Li wrote: > >> just noticed that rpi3 wiki page still has outdated issue info regarding >> this (the jemalloc error). Anyone to help update it? >> >> https://wiki.freebsd.org/arm64/rpi3 > > stable/11 is still in process for the fork handling fixes. > > One of the 2 fixes to fork behavior has just been MFC'd: > -r313772 from head is now -r317147 in stable/11 . So > interrupts will no longer trash the sp_el0 register. > > There is still -r316679 from head to go so that > Copy-On-Write would work for fork. (The defect > may be more general than just being for fork.) stable/11 -r317354 completes the fixes: Author: kib Date: Mon Apr 24 07:52:44 2017 New Revision: 317354 URL: https://svnweb.freebsd.org/changeset/base/317354 Log: MFC r316679: Do not lose dirty bits for removing PROT_WRITE on arm64. Modified: stable/11/sys/arm64/arm64/pmap.c Directory Properties: stable/11/ (props changed) . . . See: https://lists.freebsd.org/pipermail/svn-src-stable-11/2017-April/003041.html So now the old rpi3 wiki page material is only for masking some of the problems in older contexts for 12 or for older contexts for 11. [I've not been running 11, just 12.] === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Apr 25 01:42:27 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA368D4E3A6 for ; Tue, 25 Apr 2017 01:42:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-26.reflexion.net [208.70.210.26]) (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 AFB2E1EFE for ; Tue, 25 Apr 2017 01:42:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29315 invoked from network); 25 Apr 2017 01:45:35 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 01:45:35 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 24 Apr 2017 21:42:25 -0400 (EDT) Received: (qmail 8880 invoked from network); 25 Apr 2017 01:42:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 01:42:25 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C73A6EC88B5; Mon, 24 Apr 2017 18:42:24 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: Evidence of a source of irq 1023's (with last irq 27) Message-Id: Date: Mon, 24 Apr 2017 18:42:24 -0700 To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 01:42:28 -0000 Note: The same kernel used below but installed on a rpi3 (aarch64) does not report such spurious interrupts. The issue is somehow specific to the Pine64+'s or at least not general to all aarch64's. (I've access to a Pine64+ 2GB but Tom V. to a Pine64+ 1GB if I understand right. I do not know about other folks.) The initial pine64+ 2GB context had a powered hub with an SSD and had Ethernet plugged in. But unplugging everything but the serial console and applying power gets the same sort of thing, other than instead of 107 shown for the first "last irq" a 64 was shown instead. I made the following change in order to gather more evidence for the spurious interrupts that I and others have seen on Pine64+'s: FreeBSDx64# svnlite diff /usr/src/sys/arm/arm/gic.c Index: /usr/src/sys/arm/arm/gic.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/arm/gic.c (revision 317015) +++ /usr/src/sys/arm/arm/gic.c (working copy) @@ -672,9 +672,15 @@ =20 if (irq >=3D sc->nirqs) { #ifdef GIC_DEBUG_SPURIOUS +//#define EXPECTED_SPURIOUS_IRQ 1023 +// if (irq !=3D EXPECTED_SPURIOUS_IRQ) { device_printf(sc->gic_dev, - "Spurious interrupt detected: last irq: %d on = CPU%d\n", - sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); + "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n" + "0,1,2,3: last irqs: %d,%d,%d,%d\n", + irq, sc->nirqs, + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); +// } #endif return (FILTER_HANDLED); } @@ -720,6 +726,18 @@ if (irq < sc->nirqs) goto dispatch_irq; =20 +// if (irq !=3D EXPECTED_SPURIOUS_IRQ) { +//#undef EXPECTED_SPURIOUS_IRQ +#ifdef GIC_DEBUG_SPURIOUS + device_printf(sc->gic_dev, + "nextirq: Spurious interrupt %d detected of %d: last = irq: %d on CPU%d\n" + "0,1,2,3: last irqs: %d,%d,%d,%d\n", + irq, sc->nirqs, + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); +#endif +// } + return (FILTER_HANDLED); } The second block of code is in the "next_irq:" part of the code and has a "nextirq:" prefix text to make its messages unique. The console result from a boot attempt with this was as follows but first I will note one line from it showing the irq 27 binding: ehci0: mem 0x1c1a000-0x1c1a0ff = irq 27 on simplebus0 That 27 is involved in what is shown below. >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 3 block devices.....* done ZFS found no pools UFS found 1 partition Consoles: EFI console =20 Command line arguments: loader.efi Image base: 0xb8dc4000 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.1 EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x7ba128 data=3D0x9e6f8+0x39c3fe = syms=3D[0x8+0x103b60+0x8+0xf8a79] /boot/entropy size=3D0x1000 Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x49000000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT r317015M arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface kbd0 at kbdmux0 ofwbus0: aw_ccu0: on ofwbus0 clk_fixed0: on aw_ccu0 clk_fixed1: on aw_ccu0 aw_pll0: mem 0x1c20000-0x1c20003 on aw_ccu0 aw_pll1: mem 0x1c20028-0x1c2002b on aw_ccu0 clk_fixed2: on aw_ccu0 aw_pll2: mem 0x1c2002c-0x1c2002f on aw_ccu0 aw_cpuclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 aw_axiclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 aw_ahbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 aw_ahbclk1: mem 0x1c2005c-0x1c2005f on aw_ccu0 aw_apbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 aw_apbclk1: mem 0x1c20058-0x1c2005b on aw_ccu0 aw_gate0: mem 0x1c20060-0x1c20073 on = aw_ccu0 aw_modclk0: mem 0x1c20088-0x1c2008b on aw_ccu0 aw_modclk1: mem 0x1c2008c-0x1c2008f on aw_ccu0 aw_modclk2: mem 0x1c20090-0x1c20093 on aw_ccu0 aw_pll3: mem 0x1c20044-0x1c20047 on aw_ccu0 aw_usbclk0: mem 0x1c200cc-0x1c200cf on aw_ccu0 aw_thsclk0: mem 0x1c20074-0x1c20077 on aw_ccu0 simplebus0: on ofwbus0 aw_reset0: mem 0x1c202c0-0x1c202cb on = simplebus0 aw_reset1: mem 0x1c202d0-0x1c202d3 on = simplebus0 aw_reset2: mem 0x1c202d8-0x1c202db on = simplebus0 regfix0: on simplebus0 psci0: on ofwbus0 aw_sid0: mem 0x1c14000-0x1c143ff on = simplebus0 iichb0: mem 0x1f03400-0x1f037ff irq 24 on simplebus0 iicbus0: on iichb0 awusbphy0: mem = 0x1c19400-0x1c19423,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 0 on ofwbus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 gpio0: mem 0x1c20800-0x1c20bff irq = 8,9,10 on simplebus0 gpiobus0: on gpio0 aw_nmi0: mem 0x1f00c0c-0x1f00c43 irq 23 on = simplebus0 axp81x_pmu0: at addr 0x746 irq = 30 on iicbus0 gpiobus1: on axp81x_pmu0 generic_timer0: irq 1,2,3,4 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 rtc0: mem 0x1f00000-0x1f00053 irq 16,17 on simplebus0 cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 a10_mmc0: mem = 0x1c0f000-0x1c0ffff irq 5 on simplebus0 mmc0: on a10_mmc0 gpioc0: on gpio0 uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 11 on = simplebus0 uart0: console (115384,n,8,1) awg0: mem = 0x1c30000-0x1c300ff,0x1c00030-0x1c00033 irq 21 on simplebus0 miibus0: on awg0 rgephy0: PHY 0 on = miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow rgephy1: PHY 1 on = miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow awg0: Ethernet address: 02:ba:58:11:06:4e aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 22 on = simplebus0 gpioc1: on axp81x_pmu0 iic0: on iicbus0 aw_thermal0: mem = 0x1c25000-0x1c253ff irq 25 on simplebus0 ohci0: mem 0x1c1a400-0x1c1a4ff irq 26 on = simplebus0 usbus0 on ohci0 ehci0: mem 0x1c1a000-0x1c1a0ff = irq 27 on simplebus0 usbus1: EHCI version 1.0 usbus1 on ehci0 ohci1: mem 0x1c1b400-0x1c1b4ff irq 28 on = simplebus0 usbus2 on ohci1 ehci1: mem 0x1c1b000-0x1c1b0ff = irq 29 on simplebus0 usbus3: EHCI version 1.0 usbus3 on ehci1 cryptosoft0: gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 107 on = CPU0 0,1,2,3: last irqs: 107,0,0,0 Timecounters tick every 1.000 msec gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 . . . The messages just seem to be continuously generated. I ended up = unplugging the Pine64+ 2GB power. But they were all 27's expect for that first one being a 107 (or 64). So this starts before any of the other cores are started. I'll see if I can come up with a test showing later behavior. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Apr 25 04:06:14 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8EF9BD4FB55 for ; Tue, 25 Apr 2017 04:06:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-26.reflexion.net [208.70.210.26]) (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 546571F94 for ; Tue, 25 Apr 2017 04:06:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10684 invoked from network); 25 Apr 2017 04:06:12 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 04:06:12 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 00:06:12 -0400 (EDT) Received: (qmail 12350 invoked from network); 25 Apr 2017 04:06:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 04:06:12 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B3E98EC8552; Mon, 24 Apr 2017 21:06:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: Evidence of a source of irq 1023's (with last irq 27) From: Mark Millard In-Reply-To: Date: Mon, 24 Apr 2017 21:06:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 04:06:14 -0000 [I add more acquired information from generated messages this time, spanning a full boot and some later activity.] On 2017-Apr-24, at 6:42 PM, Mark Millard wrote: > Note: The same kernel used below but installed > on a rpi3 (aarch64) does not report such spurious > interrupts. The issue is somehow specific > to the Pine64+'s or at least not general > to all aarch64's. (I've access to a Pine64+ > 2GB but Tom V. to a Pine64+ 1GB if I understand > right. I do not know about other folks.) >=20 >=20 > The initial pine64+ 2GB context had a powered hub with > an SSD and had Ethernet plugged in. But unplugging > everything but the serial console and applying power > gets the same sort of thing, other than instead of > 107 shown for the first "last irq" a 64 was shown > instead. >=20 >=20 > I made the following change in order to gather > more evidence for the spurious interrupts that > I and others have seen on Pine64+'s: >=20 > FreeBSDx64# svnlite diff /usr/src/sys/arm/arm/gic.c > Index: /usr/src/sys/arm/arm/gic.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/arm/arm/gic.c (revision 317015) > +++ /usr/src/sys/arm/arm/gic.c (working copy) > @@ -672,9 +672,15 @@ >=20 > if (irq >=3D sc->nirqs) { > #ifdef GIC_DEBUG_SPURIOUS > +//#define EXPECTED_SPURIOUS_IRQ 1023 > +// if (irq !=3D EXPECTED_SPURIOUS_IRQ) { > device_printf(sc->gic_dev, > - "Spurious interrupt detected: last irq: %d on = CPU%d\n", > - sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); > + "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n" > + "0,1,2,3: last irqs: %d,%d,%d,%d\n", > + irq, sc->nirqs, > + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), > + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); > +// } > #endif > return (FILTER_HANDLED); > } > @@ -720,6 +726,18 @@ > if (irq < sc->nirqs) > goto dispatch_irq; >=20 > +// if (irq !=3D EXPECTED_SPURIOUS_IRQ) { > +//#undef EXPECTED_SPURIOUS_IRQ > +#ifdef GIC_DEBUG_SPURIOUS > + device_printf(sc->gic_dev, > + "nextirq: Spurious interrupt %d detected of %d: last = irq: %d on CPU%d\n" > + "0,1,2,3: last irqs: %d,%d,%d,%d\n", > + irq, sc->nirqs, > + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), > + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); > +#endif > +// } > + > return (FILTER_HANDLED); > } >=20 > The second block of code is in the "next_irq:" > part of the code and has a "nextirq:" prefix > text to make its messages unique. >=20 > The console result from a boot attempt with this > was as follows but first I will note one line from > it showing the irq 27 binding: >=20 > ehci0: mem = 0x1c1a000-0x1c1a0ff irq 27 on simplebus0 >=20 > That 27 is involved in what is shown below. >=20 >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > Initializing modules: ZFS UFS > Probing 3 block devices.....* done > ZFS found no pools > UFS found 1 partition > Consoles: EFI console =20 > Command line arguments: loader.efi > Image base: 0xb8dc4000 > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) >=20 > FreeBSD/arm64 EFI loader, Revision 1.1 > EFI boot environment > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=3D0x7ba128 data=3D0x9e6f8+0x39c3fe = syms=3D[0x8+0x103b60+0x8+0xf8a79] > /boot/entropy size=3D0x1000 >=20 > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by EFI at 0x49000000. > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2017 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT r317015M arm64 > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) > VT: init without driver. > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: unblocking device. > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > aw_ccu0: on ofwbus0 > clk_fixed0: on aw_ccu0 > clk_fixed1: on aw_ccu0 > aw_pll0: mem 0x1c20000-0x1c20003 on aw_ccu0 > aw_pll1: mem 0x1c20028-0x1c2002b on aw_ccu0 > clk_fixed2: on aw_ccu0 > aw_pll2: mem 0x1c2002c-0x1c2002f on aw_ccu0 > aw_cpuclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 > aw_axiclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 > aw_ahbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 > aw_ahbclk1: mem 0x1c2005c-0x1c2005f on aw_ccu0 > aw_apbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 > aw_apbclk1: mem 0x1c20058-0x1c2005b on aw_ccu0 > aw_gate0: mem 0x1c20060-0x1c20073 on = aw_ccu0 > aw_modclk0: mem 0x1c20088-0x1c2008b on = aw_ccu0 > aw_modclk1: mem 0x1c2008c-0x1c2008f on = aw_ccu0 > aw_modclk2: mem 0x1c20090-0x1c20093 on = aw_ccu0 > aw_pll3: mem 0x1c20044-0x1c20047 on aw_ccu0 > aw_usbclk0: mem 0x1c200cc-0x1c200cf on aw_ccu0 > aw_thsclk0: mem 0x1c20074-0x1c20077 on aw_ccu0 > simplebus0: on ofwbus0 > aw_reset0: mem 0x1c202c0-0x1c202cb on = simplebus0 > aw_reset1: mem 0x1c202d0-0x1c202d3 on = simplebus0 > aw_reset2: mem 0x1c202d8-0x1c202db on = simplebus0 > regfix0: on simplebus0 > psci0: on ofwbus0 > aw_sid0: mem 0x1c14000-0x1c143ff on = simplebus0 > iichb0: mem 0x1f03400-0x1f037ff irq 24 on simplebus0 > iicbus0: on iichb0 > awusbphy0: mem = 0x1c19400-0x1c19423,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 > gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 0 on ofwbus0 > gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 > gpio0: mem 0x1c20800-0x1c20bff irq = 8,9,10 on simplebus0 > gpiobus0: on gpio0 > aw_nmi0: mem 0x1f00c0c-0x1f00c43 irq 23 on = simplebus0 > axp81x_pmu0: at addr 0x746 irq = 30 on iicbus0 > gpiobus1: on axp81x_pmu0 > generic_timer0: irq 1,2,3,4 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > rtc0: mem 0x1f00000-0x1f00053 irq 16,17 on simplebus0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpufreq_dt0: on cpu0 > cpu1: on cpulist0 > cpu2: on cpulist0 > cpu3: on cpulist0 > a10_mmc0: mem = 0x1c0f000-0x1c0ffff irq 5 on simplebus0 > mmc0: on a10_mmc0 > gpioc0: on gpio0 > uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 11 on = simplebus0 > uart0: console (115384,n,8,1) > awg0: mem = 0x1c30000-0x1c300ff,0x1c00030-0x1c00033 irq 21 on simplebus0 > miibus0: on awg0 > rgephy0: PHY 0 on = miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow > rgephy1: PHY 1 on = miibus0 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow > awg0: Ethernet address: 02:ba:58:11:06:4e > aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 22 on = simplebus0 > gpioc1: on axp81x_pmu0 > iic0: on iicbus0 > aw_thermal0: mem = 0x1c25000-0x1c253ff irq 25 on simplebus0 > ohci0: mem 0x1c1a400-0x1c1a4ff irq 26 on = simplebus0 > usbus0 on ohci0 > ehci0: mem = 0x1c1a000-0x1c1a0ff irq 27 on simplebus0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > ohci1: mem 0x1c1b400-0x1c1b4ff irq 28 on = simplebus0 > usbus2 on ohci1 > ehci1: mem = 0x1c1b000-0x1c1b0ff irq 29 on simplebus0 > usbus3: EHCI version 1.0 > usbus3 on ehci1 > cryptosoft0: > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 107 = on CPU0 > 0,1,2,3: last irqs: 107,0,0,0 > Timecounters tick every 1.000 msec > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > . . . >=20 > The messages just seem to be continuously generated. I ended up = unplugging > the Pine64+ 2GB power. >=20 > But they were all 27's expect for that first one being a 107 (or 64). >=20 > So this starts before any of the other cores are started. >=20 >=20 > I'll see if I can come up with a test showing later behavior. I updated my change to avoid reporting the: nextirq: . . . last irq: 27 on CPU 0 messages. This allows the boot to progress in reasonable time and exposes more notices with other content. FreeBSDx64# svnlite diff /usr/src/sys/arm/arm/gic.c Index: /usr/src/sys/arm/arm/gic.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/arm/gic.c (revision 317015) +++ /usr/src/sys/arm/arm/gic.c (working copy) @@ -672,9 +672,15 @@ =20 if (irq >=3D sc->nirqs) { #ifdef GIC_DEBUG_SPURIOUS +#define EXPECTED_SPURIOUS_IRQ 1023 +// if (irq !=3D EXPECTED_SPURIOUS_IRQ) { device_printf(sc->gic_dev, - "Spurious interrupt detected: last irq: %d on = CPU%d\n", - sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); + "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n" + "0,1,2,3: last irqs: %d,%d,%d,%d\n", + irq, sc->nirqs, + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); +// } #endif return (FILTER_HANDLED); } @@ -720,6 +726,22 @@ if (irq < sc->nirqs) goto dispatch_irq; =20 + if ( irq !=3D EXPECTED_SPURIOUS_IRQ + || ( 0 =3D=3D PCPU_GET(cpuid) + && 27 !=3D sc->last_irq[0] + ) + ) { +#undef EXPECTED_SPURIOUS_IRQ +#ifdef GIC_DEBUG_SPURIOUS + device_printf(sc->gic_dev, + "nextirq: Spurious interrupt %d detected of %d: last = irq: %d on CPU%d\n" + "0,1,2,3: last irqs: %d,%d,%d,%d\n", + irq, sc->nirqs, + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); +#endif + } + return (FILTER_HANDLED); In this section I mix in comments at points of the sequence and I do not show every message but blocks of them. This example has the Ethernet plugged in and the powered USB HUB and its SSD in place. The SSD has the root file system that is booted. Initially for test test context: gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 107 on = CPU0 0,1,2,3: last irqs: 107,0,0,0 Timecounters tick every 1.000 msec usbus0: gic0: nextirq: Spurious interrupt 1023 detected of 224: last = irq: 92 on CPU0 0,1,2,3: last irqs: 92,0,0,0 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on = usbus0 ugen1.1: at usbus1 uhub1: on = usbus1 ugen2.1: at usbus2 uhub2: on = usbus2 ugen3.1: at usbus3 uhub3: on = usbus3 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 . . . Then later "last irq: 106"s start being involved: . . . gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 . . . Once multiple cores are running the "nextirq:" messages stop and transition to all being from the first message block in the updated code. At which point "last irq: 27 on CPU 0" can be and is reported again. First I show up to the first non"nextirq:" message. . . . . . gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number da0: 40.000MB/s transfers da0: 228936MB (468862128 512 byte sectors) da0: quirks=3D0x2 Release APs gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,27,27,27 CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <0> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 Trying to mount root from ufs:/dev/ufs/PINE642Grootfs [rw,noatime]... Setting hostuuid: a4f7fbeb-f668-11de-b280-ebb65474e619. Setting hostid: 0xcd8e9e25. Starting file system checks: /dev/ufs/PINE642Grootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/PINE642Grootfs: clean, 40252336 free (325480 frags, 4990857 = blocks, 0.7% fragmentation) Mounting local filesystems:gic0: nextirq: Spurious interrupt 1023 = detected of 224: last irq: 92 on CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 . ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib = /usr/local/lib/gcc6 /usr/local/lib/perl5/5.24/mach/CORE = /usr/local/llvm40/lib Setting hostname: pine64. Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATT= ACH,CACHED Feeding entropy: . awg0: link state changed to DOWN Starting dhclient. awg0: no link ......awg0: link state changed to UP got link Starting Network: lo0 awg0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 nd6 options=3D21 awg0: flags=3D8843 metric 0 mtu = 1500 options=3D8000b ether 02:ba:58:11:06:4e inet 192.168.1.103 netmask 0xffffff00 broadcast 192.168.1.255=20 media: Ethernet autoselect (1000baseT ) status: active nd6 options=3D29 Starting devd. add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Creating and/or trimming log files. Starting syslogd. Starting rpcbind. No core dumps found. NFS access cache time=3D60 Clearing /tmp (X related). NFSv4 is disabled Starting mountd. Starting nfsd. Updating motd:. Mounting late filesystems:. Starting ntpd. Starting powerd. And from here on no more "nextirq:" messages occur during the boot activity. . . gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 Performing sanity check on sshd configuration. gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 gic0: 0,1,2,3: last irqs: 27,27,27,106 Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 Starting sshd. gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,27 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,27 gic0: gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU3 Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,27,27,27 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU2 Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 0,1,2,3: last irqs: 27,27,27,106 gic0: gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU2 Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,114,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,114,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,114,27,106 . . . Eventually there is evidence of 114 (see above) and of 32 or such in the list of last irqs across the cores, for example: Starting background file system checks in 60 seconds. gic0: gic0: Spurious interrupt 1023 detected of 224: last irq: 32 on = CPU1 Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,32,27,27 0,1,2,3: last irqs: 27,32,27,27 . . . 114 and 32 are not as common. Eventually when sitting idle it quits generating messages. Then if I run openssl speed, possibly in parallel, it is not generating messages while busy, other than possibly some at the start. But something like find / -name test print does generate messages. For example: gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 . . . Only initially did it get 92's, but note that they are "nextirq:" messages again! The rest being 27's and 106's and being from the first message code instead of from the "nextirq:" message. Trying find looking at the mmcsd0 gets nearly all 92's with "nextirq:" messages, suggesting that it is tied to the microSD card I/O, much like 27 seems to be for USB. For now I stop with that. I've not figured out how to get any better/non-redundant information. I vaguely remember that I've once seen something that had a table with something about what irq's numbers were for what in some possibly analogous context. But I do not remember where I ran into such a document. (And may be it was not for the Pine64+ context.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Apr 25 05:03:17 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01185D4F635 for ; Tue, 25 Apr 2017 05:03:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-26.reflexion.net [208.70.210.26]) (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 A8E4310C7 for ; Tue, 25 Apr 2017 05:03:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32357 invoked from network); 25 Apr 2017 05:03:15 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 05:03:15 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 01:03:15 -0400 (EDT) Received: (qmail 8912 invoked from network); 25 Apr 2017 05:03:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 05:03:14 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 428DFEC88E9; Mon, 24 Apr 2017 22:03:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] From: Mark Millard In-Reply-To: Date: Mon, 24 Apr 2017 22:03:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> References: To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 05:03:17 -0000 I found some basic reference material for the "last irq" numbers for the A64 that is in the Pine64+ 2GB (and 1GB). . . IRQ 27: PPI 11 interrupt, vector 0x006C (I've no clue about this one beyond it being a "Private Peripheral Interrupt" example, somehow specific to each core separately.) The rest of the IRQs are "Shared Peripheral Interrupt"s. . . IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170 IRQ 106: USB-EHCI0 interrupt, vector 0x01A8 There were some: IRQ 114: EMAC interrupt, vector 0x01C8 IRQ 32: UART 0 interrupt, vector 0x0080 And the first "last irq:" for each boot was one of: IRQ 107: USB-OHCIO interrupt, vector 0x0A1C IRQ 64: External Non-Mask Interrupt, vector 0x0100 Neither 107 or 64 occurred again after the first message for a boot. 64 showed up when no USB device was plugged in; 107 showed when one was left plugged in (plugged in before powering on the Pine64+ 2GB). 1023 for the current irq number is special and not specific to the A64. So far I can not tell if the kernel mishandles the A64 in some way that leads to 1023's vs. if this is just what an A64 does for some odd reason, even with fully-correct software. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Apr 25 07:25:32 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A1B4D4F2F2 for ; Tue, 25 Apr 2017 07:25:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-25.reflexion.net [208.70.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DCABF1680 for ; Tue, 25 Apr 2017 07:25:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28059 invoked from network); 25 Apr 2017 07:28:39 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 07:28:39 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 03:25:29 -0400 (EDT) Received: (qmail 17239 invoked from network); 25 Apr 2017 07:25:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 07:25:29 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0692DEC856A; Tue, 25 Apr 2017 00:25:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] From: Mark Millard In-Reply-To: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> Date: Tue, 25 Apr 2017 00:25:28 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 07:25:32 -0000 On 2017-Apr-24, at 10:03 PM, Mark Millard wrote: > I found some basic reference material for the > "last irq" numbers for the A64 that is in the > Pine64+ 2GB (and 1GB). . . > > IRQ 27: PPI 11 interrupt, vector 0x006C > (I've no clue about this one beyond it being a > "Private Peripheral Interrupt" example, somehow > specific to each core separately.) Looks to be a timer, not that I can tell much about it: timer { compatible = "arm,armv8-timer"; interrupts = , , , ; }; But looking around I've seen references to needing IRQ_TYPE_NONE if the register is read-only, avoiding writes to read-only registers, --with such timers as examples (not necessarily A64 specific material though). > The rest of the IRQs are "Shared Peripheral > Interrupt"s. . . > > IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170 > > IRQ 106: USB-EHCI0 interrupt, vector 0x01A8 > > > There were some: > > IRQ 114: EMAC interrupt, vector 0x01C8 > IRQ 32: UART 0 interrupt, vector 0x0080 > > And the first "last irq:" for each boot was > one of: > > IRQ 107: USB-OHCIO interrupt, vector 0x0A1C > IRQ 64: External Non-Mask Interrupt, vector 0x0100 > > Neither 107 or 64 occurred again after the first > message for a boot. 64 showed up when no USB device > was plugged in; 107 showed when one was left plugged > in (plugged in before powering on the Pine64+ 2GB). > > 1023 for the current irq number is special > and not specific to the A64. > > > So far I can not tell if the kernel mishandles the > A64 in some way that leads to 1023's vs. if this > is just what an A64 does for some odd reason, even > with fully-correct software. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Apr 25 09:55:44 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 129B5D4F4C5 for ; Tue, 25 Apr 2017 09:55:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-25.reflexion.net [208.70.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C920F1FA for ; Tue, 25 Apr 2017 09:55:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2901 invoked from network); 25 Apr 2017 09:55:42 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 09:55:42 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 05:55:42 -0400 (EDT) Received: (qmail 5287 invoked from network); 25 Apr 2017 09:55:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 09:55:41 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2D235EC8552; Tue, 25 Apr 2017 02:55:41 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] Date: Tue, 25 Apr 2017 02:55:40 -0700 References: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org In-Reply-To: Message-Id: <62AF263E-8028-44AB-8AFA-B5F08C96673D@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 09:55:44 -0000 On 2017-Apr-25, at 12:25 AM, Mark Millard = wrote: > On 2017-Apr-24, at 10:03 PM, Mark Millard = wrote: >=20 >> I found some basic reference material for the=20 >> "last irq" numbers for the A64 that is in the >> Pine64+ 2GB (and 1GB). . . >>=20 >> IRQ 27: PPI 11 interrupt, vector 0x006C >> (I've no clue about this one beyond it being a >> "Private Peripheral Interrupt" example, somehow >> specific to each core separately.) >=20 > Looks to be a timer, not that I can tell > much about it: >=20 > timer { > compatible =3D "arm,armv8-timer"; > interrupts =3D (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>; > }; >=20 > But looking around I've seen references to needing IRQ_TYPE_NONE > if the register is read-only, avoiding writes to read-only > registers, --with such timers as examples (not necessarily > A64 specific material though). Looking around more the read-only status seems to be an implementation defined area for PPI's. But I have other notes later below on what appears to me to be a mismatch between _HIGH vs. _LOW use and what arm_gic_architecture_specification_v2.0.pdf says. >> The rest of the IRQs are "Shared Peripheral >> Interrupt"s. . . >>=20 >> IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170 >>=20 >> IRQ 106: USB-EHCI0 interrupt, vector 0x01A8 >>=20 >>=20 >> There were some: >>=20 >> IRQ 114: EMAC interrupt, vector 0x01C8 >> IRQ 32: UART 0 interrupt, vector 0x0080 >>=20 >> And the first "last irq:" for each boot was >> one of: >>=20 >> IRQ 107: USB-OHCIO interrupt, vector 0x0A1C >> IRQ 64: External Non-Mask Interrupt, vector 0x0100 >>=20 >> Neither 107 or 64 occurred again after the first >> message for a boot. 64 showed up when no USB device >> was plugged in; 107 showed when one was left plugged >> in (plugged in before powering on the Pine64+ 2GB). >>=20 >> 1023 for the current irq number is special >> and not specific to the A64. >>=20 >>=20 >> So far I can not tell if the kernel mishandles the >> A64 in some way that leads to 1023's vs. if this >> is just what an A64 does for some odd reason, even >> with fully-correct software. Looking around I see in sys/arm/arm/gic_common.h : #define GICD_ICFGR(n) (0x0C00 + (((n) >> 4) * 4)) /* v1 = ICDICFR */ #define GICD_I_PER_ICFGRn 16 /* First bit is a polarity bit (0 - low, 1 - high) */ #define GICD_ICFGR_POL_LOW (0 << 0) #define GICD_ICFGR_POL_HIGH (1 << 0) #define GICD_ICFGR_POL_MASK 0x1 /* Second bit is a trigger bit (0 - level, 1 - edge) */ #define GICD_ICFGR_TRIG_LVL (0 << 1) #define GICD_ICFGR_TRIG_EDGE (1 << 1) #define GICD_ICFGR_TRIG_MASK 0x2 But Pine64+ is based on (from what I read): arm_gic_architecture_specification_v2.0.pdf and that does not match for the "polarity" part of GICD_ICFGR code in the above. Quoting (for both bits, focused on PPI to some extent but some material applies to SPIs as well). . . For each supported PPI, it is IMPLEMENTATION DEFINED whether software can program the corresponding Int_config field. [2F+1:2F] Int_config, field F For Int_config[1], the most significant bit, bit [2F+1], the encoding = is: =E2=80=A2 0 Corresponding interrupt is level-sensitive. =E2=80=A2 1 Corresponding interrupt is edge-triggered. Int_config[0], the least significant bit, bit [2F], is reserved, but see Table 4-19 for the encoding of this bit on some early implementations of this GIC architecture. [so reserved instead of polarity in general] For SGIs: Int_config[1] Not programmable, RAO/WI. [So 1's fit with SGIs for Int_config[1].] For PPIs and SPIs: Int_config[1] For SPIs, this bit is programmable.a For PPIs it is = IMPLEMENTATION DEFINED whether this bit is programmable. A read of this bit always returns the = correct value to indicate whether the corresponding interrupt is level-sensitive or = edge-triggered. [But SGIs and PPIs are not the same for Int_config[1].] As for what reserved bits are intended to be, quoting more places. . . Bit positions described as Reserved are UNK/SBZP. UNK/SBZP UNKNOWN on reads, Should-Be-Zero-or-Preserved on writes. In any implementation, the bit must read as 0, or all 0s for a bit = field, and writes to the field must be ignored. Software must not rely on the = field reading as 0, or all 0s for a bit field, and must use an SBZP policy to write to the field. [The Int_config[1] wording overrides the read part of the above.] So it would appear that use of IRQ_TYPE_LEVEL_HIGH is a violation of the intent for PPI's by it translating to include use of GICD_ICFGR_POL_HIGH which uses 1 instead of 0 for the reserved bit. [As for those "early" implementations. . .] On a GIC where the handling mode of peripheral interrupts is = configurable, the encoding of Int_config[0] for PPIs and SPIs, is: =E2=80=A2 0 Corresponding interrupt is handled using the N-N = model. =E2=80=A2 1 Corresponding interrupt is handled using the 1-N = model. [which I do not think applies to the A64, instead the N-N model applies to PPIs and the 1-N model to SPIs with no control to do otherwise. But it is very different from a high vs. low polarity when it does apply.] Quoting another place. . . In a multiprocessor implementation, if bit[1] of the Int_config field for any PPI is programmable then GICD_ICFGR1 is banked for each connected processor. This register holds the Int_config fields for the PPIs, interrupts 16-31. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Apr 25 21:58:18 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46458D50DD8 for ; Tue, 25 Apr 2017 21:58:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 E83FC12B1 for ; Tue, 25 Apr 2017 21:58:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32527 invoked from network); 25 Apr 2017 21:52:42 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 21:52:42 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 17:51:36 -0400 (EDT) Received: (qmail 5846 invoked from network); 25 Apr 2017 21:51:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 21:51:36 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E1AAFEC8714; Tue, 25 Apr 2017 14:51:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] From: Mark Millard In-Reply-To: Date: Tue, 25 Apr 2017 14:51:35 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:58:18 -0000 On 2017-Apr-25, at 12:25 AM, Mark Millard wrote: > On 2017-Apr-24, at 10:03 PM, Mark Millard wrote: > >> I found some basic reference material for the >> "last irq" numbers for the A64 that is in the >> Pine64+ 2GB (and 1GB). . . >> >> IRQ 27: PPI 11 interrupt, vector 0x006C >> (I've no clue about this one beyond it being a >> "Private Peripheral Interrupt" example, somehow >> specific to each core separately.) > > Looks to be a timer, not that I can tell > much about it: > > timer { > compatible = "arm,armv8-timer"; > interrupts = (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>; > }; > > But looking around I've seen references to needing IRQ_TYPE_NONE > if the register is read-only, avoiding writes to read-only > registers, --with such timers as examples (not necessarily > A64 specific material though). > >> The rest of the IRQs are "Shared Peripheral >> Interrupt"s. . . >> >> IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170 >> >> IRQ 106: USB-EHCI0 interrupt, vector 0x01A8 >> >> >> There were some: >> >> IRQ 114: EMAC interrupt, vector 0x01C8 >> IRQ 32: UART 0 interrupt, vector 0x0080 >> >> And the first "last irq:" for each boot was >> one of: >> >> IRQ 107: USB-OHCIO interrupt, vector 0x0A1C >> IRQ 64: External Non-Mask Interrupt, vector 0x0100 >> >> Neither 107 or 64 occurred again after the first >> message for a boot. 64 showed up when no USB device >> was plugged in; 107 showed when one was left plugged >> in (plugged in before powering on the Pine64+ 2GB). >> >> 1023 for the current irq number is special >> and not specific to the A64. >> >> >> So far I can not tell if the kernel mishandles the >> A64 in some way that leads to 1023's vs. if this >> is just what an A64 does for some odd reason, even >> with fully-correct software. When arm_gic_intr(.) jumps to "next_irq:" and finds that there is no next interrupt that is indicated by gic_c_read_4 of GICC_IAR returning 1023 according to arm_gic_architecture_specification_v2.0.pdf . So all the "nextirq:" messages that are in what I reported are as-expected. It is the messages that do not say "nextirq:" that are in question, the ones were the first gic_c_read_4 for GICC_IAR returns 1023 up front for some reason. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Apr 26 04:37:04 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18AC9D51456 for ; Wed, 26 Apr 2017 04:37:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 D3A70B54 for ; Wed, 26 Apr 2017 04:37:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18749 invoked from network); 26 Apr 2017 04:30:22 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Apr 2017 04:30:22 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 26 Apr 2017 00:30:22 -0400 (EDT) Received: (qmail 23247 invoked from network); 26 Apr 2017 04:30:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Apr 2017 04:30:21 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1ACD8EC7B46; Tue, 25 Apr 2017 21:30:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] From: Mark Millard In-Reply-To: Date: Tue, 25 Apr 2017 21:30:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23D019EB-DF40-45FD-A981-50CED7EC3ABA@dsl-only.net> References: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 04:37:04 -0000 On 2017-Apr-25, at 2:51 PM, Mark Millard wrote: > On 2017-Apr-25, at 12:25 AM, Mark Millard = wrote: >=20 >> On 2017-Apr-24, at 10:03 PM, Mark Millard = wrote: >>=20 >>> I found some basic reference material for the=20 >>> "last irq" numbers for the A64 that is in the >>> Pine64+ 2GB (and 1GB). . . >>>=20 >>> IRQ 27: PPI 11 interrupt, vector 0x006C >>> (I've no clue about this one beyond it being a >>> "Private Peripheral Interrupt" example, somehow >>> specific to each core separately.) >>=20 >> Looks to be a timer, not that I can tell >> much about it: >>=20 >> timer { >> compatible =3D "arm,armv8-timer"; >> interrupts =3D > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, >> > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, >> > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, >> > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>; >> }; >>=20 >> But looking around I've seen references to needing IRQ_TYPE_NONE >> if the register is read-only, avoiding writes to read-only >> registers, --with such timers as examples (not necessarily >> A64 specific material though). _HIGH is an incorrect description for A64's gic. Allwinner_A64_User_Manual_V1.0.pdf explicitly says, quoting: 3.12. GIC For details about GIC, please refer to the GIC PL400 technical reference manual and ARM GIC Architecture Specification V2.0. DDI0471B_gic400_r0p1_trm.pdf is explicit about the actual type of signal, quoting: 2.3.2 PPIs A PPI is an interrupt that is specific to a single processor. All PPI signals are active-LOW level-sensitive. arm_gic_architecture_specification_v2.0.pdf is not as specific. DDI0471B_gic400_r0p1_trm.pdf does describe what irq 27 (so PPI 11) is specifically. It also mentions that GICD) ICFGRn's even bits (Int_config[0]'s) are implemented but are always read-only, provided only for legacy software. But when I looked around more it looked like there was explicit code structure that ignored various details and forced other settings so that the _HIGH status was actually not used. >>> The rest of the IRQs are "Shared Peripheral >>> Interrupt"s. . . >>>=20 >>> IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170 >>>=20 >>> IRQ 106: USB-EHCI0 interrupt, vector 0x01A8 >>>=20 >>>=20 >>> There were some: >>>=20 >>> IRQ 114: EMAC interrupt, vector 0x01C8 >>> IRQ 32: UART 0 interrupt, vector 0x0080 >>>=20 >>> And the first "last irq:" for each boot was >>> one of: >>>=20 >>> IRQ 107: USB-OHCIO interrupt, vector 0x0A1C >>> IRQ 64: External Non-Mask Interrupt, vector 0x0100 >>>=20 >>> Neither 107 or 64 occurred again after the first >>> message for a boot. 64 showed up when no USB device >>> was plugged in; 107 showed when one was left plugged >>> in (plugged in before powering on the Pine64+ 2GB). >>>=20 >>> 1023 for the current irq number is special >>> and not specific to the A64. >>>=20 >>>=20 >>> So far I can not tell if the kernel mishandles the >>> A64 in some way that leads to 1023's vs. if this >>> is just what an A64 does for some odd reason, even >>> with fully-correct software. >=20 > When arm_gic_intr(.) jumps to "next_irq:" and finds that > there is no next interrupt that is indicated by > gic_c_read_4 of GICC_IAR returning 1023 according to > arm_gic_architecture_specification_v2.0.pdf . >=20 > So all the "nextirq:" messages that are in what I > reported are as-expected. >=20 > It is the messages that do not say "nextirq:" that are > in question, the ones were the first gic_c_read_4 for > GICC_IAR returns 1023 up front for some reason. All my testing has only found the A64's gic architecture's 1023 irq as the irq for everything the code classifies as spurious, everything that is "too large to be one of the used irq's". I find no evidence of any such generation other than automatic 1023's from the gic. arm_gic_intr handles the 1023's appropriately from what I read. No 1023 should be a problem. I've not found anything saying that the 1023's should not be generated by the gic, it appears optional for various ones being generated that are seen in the first read of GICC_IAR. Other gics might not. (I've not checked the gic status in an rpi3 but an rpi3 with the same kernel does not generate these 1023's seen on Pine64+ 2GB and 1GB boxes --and possibly other A64 boxes.) It appears that something like: # svnlite diff /usr/src/sys/arm/arm/gic.h = = Index: = /usr/src/sys/arm/arm/gic.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/arm/gic.h (revision 317015) +++ /usr/src/sys/arm/arm/gic.h (working copy) @@ -39,7 +39,7 @@ #ifndef _ARM_GIC_H_ #define _ARM_GIC_H_ =20 -#define GIC_DEBUG_SPURIOUS +//#define GIC_DEBUG_SPURIOUS =20 #define GIC_FIRST_SGI 0 /* Irqs 0-15 are = SGIs/IPIs. */ #define GIC_LAST_SGI 15 would be more appropriate for at least the Pine64+ 2GB and 1GB so that the debug messages do not mess up use of the console (and cause extra activity and its consequences). This might help other A64's too. The GIC_DEBUG_SPURIOUS goes back to gic.c in head -r291424 from 2015-Nov 28 (UTC). While it moved to gic.h it seem to have stayed enabled since it was added. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Apr 26 04:59:39 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D24AAD51811 for ; Wed, 26 Apr 2017 04:59:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 7AD8E3CE for ; Wed, 26 Apr 2017 04:59:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3652 invoked from network); 26 Apr 2017 05:00:44 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 26 Apr 2017 05:00:44 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 26 Apr 2017 00:59:38 -0400 (EDT) Received: (qmail 4057 invoked from network); 26 Apr 2017 04:59:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Apr 2017 04:59:38 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 85028EC7B46; Tue, 25 Apr 2017 21:59:37 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Should sys/arm/arm/gic.h 's GIC_DEBUG_SPURIOUS be disabled? It would help Pine64+ 2GB and 1GB console use --and possibly other A64's Message-Id: <446204CA-0347-49FE-9EDC-24F4F273A0A3@dsl-only.net> Date: Tue, 25 Apr 2017 21:59:36 -0700 To: mmel@FreeBSD.org, freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 04:59:39 -0000 This note is prompted by problems using the console on Pine64+ 2GB 's when it is busy. (And 1GB 's as reported by Tom V.) There are extensive messages about spurious interrupts. The following notes are written from the view of the A64's documented gic-400. All my testing has only found the A64's gic architecture's 1023 irq as the irq for everything the code classifies as spurious, everything that is "too large to be one of the used irq's" turns out to be the 1023 value. I find no evidence of any such generation of large irq's other than automatic 1023's generated by the gic itself. arm_gic_intr handles the 1023's appropriately from what I read. No 1023 should be a problem. I've not found anything saying that the 1023's should not be generated by the gic, it appears optional for various ones being generated that are seen in the first read of GICC_IAR for a core. Other gics might not. (I've not checked the gic status in an rpi3 but an rpi3 with the same kernel does not generate the spurious interrupt messages.) The "next_irq:" code should get a 1023 when no more interrupts are available for the core for an ARM64 and its gic --and it does. It appears that something like: # svnlite diff /usr/src/sys/arm/arm/gic.h = = Index: = /usr/src/sys/arm/arm/gic.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/arm/gic.h (revision 317015) +++ /usr/src/sys/arm/arm/gic.h (working copy) @@ -39,7 +39,7 @@ #ifndef _ARM_GIC_H_ #define _ARM_GIC_H_ =20 -#define GIC_DEBUG_SPURIOUS +//#define GIC_DEBUG_SPURIOUS =20 #define GIC_FIRST_SGI 0 /* Irqs 0-15 are = SGIs/IPIs. */ #define GIC_LAST_SGI 15 would be more appropriate for at least the Pine64+ 2GB and 1GB so that the debug messages do not mess up use of the console (and cause the extra activity and its consequences). This might help other A64's too. The same sort of thing goes for stable/11's sys/arm/arm/gic.c that still has the older code structure but with GIC_DEBUG_SPURIOUS defined and used to cause the messages. The GIC_DEBUG_SPURIOUS goes back to gic.c in head -r291424 from 2015-Nov 28 (UTC) via mmel. While GIC_DEBUG_SPURIOUS moved to gic.h it seem to have stayed enabled since it was added. Note: In my testing I temporarily made variations of the messages that reported more. I found nothing I could point to as suggesting an error. It all seemed fine because of the 1023 status and the code's handling that that. [Some --but far form all-- this activity is visible in a different sequence of list submittals. The above is the overall conclusion of my investigation. The other messages clearly show my learning-as-I-go status for this.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Apr 26 10:13:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EAFDD4C2DA for ; Wed, 26 Apr 2017 10:13:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 48AA4157 for ; Wed, 26 Apr 2017 10:13:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14751 invoked from network); 26 Apr 2017 10:14:05 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 26 Apr 2017 10:14:05 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 26 Apr 2017 06:12:58 -0400 (EDT) Received: (qmail 5090 invoked from network); 26 Apr 2017 10:12:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Apr 2017 10:12:58 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id DEFD4EC7B46; Wed, 26 Apr 2017 03:12:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FreeBSD status for/on ODroid-C2? From: Mark Millard In-Reply-To: Date: Wed, 26 Apr 2017 03:12:57 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <61985953-493F-432C-888E-3F4A06BBCA38@dsl-only.net> To: Tom Vijlbrief X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 10:13:01 -0000 On 2016-Oct-2, at 7:17 AM, Tom Vijlbrief = wrote: > No change (at least in my tree) since my last report on this list = somewhere in May or June. >=20 > The kernel boots with 4 cpus and working usb. I use an usb ethernet = device and usb disk with the root filesysteem. Compiling and running = ports works, but a build world fails randomly with a memory access error = eg after running 15 minutes. Modern head (12) should no longer have the (same?) buildworld problems now that head and stable/11 both have the 2 fixes that fix the fork behavior (avoiding trashing a special register and copy-on-write now working). It would be interesting to see how things go now if you rebuilt the Odroid-C2 based on modern head (12). > I don't think it makes sense to work on this until a freebsd rpi3 = arm64 port is officially supported... FreeBSD for Odroid-C2 may go easier now that the fork problems are addressed. Both Pine64+ 2GB and rpi3 are now well behaved for buildworld. They were not before. > Op zo 2 okt. 2016 15:04 schreef Mark Millard : > [Context switching to ODroid-C2 from Pine64. . .] >=20 > On 2016-Oct-2, at 12:19 AM, Tom Vijlbrief = wrote: >=20 > > I have a script which creates a bootable image: > > > > https://github.com/tomtor/image-freebsd-pine64 > > > > You can use the boot version from the Ubuntu image and change = uEnv.txt and > > create an additional partition which holds the kernel image. So you = skip > > ubldr. > > > > Note that the kernel boots, but I got none of the hardware devices = working > > (I spend more time on the Odroid-C2) and haven't been working on it = the > > last months... >=20 > Anything worth reporting on the ODroid-C2 details for FreeBSD: what = works, what does not, what needs to be done to boot FreeBSD, and so on? = (I assume head [CURRENT-12 these days].) >=20 >=20 > Looking around. . . >=20 >=20 > https://github.com/tomtor/image-freebsd-c2 >=20 > seems to have last been updated on May 7 (vs. = https://github.com/tomtor/image-freebsd-pine64 's April 17). >=20 >=20 > https://github.com/tomtor/freebsd/tree/tc2 >=20 > seems to have last been updated on June 17. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Apr 26 11:10:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A75A1D50BA8 for ; Wed, 26 Apr 2017 11:10:11 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65BF7FDD for ; Wed, 26 Apr 2017 11:10:11 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-yb0-x22c.google.com with SMTP id 11so545740yby.0 for ; Wed, 26 Apr 2017 04:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=meD7NDoft7oiCUWunahvAmzclcNNBVJzA/TpSGAo1Ao=; b=NzMa1FYNuPkZ+ePnX1a9diCt+2jfk0xZ9TxdnXAo8M3pOtiuPuQ5XmFAVEr6uPYeLk YtfE4blGK/3JhNnFoG85v2FT1bYBV1Y4eYnubPp6XS6aHW3VOrM7Pdjyj6FZ/0+SV6uj gwYX7UOc1lLyqZVLxpc/hiJUDqMzBSxtc0I7zW67nGDM/m7wGbppISCZXd2U9h8h7IBK FzokkFQjQrNFPPnQ68e9QC8HpxId/5lvj7nE5WtExbq0rzxK/3XltE32Hyj8SzwN+0LG 5IGOZPmalKj0opw3Q4vC/XqFt3uT+ho16rl/PloOPT6YUeJzk0LJVK0GPr6jjO3nSoPQ vIaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=meD7NDoft7oiCUWunahvAmzclcNNBVJzA/TpSGAo1Ao=; b=pDXLerjxSg3sdIPA0cJFtGMrCY1DHckr4anP5kKQZK4ootOSystXutfyQjLN0WGxkl DE7wSO6bFP+03t8r03E4/q3BrpQyczvrsR/rLO/ctK8nkYSKV0xFkZifZ4O6WMKfoheo aHJ+NgSXbqP3P0Bz/HMCVl4a4LfYnhE++lMdOqaj9Ozf6ztHgM1dmCe2jaLEV1W4zlDH TFSMPvDawYSWbD/aMS/mcBhbdYtoRXaJteOw3fmr4aFpD2u0Wa1Yh8Ypw6a75FSyg/ij wRf7Z/I7fz2JpcMnDG3r6xqOPhyr6yu9E1ZA6d8u9InwVr276KHZkV6BqSSUFoqHDNdx Ff9w== X-Gm-Message-State: AN3rC/4zpN5UC7O4tyvust8aOprEzsv+lLpW3ekjbzspMlRaWtCljEwo fjIdQjgGuj40/KD3wyvrE7Trc3NZAEB2 X-Received: by 10.37.176.1 with SMTP id q1mr12658944ybf.26.1493205010372; Wed, 26 Apr 2017 04:10:10 -0700 (PDT) MIME-Version: 1.0 References: <61985953-493F-432C-888E-3F4A06BBCA38@dsl-only.net> In-Reply-To: From: Tom Vijlbrief Date: Wed, 26 Apr 2017 11:09:59 +0000 Message-ID: Subject: Re: FreeBSD status for/on ODroid-C2? To: Mark Millard Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 11:10:11 -0000 I am pretty sure the Odroid-C2 wil run stable with the recent fork fixes, but I reallocated my Odroid-C2 to a non-freebsd purpose, so I cannot test this. Note that the ethernet and SD-card are still non functional, which makes the Odroid-2 not really usable with FreeBSD, in it's current state. I had to boot the kernel over the network with U-Boot and use an USB Ethernet adapter and file system on USB-disk... The Odroid-C2 is still a nice piece of hardware for an energy efficient small (FreeBSD) server. The CPU runs at 1.5Ghz because it uses a more modern production process than the RPI3 or Pine and it has a standard cooling element mounted on the chips. It is also very compact compared to the Pine. Op wo 26 apr. 2017 om 12:12 schreef Mark Millard : > On 2016-Oct-2, at 7:17 AM, Tom Vijlbrief wrote: > > > No change (at least in my tree) since my last report on this list > somewhere in May or June. > > > > The kernel boots with 4 cpus and working usb. I use an usb ethernet > device and usb disk with the root filesysteem. Compiling and running ports > works, but a build world fails randomly with a memory access error eg after > running 15 minutes. > > Modern head (12) should no longer have the (same?) > buildworld problems now that head and stable/11 > both have the 2 fixes that fix the fork behavior > (avoiding trashing a special register and > copy-on-write now working). > > It would be interesting to see how things go now > if you rebuilt the Odroid-C2 based on modern head > (12). > > > I don't think it makes sense to work on this until a freebsd rpi3 arm64 > port is officially supported... > > FreeBSD for Odroid-C2 may go easier now that the > fork problems are addressed. > > Both Pine64+ 2GB and rpi3 are now well behaved for > buildworld. They were not before. > > > Op zo 2 okt. 2016 15:04 schreef Mark Millard : > > [Context switching to ODroid-C2 from Pine64. . .] > > > > On 2016-Oct-2, at 12:19 AM, Tom Vijlbrief > wrote: > > > > > I have a script which creates a bootable image: > > > > > > https://github.com/tomtor/image-freebsd-pine64 > > > > > > You can use the boot version from the Ubuntu image and change uEnv.txt > and > > > create an additional partition which holds the kernel image. So you > skip > > > ubldr. > > > > > > Note that the kernel boots, but I got none of the hardware devices > working > > > (I spend more time on the Odroid-C2) and haven't been working on it the > > > last months... > > > > Anything worth reporting on the ODroid-C2 details for FreeBSD: what > works, what does not, what needs to be done to boot FreeBSD, and so on? (I > assume head [CURRENT-12 these days].) > > > > > > Looking around. . . > > > > > > https://github.com/tomtor/image-freebsd-c2 > > > > seems to have last been updated on May 7 (vs. > https://github.com/tomtor/image-freebsd-pine64 's April 17). > > > > > > https://github.com/tomtor/freebsd/tree/tc2 > > > > seems to have last been updated on June 17. > > === > Mark Millard > markmi at dsl-only.net > > > From owner-freebsd-arm@freebsd.org Wed Apr 26 11:10:46 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD0E4D50C21 for ; Wed, 26 Apr 2017 11:10:46 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 435C41184 for ; Wed, 26 Apr 2017 11:10:45 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MbsV8-1dMewW2rZ8-00JJtv; Wed, 26 Apr 2017 13:10:34 +0200 Date: Wed, 26 Apr 2017 13:10:27 +0200 From: "O. Hartmann" To: Mark Millard Cc: freebsd-arm Subject: Re: FreeBSD status for/on ODroid-C2? Message-ID: <20170426131014.03207043@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <61985953-493F-432C-888E-3F4A06BBCA38@dsl-only.net> Organization: Walstatt X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:R365LkXehN8ldyj9VKUiNVJ1B09N3WfUdk8EMhv4DbYLZN38IXC g7wWnMIJRQRj++/iACj9GelUdXsjy6gndnUWrYMLdppG+RsTrOwHsJg/DhjyBX9tDxixGVq 0aNcUvBsSfkY12w7OnVGC8qQeK3FS743mdYT7J4H0cuGuJzmrCaFmMG9/g+r9teUFTqipvm 7+Id8TlnWIvSJQJniZKXQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:fApMirDL3SY=:4MBX4a3XzTxusuLBODyJ9h pcYfGnDPjgJEembjN53zk/K5PHVhvWu4CEW82tp1yOf90LcMf+mdFYHReD4gaZ5MFXJNhtHr6 ucfkJWEqNliyMXicObPLDEG0iKAp6mdydLJNHNNECFjFw3euc/JIVbRAgnAJaXRZh42hxJXzM M/RICEgnT2e6LP2bPq+b72HDveoOm9rHHdF4rMULoxGSEeBOFRE/VhRCjNP0AcFBshKOR9qcU lJHK3eq3RiQUOOpmeBkdNqb3JORn323DvWs0hiaLlMcMuvHGLxP3yPZbGsxllFUa69axozYDY EDgoZQufI1EgBW1XTKHcLCfZ+DvaK5bk4ziAUUpD/xCyBcMuww1sKwv2UU/ESp/R8E/e31muf vO5rWEbSt1ZqEeCYEoDF92lBbXWpikHObRrmont1PIz9lDKfrEs6DsreBTAmxR9ZkwlA3Ul5R dM6ZCbF0lb+5pTluHBWuxhtu98jNEk9+3qX/mYiSSQ5wKKLEhw2/aD1jaqW0oMUj4dKKIgWzh UJdmDwn+7l1abSnFl2lyo/LhoHAU6lfrC8FolMzSoG+GOMI3Aw4lzoMZn7GdW+k55W3roJblN uquw+0jC5WRsVV5CHV0rKiX4/iqry8Mm8wgOUJqhi2uUENE0qgZnOY+leHezg8IXPk3P7LxkM tpQYsQM1/7KMmwqUene7lUrTWEgTv3SFCf98jl1I3uSFw57INpGvPZ6AsDa27SzcQyKpNyysX k7zJqCOhUwRP9Hi8uXzKga7OdthvM1MUaupTVoM6kGERmO2mdPT8ax4iL15pMW90c5eKdi0/a n5jVP95 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 11:10:46 -0000 On Wed, 26 Apr 2017 03:12:57 -0700 Mark Millard wrote: > On 2016-Oct-2, at 7:17 AM, Tom Vijlbrief wrote: > > > No change (at least in my tree) since my last report on this list somewhere > > in May or June. > > > > The kernel boots with 4 cpus and working usb. I use an usb ethernet device > > and usb disk with the root filesysteem. Compiling and running ports works, > > but a build world fails randomly with a memory access error eg after > > running 15 minutes. > > Modern head (12) should no longer have the (same?) > buildworld problems now that head and stable/11 > both have the 2 fixes that fix the fork behavior > (avoiding trashing a special register and > copy-on-write now working). > > It would be interesting to see how things go now > if you rebuilt the Odroid-C2 based on modern head > (12). > > > I don't think it makes sense to work on this until a freebsd rpi3 arm64 > > port is officially supported... > > FreeBSD for Odroid-C2 may go easier now that the > fork problems are addressed. > > Both Pine64+ 2GB and rpi3 are now well behaved for > buildworld. They were not before. Ah, thank you very much. As soon I get into howto create a bootable image, I'll try. I have both the Pine64 and the Odroid-C2. While 12-CURRENT (as of today) compiles now very well (buildworld and buildkernel produce no errors while building world/kernel and using the built world as the foundation of an ARM64 poudriere-jail), there are some issues with the ports tree system. With recent sources, ports-mgmt/pkg fails to build with arm64 jail and so the whole ports tree. > > > Op zo 2 okt. 2016 15:04 schreef Mark Millard : > > [Context switching to ODroid-C2 from Pine64. . .] > > > > On 2016-Oct-2, at 12:19 AM, Tom Vijlbrief wrote: > > > > > I have a script which creates a bootable image: > > > > > > https://github.com/tomtor/image-freebsd-pine64 > > > > > > You can use the boot version from the Ubuntu image and change uEnv.txt and > > > create an additional partition which holds the kernel image. So you skip > > > ubldr. > > > > > > Note that the kernel boots, but I got none of the hardware devices working > > > (I spend more time on the Odroid-C2) and haven't been working on it the > > > last months... > > > > Anything worth reporting on the ODroid-C2 details for FreeBSD: what works, > > what does not, what needs to be done to boot FreeBSD, and so on? (I assume > > head [CURRENT-12 these days].) > > > > > > Looking around. . . > > > > > > https://github.com/tomtor/image-freebsd-c2 > > > > seems to have last been updated on May 7 (vs. > > https://github.com/tomtor/image-freebsd-pine64 's April 17). > > > > > > https://github.com/tomtor/freebsd/tree/tc2 > > > > seems to have last been updated on June 17. > > === > Mark Millard > markmi at dsl-only.net > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Apr 26 12:00:56 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E3DDD51220 for ; Wed, 26 Apr 2017 12:00:56 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D92689B0 for ; Wed, 26 Apr 2017 12:00:55 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MYtId-1dZ5Tl4BQR-00Vj7w; Wed, 26 Apr 2017 14:00:51 +0200 Date: Wed, 26 Apr 2017 14:00:49 +0200 From: "O. Hartmann" To: Tom Vijlbrief Cc: Mark Millard , freebsd-arm Subject: Re: FreeBSD status for/on ODroid-C2? Message-ID: <20170426140049.34e5aa6f@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <61985953-493F-432C-888E-3F4A06BBCA38@dsl-only.net> Organization: Walstatt X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DgJ5CU0dhk9rRdF+S6BicZ7DHBhJjREpm0jaRLfqeBafirYiIhR WwVtEuVFv6hsyIiKtQtedrRG4n859sSQpYjTRgwWBjAguis20p4SD2QAwL5CJH/rFy2Afxw oYdvEi9YK1BbGhOUWYPQh87/UEcfO4Y4NblW+hL9D7P75yoiE/iyxgJLtiUEv9yQlk9gBef I9qU38IsFzWINQI0WfGOA== X-UI-Out-Filterresults: notjunk:1;V01:K0:2cPDL4hu2DM=:4beHFz7KlQk8tXm7J8lo3r 7D+uypZTtmoIYZKA4Q40wVO/STV6/EXkZ6YxwyMd3QRk91bsSICxb1wlPIHKlY6RWytnydmDW nqoX3hDQZMDNH83RTpOgCbWW3VdGazHag/YNp5DXqd4IpwgYyHTamx3SIJh9fC0olZ/aRMAM9 HQr3h6Ketz9KAU/L/kZiNRNHYsMiZ8xiDKvWbC+HZ2HsgSkNecDyBzKOXf6kMAX+xInsspLRB zKbOt8MQcM/a+PCpVo1r27rU+50zxPl2m18KMWJb0PwDsx6tBHjGeUelXjeX29S+cO/A3heg+ UsWdehvfN/IVtvd4bAntVf6LghC/7ofZQSpWhAtW5JOKkbYaxj3Wv+OXmmHReq12QffwQCXJ6 SzcNvwl1orjG+Q1m9u9/LtR42Cs5GCrtPYVyEx7dw2ek8dZgPBNbEWwjieXjbcN52g8wq4gPa 7fzG+DxJQ9oAd+vsGiSv179uoRFLG2OcTbnKJzzPHjBjcHg9oH4gLdgBOfUw5cjg68hEEAfPb ktSXYYpZ6FZ0+ScYAY96HQUr4GVwm8EeX6MVvJqNRLZLh+MXO/3BvH5C0k0QnBHw9CUs6Bdu3 n0DqbWS0ri7SeemI6MWCHoguKEE4cmyxFnpuh0tDevMhHYFudb/Tu7soW7piBB3bBPY+Jkrs1 tW3F7DN595bYa0vs6lZgZCcQPJcZXsbmpRI3TEdglAw0Ye0J2AmxK3j1TOZ4PuweL4UhxWWKs bwaoGrN+o2C5ylKALpFU1FcuPlzCvGQYCPcE2oi4uQq8AUM6EGIraTQMTudiZ+jIkf85cSGnC c0iHv8q X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 12:00:56 -0000 On Wed, 26 Apr 2017 11:09:59 +0000 Tom Vijlbrief wrote: > I am pretty sure the Odroid-C2 wil run stable with the recent fork fixes, > but I reallocated my Odroid-C2 to a non-freebsd purpose, so I cannot test > this. > > Note that the ethernet and SD-card are still non functional, which makes > the Odroid-2 not really usable with FreeBSD, in it's current state. > > I had to boot the kernel over the network with U-Boot and use an USB > Ethernet adapter and file system on USB-disk... > > The Odroid-C2 is still a nice piece of hardware for an energy efficient > small (FreeBSD) server. The CPU runs at 1.5Ghz because it uses a more > modern production process than the RPI3 or Pine and it has a standard > cooling element mounted on the chips. It is also very compact compared to > the Pine. Not to mention its really phantastic small form factor (compared to RPi3 or Pine64). I hope that some near day we can run FreeBSD on top of this SoC. Its lack of a wireless interface and its 2GB as well as its high performance CPU makes it suitable for some security-relevant applications, were WiFi is strictly prohibited (we have such). Its eMMC interface is also pretty nice. > > > Op wo 26 apr. 2017 om 12:12 schreef Mark Millard : > > > On 2016-Oct-2, at 7:17 AM, Tom Vijlbrief wrote: > > > > > No change (at least in my tree) since my last report on this list > > somewhere in May or June. > > > > > > The kernel boots with 4 cpus and working usb. I use an usb ethernet > > device and usb disk with the root filesysteem. Compiling and running ports > > works, but a build world fails randomly with a memory access error eg after > > running 15 minutes. > > > > Modern head (12) should no longer have the (same?) > > buildworld problems now that head and stable/11 > > both have the 2 fixes that fix the fork behavior > > (avoiding trashing a special register and > > copy-on-write now working). > > > > It would be interesting to see how things go now > > if you rebuilt the Odroid-C2 based on modern head > > (12). > > > > > I don't think it makes sense to work on this until a freebsd rpi3 arm64 > > port is officially supported... > > > > FreeBSD for Odroid-C2 may go easier now that the > > fork problems are addressed. > > > > Both Pine64+ 2GB and rpi3 are now well behaved for > > buildworld. They were not before. > > > > > Op zo 2 okt. 2016 15:04 schreef Mark Millard : > > > [Context switching to ODroid-C2 from Pine64. . .] > > > > > > On 2016-Oct-2, at 12:19 AM, Tom Vijlbrief > > wrote: > > > > > > > I have a script which creates a bootable image: > > > > > > > > https://github.com/tomtor/image-freebsd-pine64 > > > > > > > > You can use the boot version from the Ubuntu image and change uEnv.txt > > and > > > > create an additional partition which holds the kernel image. So you > > skip > > > > ubldr. > > > > > > > > Note that the kernel boots, but I got none of the hardware devices > > working > > > > (I spend more time on the Odroid-C2) and haven't been working on it the > > > > last months... > > > > > > Anything worth reporting on the ODroid-C2 details for FreeBSD: what > > works, what does not, what needs to be done to boot FreeBSD, and so on? (I > > assume head [CURRENT-12 these days].) > > > > > > > > > Looking around. . . > > > > > > > > > https://github.com/tomtor/image-freebsd-c2 > > > > > > seems to have last been updated on May 7 (vs. > > https://github.com/tomtor/image-freebsd-pine64 's April 17). > > > > > > > > > https://github.com/tomtor/freebsd/tree/tc2 > > > > > > seems to have last been updated on June 17. > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Apr 26 22:16:47 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EE78D51357 for ; Wed, 26 Apr 2017 22:16:47 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 17D5D7A2 for ; Wed, 26 Apr 2017 22:16:46 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-qk0-x22d.google.com with SMTP id h123so13478205qke.0 for ; Wed, 26 Apr 2017 15:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=rto1cr9AMiNtI8A3f7By7xbN+ZybnXH50bSr9HREb3U=; b=Yap6gPIbtuQZn0X7tZOujHZmDHRcJYasYg4VjCoflRtl8NYOmKkJe3Fe1mCzwOGYuF ALUDlBi8R0HPfSPd7mac1qxtpAv26sNile0FOdeepKlSdRnmEIzAeAT3Sk/9a0txjav/ gDI/sW2w6kdrHIGBj1QHadDkMJNF+Y2T9Paz47gAUI++o+bu3CQWaXIWpWpmCZqV/3r8 PyJTzWsJrlXXm5jbgBPmgv4yegBR8Lvf7E1O4TiP8X9/fnEOj1jlVCVgK06pkHc+GbIs rvSJffy6XD3Y5u7L242QAvG0azZ4au6+FpNE7ZOz9jQ3Qb8nTwq/0e1it0fgLU4BBi3U NG0A== 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=rto1cr9AMiNtI8A3f7By7xbN+ZybnXH50bSr9HREb3U=; b=iKwF4aUqU2tqo5Atb2KX9iKXk3tyt6466MATP0xUwYbB4Nglkx2uv6mOi1NoSePBdb oC9gA/nW94TkpQ1v7MfYwUTLA+AJGqaltC1NtQaGt7RWUv5UYTnb8V1CbVBEXUTUAagD f3ePvUtu/yqgHUlB0Uqevax0BjTKfD0VDRazskeYBxB++NDDHeNhIB+rV+9i1Xozo5hb mIdszUmpDdQVMTbEaarLGIhonzxphO/y+5FT9czV/Ko+9jO/ZiDKvON5CZpi8zH0D/Cp kC6nidMXO5EAXBc1ZOnJPIZOm100U+Ls0afOJsrpp53Jk/OWG49rE90rvAPwVZS1wjuv MuHw== X-Gm-Message-State: AN3rC/50RDHtnJRyjRM4uOfJC9EGJM3Teveaxrjl6e2+XppJ56wx0Iyz FmfV7HLWz99DlqHieSOvuytbnXeTqz+V X-Received: by 10.55.201.26 with SMTP id q26mr2181841qki.107.1493245005647; Wed, 26 Apr 2017 15:16:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.102 with HTTP; Wed, 26 Apr 2017 15:16:45 -0700 (PDT) X-Originating-IP: [203.99.129.1] From: Jonathan Chen Date: Thu, 27 Apr 2017 10:16:45 +1200 Message-ID: Subject: RPI2 LED indicators on STABLE-11 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 22:16:47 -0000 Hi, I recently updated my RPI2 to STABLE-11, r317393, and I notice that the LED lights do not behave as expected. The power LED lights up as expected with uldr, but when the FreeBSD kernel boot messages start appearing, the red power LED switches off. The green activity LED never powers up. Is there something I have to do to get FreeBSD-11/armv6 to turn on the LED indicators? Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Thu Apr 27 03:22:31 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2B9AD52D4C for ; Thu, 27 Apr 2017 03:22:31 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 8B82817A6 for ; Thu, 27 Apr 2017 03:22:31 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 207B032482 for ; Wed, 26 Apr 2017 22:15:31 -0500 (CDT) Subject: Re: RPI2 LED indicators on STABLE-11 To: freebsd-arm@freebsd.org References: From: Karl Denninger Message-ID: Date: Wed, 26 Apr 2017 22:15:20 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060003020103070702030300" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 03:22:31 -0000 This is a cryptographically signed message in MIME format. --------------ms060003020103070702030300 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/26/2017 17:16, Jonathan Chen wrote: > Hi, > > I recently updated my RPI2 to STABLE-11, r317393, and I notice that > the LED lights do not behave as expected. The power LED lights up as > expected with uldr, but when the FreeBSD kernel boot messages start > appearing, the red power LED switches off. The green activity LED > never powers up. Is there something I have to do to get > FreeBSD-11/armv6 to turn on the LED indicators? > > Cheers. What you are observing is normal. If you want the green LED to power up (flash, etc) you need to do it programmatically. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060003020103070702030300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA0MjcwMzE1MjBaME8GCSqGSIb3DQEJBDFCBEDTl0ks 4P1DGAq+KtWJOWSMUBc4MTt0MNNpf/oh70tPYybL2PpgOJcqNtOaFf6AVoHnxiLDXkOuVyYR 2lFBbxZAMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAtlV3yvUamxH4 Skny2UKZZ43OP/0HgudNUhIQZM6wXdd+BiHvd8NWTvXjw3HttypYu/DJxpjLoneWCgxAZEwE vwtFG1jDdf8gMxtd31OicMKuC+Ng3MOhbXnX+4yZoO2YPsLHjRZ2wwhs/g2CXWEJGV8cAri/ CUa7aeJSV9Ik/3PdFtvXayupDryv8EhcCSb1EdMh+3InXiUdJPsKedMU9u1KyJdwg8jwdPJG Wc/y9+vAlPW8MaUVfuookz6rAe7xunOzRBu9Xj1stX4UtLJkCajL8v8rWF/Gv+d65cXS0Xvg REMb/53WaK4BUiQRaBpuXwt1uz5hSNDk26GPKWeUHXpdpOZVTB56a3xDp0FGlOvC/Dzt/C6W +UmpkgXO3RgPU2g2KahdxNlxi/SRRQS/WGdSkrAFiLZJXpyKZ9ZNfF0+RkZ3feF9PUKw1or9 E2JS2PJ5OXc8AQFu4l5KjbYeQHTAGz5lVc4je1mT4pDzxpnnWzEfh3kfojbDuey89V9SmAvy Jg7hpXuDmTCu5jPYg9+gkHzsJZdwSskddXoqkugQltAPHv23X2EaDUYfAalP9Bt98AoSQT+i 6CPs5g2Dmn/CUfki+UTdax17G/swB4vj2+wULolpSR0mZ/UiG5lPnYJVqBRvg3X+GjdjKkHh S+Hpn0Inv1qR/YZQJa4decYAAAAAAAA= --------------ms060003020103070702030300-- From owner-freebsd-arm@freebsd.org Thu Apr 27 06:10:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F9BAD52FC4 for ; Thu, 27 Apr 2017 06:10:24 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55838D9C for ; Thu, 27 Apr 2017 06:10:23 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-qk0-x22f.google.com with SMTP id y63so19483768qkd.1 for ; Wed, 26 Apr 2017 23:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ijnMAH5EZMDJG140mchTMoj4HDqNd5MuzVRwcsnsgQo=; b=AlRfnVzs6yiZNb9RakEJmrmlotosH+FmRD6uDg5GYbZAwy2gehqV2u6mYCmW53vhdx VBi8pG3xfr2hSH9rFMipy+sqyGBEgcsVmaNeb2gBF7kMynq61G2qvtDMaaOUm9epPmpF wT2yTmGRubn+JPEvrgt+WEYLWMIy+gWohy8ReN5PElzUYaVirnnkrYjfKoeQNqn91xsa EQUoI5o8vSsYWbDWgu5BDqn5aWt9GNMi73alHgMsl0vJPlnUeRqJf+ZSNV5kOFmPY8BF LtdSyqGlplv/+mdyCUWDisAziDunTF/x/sIL+uZvt087M3oMvIiWmELMR4UbSXa9WdVS tLDw== 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=ijnMAH5EZMDJG140mchTMoj4HDqNd5MuzVRwcsnsgQo=; b=grpRzOtNmr2jVrhbSRjWp2o/mI9pB7lonjDvfp2LRwHa9PM2/wt6LBGXhBRrXmSd33 OG4VPz3e8TEpMQaLwOcVh37lI/X+Po7EC4SqEZvrm/048q0leK+f/Xhym016xiJvKEnH VOo6e74pmi8XAYjhhDgs/dsmA5gRoActTGDZZmuLS2ZgenS/IqDCwYZcpke20U1TaShx PL+gXU0YCGHrQ/4NC4rGIbtzDybThj0Zp+qRl+cy7FkWOaqux7VMy4zcYO3OGA0LDI3A huqbnNzy2p/n7mBVapK/QLWXeWLrQLw12HRGcjybpND7MTq9Uz/fLKHNPUZCy98IdgS3 C5Nw== X-Gm-Message-State: AN3rC/5SCXfsx22rGyPQAyhnZy//oKHbG97snbXPXjlsZQAWqxe/d2C1 m7CaaI5CCznlchSqA/0vcZZQgozqtA== X-Received: by 10.55.195.23 with SMTP id a23mr3303819qkj.223.1493273423129; Wed, 26 Apr 2017 23:10:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.102 with HTTP; Wed, 26 Apr 2017 23:10:22 -0700 (PDT) X-Originating-IP: [101.53.202.8] In-Reply-To: References: From: Jonathan Chen Date: Thu, 27 Apr 2017 18:10:22 +1200 Message-ID: Subject: Re: RPI2 LED indicators on STABLE-11 To: Karl Denninger Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 06:10:24 -0000 On 27 April 2017 at 15:15, Karl Denninger wrote: > On 4/26/2017 17:16, Jonathan Chen wrote: >> Hi, >> >> I recently updated my RPI2 to STABLE-11, r317393, and I notice that >> the LED lights do not behave as expected. The power LED lights up as >> expected with uldr, but when the FreeBSD kernel boot messages start >> appearing, the red power LED switches off. The green activity LED >> never powers up. Is there something I have to do to get >> FreeBSD-11/armv6 to turn on the LED indicators? >> > What you are observing is normal. If you want the green LED to power up > (flash, etc) you need to do it programmatically. Ah. Thanks for that. I've just noticed /dev/led/act and /dev/led/pwr. I'm now hunting for docs to see what I can do with them. Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Thu Apr 27 06:19:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36A7ED524DF for ; Thu, 27 Apr 2017 06:19:59 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E588E12EE for ; Thu, 27 Apr 2017 06:19:58 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-qt0-x22a.google.com with SMTP id y33so18445551qta.2 for ; Wed, 26 Apr 2017 23:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xIfoQw9bGk8toTpU/LzkT0i/97hETu9LlGUVYZ97vt4=; b=x8ApLoNma1TU17F0GbAZ4FBhRAU2maGKAirNeljgTSCTX4QWZjt+9xolloYeQQ6Bxj L+0Ok7OUPEtxwW8CGT0rkgN5u9rwWs9YCncmfYGiQmGtLwUnyOL2sVw75VL29zg2Hw+E sHCoAAvPoVY3gOCgCD1OWtPYrUBBkf/Oe0J49OlWNQUYeD3ID1qmRaWGV4y8uZasoSyK YcFU5M+1v0t9erWqoqx9/X6qzDZCyJUMxPk3rlCwn6KBSYYDRtUtBIZ7UF4FJ/hQyT/Q UmbvtR3dxk1MqKRZhyatqAjOH35LxhMpJeg3Ny0p+mxPHS1nuGW8H21QTwSjBd/7V0qZ YBpw== 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=xIfoQw9bGk8toTpU/LzkT0i/97hETu9LlGUVYZ97vt4=; b=emuT5XWT9LYpxxyyz4VCQpVz4RTAYlnQxxeYHPmPanqlOUiphxymBYGHFnCVqbPshd a+uUhx5Rlb1bJno2KhSjwdoxHad5OhHAojU7DL5F/N8boXk2DJIMnwEB8utXfbA6IJwD HiKEGUIvpVuXE3eZ4YxwycJV8/FRi6GBDvPMhSbojSbboZ11NMNlVQC8vP4gdp2+mnMC Dg7uZN/ABbAs50dhRHL004lfBAyLxp3Of8DhQowIEHOj189dg/EZ6cytNm+Oc9/ruknJ KjAEuNZDdHQbsAtWazuhGXt2TleZwZUfgfsvFVtBHrrz7yxLD9jBgBEKYg9SschtkBwH Qomw== X-Gm-Message-State: AN3rC/4MvGI7QZg3Jowna/SNFUbrrdn1KtY/k16E+CnJGwy3kZgEwIPm zIYyE2MLU1FiXRc7aAPS8m6ZEjbvKoY6 X-Received: by 10.200.57.18 with SMTP id s18mr3340526qtb.1.1493273998016; Wed, 26 Apr 2017 23:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.102 with HTTP; Wed, 26 Apr 2017 23:19:57 -0700 (PDT) X-Originating-IP: [101.53.202.8] In-Reply-To: <543714FC-0F70-43F3-8836-AB943C87F5B1@cs.huji.ac.il> References: <543714FC-0F70-43F3-8836-AB943C87F5B1@cs.huji.ac.il> From: Jonathan Chen Date: Thu, 27 Apr 2017 18:19:57 +1200 Message-ID: Subject: Re: RPI2 LED indicators on STABLE-11 To: Daniel Braniss Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 06:19:59 -0000 On 27 April 2017 at 18:17, Daniel Braniss wrote: > >> On 27 Apr 2017, at 09:10, Jonathan Chen wrote: >> >> On 27 April 2017 at 15:15, Karl Denninger wrote: >>> On 4/26/2017 17:16, Jonathan Chen wrote: >>>> Hi, >>>> >>>> I recently updated my RPI2 to STABLE-11, r317393, and I notice that >>>> the LED lights do not behave as expected. The power LED lights up as >>>> expected with uldr, but when the FreeBSD kernel boot messages start >>>> appearing, the red power LED switches off. The green activity LED >>>> never powers up. Is there something I have to do to get >>>> FreeBSD-11/armv6 to turn on the LED indicators? >>>> >>> What you are observing is normal. If you want the green LED to power up >>> (flash, etc) you need to do it programmatically. >> >> Ah. Thanks for that. I've just noticed /dev/led/act and /dev/led/pwr. >> I'm now hunting for docs to see what I can do with them. >> > > man led Yup, got that. I esp. like the example: /usr/bin/morse -l "Soekris rocks" > /dev/led/error Cheers. -- Jonathan Chen From owner-freebsd-arm@freebsd.org Thu Apr 27 06:24:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D08D3D527D8 for ; Thu, 27 Apr 2017 06:24:59 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EB3A1717 for ; Thu, 27 Apr 2017 06:24:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1d3ckE-000MO1-32; Thu, 27 Apr 2017 09:17:38 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RPI2 LED indicators on STABLE-11 From: Daniel Braniss In-Reply-To: Date: Thu, 27 Apr 2017 09:17:37 +0300 Cc: Karl Denninger , freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <543714FC-0F70-43F3-8836-AB943C87F5B1@cs.huji.ac.il> References: To: Jonathan Chen X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 06:24:59 -0000 > On 27 Apr 2017, at 09:10, Jonathan Chen wrote: > > On 27 April 2017 at 15:15, Karl Denninger wrote: >> On 4/26/2017 17:16, Jonathan Chen wrote: >>> Hi, >>> >>> I recently updated my RPI2 to STABLE-11, r317393, and I notice that >>> the LED lights do not behave as expected. The power LED lights up as >>> expected with uldr, but when the FreeBSD kernel boot messages start >>> appearing, the red power LED switches off. The green activity LED >>> never powers up. Is there something I have to do to get >>> FreeBSD-11/armv6 to turn on the LED indicators? >>> >> What you are observing is normal. If you want the green LED to power up >> (flash, etc) you need to do it programmatically. > > Ah. Thanks for that. I've just noticed /dev/led/act and /dev/led/pwr. > I'm now hunting for docs to see what I can do with them. > man led > Cheers. > -- > Jonathan Chen > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Thu Apr 27 15:59:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A23BED53E9C for ; Thu, 27 Apr 2017 15:59:06 +0000 (UTC) (envelope-from verginegiovanni@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 17E8E1D15 for ; Thu, 27 Apr 2017 15:59:06 +0000 (UTC) (envelope-from verginegiovanni@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id t144so20127973lff.1 for ; Thu, 27 Apr 2017 08:59:06 -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:cc; bh=Af9ZHxCuCZcKgTZJpGMteOU3TlayzaJv6LlwerWzjhc=; b=hrCmv0IPaS9Tv6n/PzKg5d17OhJOXHYmn9fmjxgDVYHz8BgmdJrlYIeyFYDJ18gPIc zgnq9HuhpBZaaR/xDuEH7A/BiqvFhOZSrBiBk7vXr4alGAGfB3Iv4NZ0UGC9I5VxEzrE Ujd//mKtCAemqw9cI3k9KZrYfVRIQqR0MvmxZTWdIMtxFwG0YtByDAZgAMj+ZR3mJ5dL Az83XeiQLc2WDdsj+cFmEj9Jk1BG8uyoOspzgEwJN0/ruA19+I16CAn2oUEa3oWkqyKI g8cvAutRXmzlr0EmOUmMcTltC1+SjKGoBUtiD4P4prizbOkk5gdQ/pNphbdqI0ctLMKA u5dw== 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:cc; bh=Af9ZHxCuCZcKgTZJpGMteOU3TlayzaJv6LlwerWzjhc=; b=hD83i1q9h1MS8R0v7hYFC3jHdiWNQ1xH9eMOa2GnLzCQCkBnEtuFopf4lv5P+MpCFX vb1PzGmwwwurIXOuZQD4f6MmfhPajKscPqRyEOg7X5xbuyPUpfBgm0D9uhaqVBb67nJh BaEn/PhJc8nWKrP3v13ko2B4InLPfxE/6Eerb17ltyKDxXkhE7VkMT6bkvMLMbNtIVpx ntctujaWhJu/V90dr4BGeSngSzxO+SIls3bqIJw7AFfb9a4/eKH0N+QTbqr4n+zagp/p dwvxlWGHDYc07LY2tm1srepKgLm3mZVGrXfF2IP7AisSYdYcH8c3WRV8w8PR+PY0lJXe nPaw== X-Gm-Message-State: AN3rC/661xgygD32h3/pN/yY6WxoX2prdo47eJzArPg1HHWlaZq8XFP3 aMzqa2JFSd/HgTdkF7QcXXS0B/C+wQ== X-Received: by 10.46.78.25 with SMTP id c25mr246129ljb.45.1493308743600; Thu, 27 Apr 2017 08:59:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.26.11 with HTTP; Thu, 27 Apr 2017 08:59:02 -0700 (PDT) In-Reply-To: <20170426140049.34e5aa6f@freyja.zeit4.iv.bundesimmobilien.de> References: <61985953-493F-432C-888E-3F4A06BBCA38@dsl-only.net> <20170426140049.34e5aa6f@freyja.zeit4.iv.bundesimmobilien.de> From: Giovanni Date: Thu, 27 Apr 2017 18:59:02 +0300 Message-ID: Subject: Re: FreeBSD status for/on ODroid-C2? Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:59:06 -0000 Hello guys, I have an Odroid C2 that I'm not using right now with SD card (without eMMC). but I have basically no skills right now about recompiling FreeBSD for arm. So if you want to send me your experimental images and test them for you, just drop me a line, I will be glad to help you. Regards, Giovanni 2017-04-26 15:00 GMT+03:00 O. Hartmann : > On Wed, 26 Apr 2017 11:09:59 +0000 > Tom Vijlbrief wrote: > > > I am pretty sure the Odroid-C2 wil run stable with the recent fork fixes, > > but I reallocated my Odroid-C2 to a non-freebsd purpose, so I cannot test > > this. > > > > Note that the ethernet and SD-card are still non functional, which makes > > the Odroid-2 not really usable with FreeBSD, in it's current state. > > > > I had to boot the kernel over the network with U-Boot and use an USB > > Ethernet adapter and file system on USB-disk... > > > > The Odroid-C2 is still a nice piece of hardware for an energy efficient > > small (FreeBSD) server. The CPU runs at 1.5Ghz because it uses a more > > modern production process than the RPI3 or Pine and it has a standard > > cooling element mounted on the chips. It is also very compact compared to > > the Pine. > > Not to mention its really phantastic small form factor (compared to RPi3 or > Pine64). > > I hope that some near day we can run FreeBSD on top of this SoC. Its lack > of a > wireless interface and its 2GB as well as its high performance CPU makes it > suitable for some security-relevant applications, were WiFi is strictly > prohibited (we have such). Its eMMC interface is also pretty nice. > > > > > > > Op wo 26 apr. 2017 om 12:12 schreef Mark Millard : > > > > > On 2016-Oct-2, at 7:17 AM, Tom Vijlbrief > wrote: > > > > > > > No change (at least in my tree) since my last report on this list > > > somewhere in May or June. > > > > > > > > The kernel boots with 4 cpus and working usb. I use an usb ethernet > > > device and usb disk with the root filesysteem. Compiling and running > ports > > > works, but a build world fails randomly with a memory access error eg > after > > > running 15 minutes. > > > > > > Modern head (12) should no longer have the (same?) > > > buildworld problems now that head and stable/11 > > > both have the 2 fixes that fix the fork behavior > > > (avoiding trashing a special register and > > > copy-on-write now working). > > > > > > It would be interesting to see how things go now > > > if you rebuilt the Odroid-C2 based on modern head > > > (12). > > > > > > > I don't think it makes sense to work on this until a freebsd rpi3 > arm64 > > > port is officially supported... > > > > > > FreeBSD for Odroid-C2 may go easier now that the > > > fork problems are addressed. > > > > > > Both Pine64+ 2GB and rpi3 are now well behaved for > > > buildworld. They were not before. > > > > > > > Op zo 2 okt. 2016 15:04 schreef Mark Millard >: > > > > [Context switching to ODroid-C2 from Pine64. . .] > > > > > > > > On 2016-Oct-2, at 12:19 AM, Tom Vijlbrief > > > wrote: > > > > > > > > > I have a script which creates a bootable image: > > > > > > > > > > https://github.com/tomtor/image-freebsd-pine64 > > > > > > > > > > You can use the boot version from the Ubuntu image and change > uEnv.txt > > > and > > > > > create an additional partition which holds the kernel image. So you > > > skip > > > > > ubldr. > > > > > > > > > > Note that the kernel boots, but I got none of the hardware devices > > > working > > > > > (I spend more time on the Odroid-C2) and haven't been working on > it the > > > > > last months... > > > > > > > > Anything worth reporting on the ODroid-C2 details for FreeBSD: what > > > works, what does not, what needs to be done to boot FreeBSD, and so > on? (I > > > assume head [CURRENT-12 these days].) > > > > > > > > > > > > Looking around. . . > > > > > > > > > > > > https://github.com/tomtor/image-freebsd-c2 > > > > > > > > seems to have last been updated on May 7 (vs. > > > https://github.com/tomtor/image-freebsd-pine64 's April 17). > > > > > > > > > > > > https://github.com/tomtor/freebsd/tree/tc2 > > > > > > > > seems to have last been updated on June 17. > > > > > > === > > > Mark Millard > > > markmi at dsl-only.net > > > > > > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Apr 27 18:05:10 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26791D534E1 for ; Thu, 27 Apr 2017 18:05:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (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 02C95DFE for ; Thu, 27 Apr 2017 18:05:09 +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 v3RI4l7d013292 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 11:04:48 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v3RI4jtQ013291; Thu, 27 Apr 2017 11:04:45 -0700 (PDT) (envelope-from fbsd) Date: Thu, 27 Apr 2017 11:04:45 -0700 From: bob prohaska To: Jonathan Chen Cc: Daniel Braniss , freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI2 LED indicators on STABLE-11 Message-ID: <20170427180445.GA12019@www.zefox.net> References: <543714FC-0F70-43F3-8836-AB943C87F5B1@cs.huji.ac.il> 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 18:05:10 -0000 On Thu, Apr 27, 2017 at 06:19:57PM +1200, Jonathan Chen wrote: > > Yup, got that. I esp. like the example: > /usr/bin/morse -l "Soekris rocks" > /dev/led/error > My machine (RPI2) running -current seems to want /dev/led/act but works nicely otherwise. However, it does not seem to stop; it's been running for over an hour. There doesn't seem to be a residual job showing in top or ps. It doesn't look as if morse defaults to a loop, anybody have a guess what might be going on? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Thu Apr 27 18:59:57 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12CACD5336E for ; Thu, 27 Apr 2017 18:59:57 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (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 BD69296D for ; Thu, 27 Apr 2017 18:59:56 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.1] (port=50203 helo=caithnard.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1d3oLg-0006yk-74; Thu, 27 Apr 2017 18:41:04 +0000 Received: from [127.0.0.1] (port=45137 helo=caithnard.riddles.org.uk) by caithnard.riddles.org.uk with esmtp (Exim 4.89 (FreeBSD)) (envelope-from ) id 1d3oLf-0004ph-CP; Thu, 27 Apr 2017 18:41:03 +0000 From: Andrew Gierth To: bob prohaska Cc: Jonathan Chen , freebsd-arm@freebsd.org Subject: Re: RPI2 LED indicators on STABLE-11 In-Reply-To: <20170427180445.GA12019@www.zefox.net> (bob prohaska's message of "Thu, 27 Apr 2017 11:04:45 -0700") Message-ID: <87wpa5u27b.fsf@news-spur.riddles.org.uk> References: <543714FC-0F70-43F3-8836-AB943C87F5B1@cs.huji.ac.il> <20170427180445.GA12019@www.zefox.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Thu, 27 Apr 2017 19:41:02 +0100 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 18:59:57 -0000 >>>>> "bob" == bob prohaska writes: bob> My machine (RPI2) running -current seems to want /dev/led/act but bob> works nicely otherwise. However, it does not seem to stop; it's bob> been running for over an hour. There doesn't seem to be a residual bob> job showing in top or ps. man led; "The sequence is repeated after a one second pause." If you want it to stop, just echo 0 >>/dev/led/act -- Andrew. From owner-freebsd-arm@freebsd.org Thu Apr 27 23:22:38 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97973D53D04 for ; Thu, 27 Apr 2017 23:22:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 48952D42 for ; Thu, 27 Apr 2017 23:22:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17748 invoked from network); 27 Apr 2017 23:22:36 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Apr 2017 23:22:36 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 27 Apr 2017 19:22:36 -0400 (EDT) Received: (qmail 20935 invoked from network); 27 Apr 2017 23:22:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Apr 2017 23:22:35 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2B1BAEC904C; Thu, 27 Apr 2017 16:22:35 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 Message-Id: <4BC7E6BC-4BF9-4F5E-9851-E022AC9A3082@dsl-only.net> Date: Thu, 27 Apr 2017 16:22:34 -0700 To: freebsd-arm , freebsd-hackers@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 23:22:38 -0000 Unfortunately for this FYI the attempt to produce a dump failed and so all the information that I have is what I first captured from the console output: a backtrace. The context was head -r317015 on a Pine64+ 2GB. At the time I was experimenting with trying to build a vm.raw from my own build of FreeBSD. The (root) file system is on a USB SSD off of a powered USB hub. panic: ARM64TODO: reclaim_pv_chunk cpuid = 1 time = 1493332968 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0xffff000000605cc0 lr = 0xffff0000000869cc sp = 0xffff000083ba4f00 fp = 0xffff000083ba5110 db_trace_self_wrapper() at vpanic+0x164 pc = 0xffff0000000869cc lr = 0xffff00000031d464 sp = 0xffff000083ba5120 fp = 0xffff000083ba5190 vpanic() at panic+0x4c pc = 0xffff00000031d464 lr = 0xffff00000031d2fc sp = 0xffff000083ba51a0 fp = 0xffff000083ba5220 panic() at reclaim_pv_chunk+0x10 pc = 0xffff00000031d2fc lr = 0xffff00000061a234 sp = 0xffff000083ba5230 fp = 0xffff000083ba5230 reclaim_pv_chunk() at get_pv_entry+0x240 pc = 0xffff00000061a234 lr = 0xffff000000616184 sp = 0xffff000083ba5240 fp = 0xffff000083ba5260 get_pv_entry() at pmap_enter+0x694 pc = 0xffff000000616184 lr = 0xffff0000006156a0 sp = 0xffff000083ba5270 fp = 0xffff000083ba5300 pmap_enter() at vm_fault_hold+0x28c pc = 0xffff0000006156a0 lr = 0xffff0000005b9740 sp = 0xffff000083ba5310 fp = 0xffff000083ba5460 vm_fault_hold() at vm_fault+0x70 pc = 0xffff0000005b9740 lr = 0xffff0000005b9464 sp = 0xffff000083ba5470 fp = 0xffff000083ba54a0 vm_fault() at data_abort+0xe0 pc = 0xffff0000005b9464 lr = 0xffff00000061ad94 sp = 0xffff000083ba54b0 fp = 0xffff000083ba5560 data_abort() at handle_el1h_sync+0x70 pc = 0xffff00000061ad94 lr = 0xffff000000607870 sp = 0xffff000083ba5570 fp = 0xffff000083ba5680 handle_el1h_sync() at kern_select+0x9fc pc = 0xffff000000607870 lr = 0xffff00000037db3c sp = 0xffff000083ba5690 fp = 0xffff000083ba58f0 kern_select() at sys_select+0x5c pc = 0xffff00000037db3c lr = 0xffff00000037dc58 sp = 0xffff000083ba5900 fp = 0xffff000083ba5930 sys_select() at do_el0_sync+0xa48 pc = 0xffff00000037dc58 lr = 0xffff00000061b91c sp = 0xffff000083ba5940 fp = 0xffff000083ba5a70 do_el0_sync() at handle_el0_sync+0x6c pc = 0xffff00000061b91c lr = 0xffff0000006079e8 sp = 0xffff000083ba5a80 fp = 0xffff000083ba5b90 handle_el0_sync() at 0x4948c pc = 0xffff0000006079e8 lr = 0x000000000004948c sp = 0xffff000083ba5ba0 fp = 0x0000ffffffffd960 === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Apr 28 00:34:45 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40DF5D4D8A9 for ; Fri, 28 Apr 2017 00:34:45 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (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 1D7C31790 for ; Fri, 28 Apr 2017 00:34:44 +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 v3S0Yat8017377 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 17:34:37 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v3S0YXM8017374; Thu, 27 Apr 2017 17:34:33 -0700 (PDT) (envelope-from fbsd) Date: Thu, 27 Apr 2017 17:34:33 -0700 From: bob prohaska To: Andrew Gierth Cc: Jonathan Chen , freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI2 LED indicators on STABLE-11 Message-ID: <20170428003433.GB12019@www.zefox.net> References: <543714FC-0F70-43F3-8836-AB943C87F5B1@cs.huji.ac.il> <20170427180445.GA12019@www.zefox.net> <87wpa5u27b.fsf@news-spur.riddles.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wpa5u27b.fsf@news-spur.riddles.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 00:34:45 -0000 On Thu, Apr 27, 2017 at 07:41:02PM +0100, Andrew Gierth wrote: > man led; "The sequence is repeated after a one second pause." > > If you want it to stop, just echo 0 >>/dev/led/act > Thank you, I thought the behavior would be controlled by /usr/bin/morse. It never crossed my mind that a device file would (or could, for that matter) loop on its own. bob prohaska From owner-freebsd-arm@freebsd.org Fri Apr 28 02:31:48 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F83AD548EE for ; Fri, 28 Apr 2017 02:31:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 008FA1196 for ; Fri, 28 Apr 2017 02:31:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7621 invoked from network); 28 Apr 2017 02:34:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 28 Apr 2017 02:34:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 27 Apr 2017 22:31:46 -0400 (EDT) Received: (qmail 29250 invoked from network); 28 Apr 2017 02:31:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Apr 2017 02:31:46 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 490FCEC85DE; Thu, 27 Apr 2017 19:31:45 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 [another example] Date: Thu, 27 Apr 2017 19:31:44 -0700 References: <4BC7E6BC-4BF9-4F5E-9851-E022AC9A3082@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org, FreeBSD Current In-Reply-To: <4BC7E6BC-4BF9-4F5E-9851-E022AC9A3082@dsl-only.net> Message-Id: <51050A07-B951-45C0-82CE-73BB342F012E@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 02:31:48 -0000 [Another example panic. Again no dump. But I have what a top -PCwaopid froze at this time.] On 2017-Apr-27, at 4:22 PM, Mark Millard wrote: > Unfortunately for this FYI the attempt to produce a dump > failed and so all the information that I have is what I > first captured from the console output: a backtrace. >=20 > The context was head -r317015 on a Pine64+ 2GB. At the > time I was experimenting with trying to build a vm.raw > from my own build of FreeBSD. The (root) file system > is on a USB SSD off of a powered USB hub. >=20 > panic: ARM64TODO: reclaim_pv_chunk > cpuid =3D 1 > time =3D 1493332968 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc > sp =3D 0xffff000083ba4f00 fp =3D 0xffff000083ba5110 >=20 > db_trace_self_wrapper() at vpanic+0x164 > pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 > sp =3D 0xffff000083ba5120 fp =3D 0xffff000083ba5190 >=20 > vpanic() at panic+0x4c > pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc > sp =3D 0xffff000083ba51a0 fp =3D 0xffff000083ba5220 >=20 > panic() at reclaim_pv_chunk+0x10 > pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 > sp =3D 0xffff000083ba5230 fp =3D 0xffff000083ba5230 >=20 > reclaim_pv_chunk() at get_pv_entry+0x240 > pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 > sp =3D 0xffff000083ba5240 fp =3D 0xffff000083ba5260 >=20 > get_pv_entry() at pmap_enter+0x694 > pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 > sp =3D 0xffff000083ba5270 fp =3D 0xffff000083ba5300 >=20 > pmap_enter() at vm_fault_hold+0x28c > pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 > sp =3D 0xffff000083ba5310 fp =3D 0xffff000083ba5460 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 > sp =3D 0xffff000083ba5470 fp =3D 0xffff000083ba54a0 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff000083ba54b0 fp =3D 0xffff000083ba5560 >=20 > data_abort() at handle_el1h_sync+0x70 > pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 > sp =3D 0xffff000083ba5570 fp =3D 0xffff000083ba5680 >=20 > handle_el1h_sync() at kern_select+0x9fc > pc =3D 0xffff000000607870 lr =3D 0xffff00000037db3c > sp =3D 0xffff000083ba5690 fp =3D 0xffff000083ba58f0 >=20 > kern_select() at sys_select+0x5c > pc =3D 0xffff00000037db3c lr =3D 0xffff00000037dc58 > sp =3D 0xffff000083ba5900 fp =3D 0xffff000083ba5930 >=20 > sys_select() at do_el0_sync+0xa48 > pc =3D 0xffff00000037dc58 lr =3D 0xffff00000061b91c > sp =3D 0xffff000083ba5940 fp =3D 0xffff000083ba5a70 >=20 > do_el0_sync() at handle_el0_sync+0x6c > pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 > sp =3D 0xffff000083ba5a80 fp =3D 0xffff000083ba5b90 >=20 > handle_el0_sync() at 0x4948c > pc =3D 0xffff0000006079e8 lr =3D 0x000000000004948c > sp =3D 0xffff000083ba5ba0 fp =3D 0x0000ffffffffd960 This time I got to record from top: (swap is on a swap partition) (pid 49888's SIZE vs. RES and SWAP might be interesting) (as might the Active figure) last pid: 48988; load averages: 0.64, 0.44, 0.38 = = up 0+04:21:01 19:19:50 32 processes: 2 running, 30 sleeping CPU 0: 13.2% user, 0.0% nice, 23.2% system, 0.3% interrupt, 63.3% idle CPU 1: 4.6% user, 0.0% nice, 23.9% system, 0.0% interrupt, 71.5% idle CPU 2: 2.1% user, 0.0% nice, 23.2% system, 0.0% interrupt, 74.8% idle CPU 3: 3.3% user, 0.0% nice, 23.8% system, 0.0% interrupt, 72.8% idle Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free Swap: 6144M Total, 34M Used, 6110M Free, 348K Out PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 48988 root 4 31 0 651M 27048K 0K RUN 0 0:03 = 87.60% xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw 11983 root 1 22 0 5068K 0K 0K wait 3 0:00 = 0.00% make vm-image vm-install DESTDIR=3D/usr/obj/DESTDIRs/vmimage-aarch64= () 11981 root 1 42 0 7320K 0K 1516K wait 1 0:00 = 0.00% sh = /root/sys_build_scripts.aarch64-host/make_noscript_aarch64_nodebug_clang_b= ootstrap-aarch64-host.sh vm-image vm-install=20 11980 root 1 20 0 6656K 1548K 0K select 0 0:02 = 0.00% [script] 11977 root 1 30 0 7320K 0K 1516K wait 3 0:00 = 0.00% /bin/sh = /root/sys_build_scripts.aarch64-host/make_aarch64_nodebug_clang_bootstrap-= aarch64-host.sh vm-image vm-install DEST 2694 root 1 20 0 8804K 2072K 0K CPU2 2 0:07 = 0.17% top -PCwaopid 827 root 1 20 0 7320K 0K 360K wait 0 0:00 = 0.00% su () 826 markmi 1 22 0 10372K 0K 1532K wait 3 0:00 = 0.00% su () 820 markmi 1 24 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () 819 markmi 1 20 0 18416K 1152K 0K select 1 0:21 = 0.00% sshd: markmi@pts/1 (sshd) 816 root 1 20 0 18416K 3276K 0K select 0 0:00 = 0.00% sshd: markmi [priv] (sshd) 765 root 1 20 0 7320K 0K 224K wait 2 0:00 = 0.00% su () 764 markmi 1 23 0 10372K 0K 1532K wait 0 0:00 = 0.00% su () 758 markmi 1 31 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () 757 markmi 1 20 0 18416K 228K 904K select 3 0:01 = 0.01% sshd: markmi@pts/0 (sshd) 754 root 1 25 0 18416K 3276K 0K select 1 0:00 = 0.00% sshd: markmi [priv] (sshd) 746 root 1 27 0 7320K 1532K 0K ttyin 0 0:00 = 0.00% -sh (sh) 745 root 1 20 0 10372K 0K 1532K wait 1 0:00 = 0.00% login [pam] () 700 root 1 20 0 6948K 0K 168K nanslp 1 0:00 = 0.00% /usr/sbin/cron -s () 696 smmsp 1 20 0 10460K 0K 184K pause 0 0:00 = 0.00% sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue = () 693 root 1 20 0 10460K 1392K 0K select 1 0:00 = 0.03% sendmail: accepting connections (sendmail) 690 root 1 20 0 15800K 968K 0K select 2 0:00 = 0.00% /usr/sbin/sshd 661 root 1 20 0 6656K 344K 0K select 2 0:01 = 0.00% /usr/sbin/powerd 658 root 2 20 0 12788K 12672K 0K select 0 0:02 = 0.01% /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift 620 root 32 52 0 6384K 1100K 0K rpcsvc 1 0:00 = 0.00% nfsd: server (nfsd) 619 root 1 52 0 6384K 704K 0K select 1 0:00 = 0.00% nfsd: master (nfsd) 617 root 1 20 0 6684K 688K 0K select 1 0:00 = 0.00% /usr/sbin/mountd -r 478 root 1 20 0 6676K 596K 0K select 3 0:00 = 0.00% /usr/sbin/rpcbind 469 root 1 20 0 6680K 572K 0K select 2 0:00 = 0.00% /usr/sbin/syslogd -s 396 root 1 20 0 9580K 32K 0K select 0 0:00 = 0.00% /sbin/devd 308 _dhcp 1 20 0 6800K 532K 0K select 2 0:00 = 0.00% dhclient: awg0 (dhclient) 307 root 1 52 0 6800K 424K 0K select 2 0:00 = 0.00% dhclient: awg0 [priv] (dhclient) And here is the backtrace: timeout stopping cpus panic: ARM64TODO: reclaim_pv_chunk cpuid =3D 0 time =3D 1493345992 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc sp =3D 0xffff000083d301d0 fp =3D 0xffff000083d303e0 db_trace_self_wrapper() at vpanic+0x164 pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 sp =3D 0xffff000083d303f0 fp =3D 0xffff000083d30460 vpanic() at panic+0x4c pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc sp =3D 0xffff000083d30470 fp =3D 0xffff000083d304f0 panic() at reclaim_pv_chunk+0x10 pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 sp =3D 0xffff000083d30500 fp =3D 0xffff000083d30500 reclaim_pv_chunk() at get_pv_entry+0x240 pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 sp =3D 0xffff000083d30510 fp =3D 0xffff000083d30530 get_pv_entry() at pmap_enter+0x694 pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 sp =3D 0xffff000083d30540 fp =3D 0xffff000083d305d0 pmap_enter() at vm_fault_hold+0x28c pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 sp =3D 0xffff000083d305e0 fp =3D 0xffff000083d30730 vm_fault_hold() at vm_fault+0x70 pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 sp =3D 0xffff000083d30740 fp =3D 0xffff000083d30770 vm_fault() at data_abort+0xe0 pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 sp =3D 0xffff000083d30780 fp =3D 0xffff000083d30830 data_abort() at handle_el0_sync+0x6c pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 sp =3D 0xffff000083d30840 fp =3D 0xffff000083d30950 handle_el0_sync() at 0x400a3de4 pc =3D 0xffff0000006079e8 lr =3D 0x00000000400a3de4 sp =3D 0xffff000083d30960 fp =3D 0x0000ffffbfdfcd30 KDB: enter: panic [ thread pid 48988 tid 100230 ] Stopped at kdb_enter+0x44: undefined d4200000 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Apr 28 05:26:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6E20D54373 for ; Fri, 28 Apr 2017 05:26:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 6C8957A4 for ; Fri, 28 Apr 2017 05:26:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4853 invoked from network); 28 Apr 2017 05:26:22 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Apr 2017 05:26:22 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 28 Apr 2017 01:26:22 -0400 (EDT) Received: (qmail 18704 invoked from network); 28 Apr 2017 05:26:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Apr 2017 05:26:22 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6D413EC904C; Thu, 27 Apr 2017 22:26:21 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 [mdconfig -d not effectively releasing memory?] Date: Thu, 27 Apr 2017 22:26:20 -0700 References: <4BC7E6BC-4BF9-4F5E-9851-E022AC9A3082@dsl-only.net> <51050A07-B951-45C0-82CE-73BB342F012E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org, FreeBSD Current In-Reply-To: <51050A07-B951-45C0-82CE-73BB342F012E@dsl-only.net> Message-Id: <302D1255-4D34-4C1B-8F3A-9180A6AF8768@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 05:26:24 -0000 [As the text does not really follow from the earlier text I'd sent directly I'm top posting a hypothesis about where so much active memory came from to be so low in available memory to get an reclaim_pv_chunk attempt.] My hypothesis is that the "mdconfig -d"s from vm_copy_base (from /usr/src/release/tools/vmimage.subr ) did not actually release the memory resources involved (from vnode backed mdconfig use): vm_copy_base() { # Creates a new UFS root filesystem and copies the contents of = the # current root filesystem into it. This produces a "clean" disk # image without any remnants of files which were created = temporarily # during image-creation and have since been deleted (e.g., = downloaded # package archives). mkdir -p ${DESTDIR}/old mdold=3D$(mdconfig -f ${VMBASE}) mount /dev/${mdold} ${DESTDIR}/old truncate -s ${VMSIZE} ${VMBASE}.tmp mkdir -p ${DESTDIR}/new mdnew=3D$(mdconfig -f ${VMBASE}.tmp) newfs -L rootfs /dev/${mdnew} mount /dev/${mdnew} ${DESTDIR}/new tar -cf- -C ${DESTDIR}/old . | tar -xUf- -C ${DESTDIR}/new umount_loop /dev/${mdold} rmdir ${DESTDIR}/old mdconfig -d -u ${mdold} umount_loop /dev/${mdnew} rmdir ${DESTDIR}/new tunefs -n enable /dev/${mdnew} mdconfig -d -u ${mdnew} mv ${VMBASE}.tmp ${VMBASE} } Without such prior mdconfig activity the "cp -p" and following "xz -T 0" do not get the large Meme:Active figure in top, "xz -T 0" getting more like 781M Mem:Active with a xz:SIZE of 791M and xz:RES < 800M (varying). Zero xz:SWAP. xz also gets all the cores going, so well over 300% in top always (4 cores) instead of < 100%. In this context both the cp and the xz finish just fine. In other words: no low memory problem without first having the vnode backed mdconfig use. =46rom the prior top report for the failure, partially repeated here: . . . Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free Swap: 6144M Total, 34M Used, 6110M Free, 348K Out PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 48988 root 4 31 0 651M 27048K 0K RUN 0 0:03 = 87.60% xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT- . . . The combination 1618M Mem:Active but 34M Swap:Used and 651M xz:SIZE but 27M xz:RES and 0K xz:SWAP just seems very odd, like it should not happen. The 17M Mem:Inact is odd for the context as well. (Mem:Wired, Mem:Buf, and Mem:Free look normal.) An alternate hypothesis would be the memory "leak" is from mkimg not having it memory-use cleaned up. This happens after vm_copy_base but before the cp/xz sequence and is what produces vm.raw. For reference of what worked just fine after the post-panic reboot, using the already existing vm.raw (sparse) file as a starting place: # cp -p vm.raw = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw # xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw # ls -lTt *raw* -rw-r--r-- 1 root wheel 34360566272 Apr 27 18:40:24 2017 vm.raw -rw-r--r-- 1 root wheel 34359746560 Apr 27 18:37:29 2017 = vm.raw.nested_bsd -rw-r--r-- 1 root wheel 27917287424 Apr 27 18:34:45 2017 raw.img # du -sm *raw* 1762 raw.img 1583 vm.raw 1583 vm.raw.nested_bsd (Before the .xz replaces the .raw:) # ls -lT /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/ total 33820032 -rw-r--r-- 1 root wheel 34360566272 Apr 27 18:40:24 2017 = FreeBSD-12.0-CURRENT-arm64-aarch64.raw # du -sm /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/* 32777 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw (After xz:) # ls -lT /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/ total 258208 -rw-r--r-- 1 root wheel 264275808 Apr 27 18:40:24 2017 = FreeBSD-12.0-CURRENT-arm64-aarch64.raw.xz # du -sm /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/* 253 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw.xz (Mem:Active returned to 10M when xz finished.) Prior reports from capturing text: On 2017-Apr-27, at 7:31 PM, Mark Millard wrote: > [Another example panic. Again no dump. But I have what > a top -PCwaopid froze at this time.] >=20 > On 2017-Apr-27, at 4:22 PM, Mark Millard = wrote: >=20 >> Unfortunately for this FYI the attempt to produce a dump >> failed and so all the information that I have is what I >> first captured from the console output: a backtrace. >>=20 >> The context was head -r317015 on a Pine64+ 2GB. At the >> time I was experimenting with trying to build a vm.raw >> from my own build of FreeBSD. The (root) file system >> is on a USB SSD off of a powered USB hub. >>=20 >> panic: ARM64TODO: reclaim_pv_chunk >> cpuid =3D 1 >> time =3D 1493332968 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self_wrapper+0x28 >> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc >> sp =3D 0xffff000083ba4f00 fp =3D 0xffff000083ba5110 >>=20 >> db_trace_self_wrapper() at vpanic+0x164 >> pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 >> sp =3D 0xffff000083ba5120 fp =3D 0xffff000083ba5190 >>=20 >> vpanic() at panic+0x4c >> pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc >> sp =3D 0xffff000083ba51a0 fp =3D 0xffff000083ba5220 >>=20 >> panic() at reclaim_pv_chunk+0x10 >> pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 >> sp =3D 0xffff000083ba5230 fp =3D 0xffff000083ba5230 >>=20 >> reclaim_pv_chunk() at get_pv_entry+0x240 >> pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 >> sp =3D 0xffff000083ba5240 fp =3D 0xffff000083ba5260 >>=20 >> get_pv_entry() at pmap_enter+0x694 >> pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 >> sp =3D 0xffff000083ba5270 fp =3D 0xffff000083ba5300 >>=20 >> pmap_enter() at vm_fault_hold+0x28c >> pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 >> sp =3D 0xffff000083ba5310 fp =3D 0xffff000083ba5460 >>=20 >> vm_fault_hold() at vm_fault+0x70 >> pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 >> sp =3D 0xffff000083ba5470 fp =3D 0xffff000083ba54a0 >>=20 >> vm_fault() at data_abort+0xe0 >> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >> sp =3D 0xffff000083ba54b0 fp =3D 0xffff000083ba5560 >>=20 >> data_abort() at handle_el1h_sync+0x70 >> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >> sp =3D 0xffff000083ba5570 fp =3D 0xffff000083ba5680 >>=20 >> handle_el1h_sync() at kern_select+0x9fc >> pc =3D 0xffff000000607870 lr =3D 0xffff00000037db3c >> sp =3D 0xffff000083ba5690 fp =3D 0xffff000083ba58f0 >>=20 >> kern_select() at sys_select+0x5c >> pc =3D 0xffff00000037db3c lr =3D 0xffff00000037dc58 >> sp =3D 0xffff000083ba5900 fp =3D 0xffff000083ba5930 >>=20 >> sys_select() at do_el0_sync+0xa48 >> pc =3D 0xffff00000037dc58 lr =3D 0xffff00000061b91c >> sp =3D 0xffff000083ba5940 fp =3D 0xffff000083ba5a70 >>=20 >> do_el0_sync() at handle_el0_sync+0x6c >> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >> sp =3D 0xffff000083ba5a80 fp =3D 0xffff000083ba5b90 >>=20 >> handle_el0_sync() at 0x4948c >> pc =3D 0xffff0000006079e8 lr =3D 0x000000000004948c >> sp =3D 0xffff000083ba5ba0 fp =3D 0x0000ffffffffd960 >=20 >=20 > This time I got to record from top: > (swap is on a swap partition) > (pid 49888's SIZE vs. RES and SWAP might be interesting) > (as might the Active figure) >=20 > last pid: 48988; load averages: 0.64, 0.44, 0.38 = = up 0+04:21:01 19:19:50 > 32 processes: 2 running, 30 sleeping > CPU 0: 13.2% user, 0.0% nice, 23.2% system, 0.3% interrupt, 63.3% = idle > CPU 1: 4.6% user, 0.0% nice, 23.9% system, 0.0% interrupt, 71.5% = idle > CPU 2: 2.1% user, 0.0% nice, 23.2% system, 0.0% interrupt, 74.8% = idle > CPU 3: 3.3% user, 0.0% nice, 23.8% system, 0.0% interrupt, 72.8% = idle > Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free > Swap: 6144M Total, 34M Used, 6110M Free, 348K Out >=20 > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND > 48988 root 4 31 0 651M 27048K 0K RUN 0 0:03 = 87.60% xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw > 11983 root 1 22 0 5068K 0K 0K wait 3 0:00 = 0.00% make vm-image vm-install DESTDIR=3D/usr/obj/DESTDIRs/vmimage-aarch64= () > 11981 root 1 42 0 7320K 0K 1516K wait 1 0:00 = 0.00% sh = /root/sys_build_scripts.aarch64-host/make_noscript_aarch64_nodebug_clang_b= ootstrap-aarch64-host.sh vm-image vm-install=20 > 11980 root 1 20 0 6656K 1548K 0K select 0 0:02 = 0.00% [script] > 11977 root 1 30 0 7320K 0K 1516K wait 3 0:00 = 0.00% /bin/sh = /root/sys_build_scripts.aarch64-host/make_aarch64_nodebug_clang_bootstrap-= aarch64-host.sh vm-image vm-install DEST > 2694 root 1 20 0 8804K 2072K 0K CPU2 2 0:07 = 0.17% top -PCwaopid > 827 root 1 20 0 7320K 0K 360K wait 0 0:00 = 0.00% su () > 826 markmi 1 22 0 10372K 0K 1532K wait 3 0:00 = 0.00% su () > 820 markmi 1 24 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () > 819 markmi 1 20 0 18416K 1152K 0K select 1 0:21 = 0.00% sshd: markmi@pts/1 (sshd) > 816 root 1 20 0 18416K 3276K 0K select 0 0:00 = 0.00% sshd: markmi [priv] (sshd) > 765 root 1 20 0 7320K 0K 224K wait 2 0:00 = 0.00% su () > 764 markmi 1 23 0 10372K 0K 1532K wait 0 0:00 = 0.00% su () > 758 markmi 1 31 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () > 757 markmi 1 20 0 18416K 228K 904K select 3 0:01 = 0.01% sshd: markmi@pts/0 (sshd) > 754 root 1 25 0 18416K 3276K 0K select 1 0:00 = 0.00% sshd: markmi [priv] (sshd) > 746 root 1 27 0 7320K 1532K 0K ttyin 0 0:00 = 0.00% -sh (sh) > 745 root 1 20 0 10372K 0K 1532K wait 1 0:00 = 0.00% login [pam] () > 700 root 1 20 0 6948K 0K 168K nanslp 1 0:00 = 0.00% /usr/sbin/cron -s () > 696 smmsp 1 20 0 10460K 0K 184K pause 0 0:00 = 0.00% sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue = () > 693 root 1 20 0 10460K 1392K 0K select 1 0:00 = 0.03% sendmail: accepting connections (sendmail) > 690 root 1 20 0 15800K 968K 0K select 2 0:00 = 0.00% /usr/sbin/sshd > 661 root 1 20 0 6656K 344K 0K select 2 0:01 = 0.00% /usr/sbin/powerd > 658 root 2 20 0 12788K 12672K 0K select 0 0:02 = 0.01% /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift > 620 root 32 52 0 6384K 1100K 0K rpcsvc 1 0:00 = 0.00% nfsd: server (nfsd) > 619 root 1 52 0 6384K 704K 0K select 1 0:00 = 0.00% nfsd: master (nfsd) > 617 root 1 20 0 6684K 688K 0K select 1 0:00 = 0.00% /usr/sbin/mountd -r > 478 root 1 20 0 6676K 596K 0K select 3 0:00 = 0.00% /usr/sbin/rpcbind > 469 root 1 20 0 6680K 572K 0K select 2 0:00 = 0.00% /usr/sbin/syslogd -s > 396 root 1 20 0 9580K 32K 0K select 0 0:00 = 0.00% /sbin/devd > 308 _dhcp 1 20 0 6800K 532K 0K select 2 0:00 = 0.00% dhclient: awg0 (dhclient) > 307 root 1 52 0 6800K 424K 0K select 2 0:00 = 0.00% dhclient: awg0 [priv] (dhclient) >=20 > And here is the backtrace: >=20 > timeout stopping cpus > panic: ARM64TODO: reclaim_pv_chunk > cpuid =3D 0 > time =3D 1493345992 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc > sp =3D 0xffff000083d301d0 fp =3D 0xffff000083d303e0 >=20 > db_trace_self_wrapper() at vpanic+0x164 > pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 > sp =3D 0xffff000083d303f0 fp =3D 0xffff000083d30460 >=20 > vpanic() at panic+0x4c > pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc > sp =3D 0xffff000083d30470 fp =3D 0xffff000083d304f0 >=20 > panic() at reclaim_pv_chunk+0x10 > pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 > sp =3D 0xffff000083d30500 fp =3D 0xffff000083d30500 >=20 > reclaim_pv_chunk() at get_pv_entry+0x240 > pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 > sp =3D 0xffff000083d30510 fp =3D 0xffff000083d30530 >=20 > get_pv_entry() at pmap_enter+0x694 > pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 > sp =3D 0xffff000083d30540 fp =3D 0xffff000083d305d0 >=20 > pmap_enter() at vm_fault_hold+0x28c > pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 > sp =3D 0xffff000083d305e0 fp =3D 0xffff000083d30730 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 > sp =3D 0xffff000083d30740 fp =3D 0xffff000083d30770 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff000083d30780 fp =3D 0xffff000083d30830 >=20 > data_abort() at handle_el0_sync+0x6c > pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 > sp =3D 0xffff000083d30840 fp =3D 0xffff000083d30950 >=20 > handle_el0_sync() at 0x400a3de4 > pc =3D 0xffff0000006079e8 lr =3D 0x00000000400a3de4 > sp =3D 0xffff000083d30960 fp =3D 0x0000ffffbfdfcd30 >=20 > KDB: enter: panic > [ thread pid 48988 tid 100230 ] > Stopped at kdb_enter+0x44: undefined d4200000 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Apr 28 10:03:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 598EBD54851 for ; Fri, 28 Apr 2017 10:03:16 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from fragranza.investici.org (fragranza.investici.org [IPv6:2a00:1dc0:2479::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.autistici.org", Issuer "Autistici/Inventati Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F2621A63 for ; Fri, 28 Apr 2017 10:03:15 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from [178.175.144.26] (fragranza [178.175.144.26]) (Authenticated sender: aggaz@paranoici.org) by localhost (Postfix) with ESMTPSA id D9D482C0121 for ; Fri, 28 Apr 2017 10:03:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paranoici.org; s=stigmate; t=1493373792; bh=YIbw/0LixFKGSmEpufzUQAs0t+TBHhbd+Mi+I/XpvHI=; h=To:From:Subject:Date; b=XjZ5mf1iTrcPQ5LXkKgW98TiwVNXu8RK7+FFxzVOushmL6JICA2nRv7Hhm5SA00Ys wM8UF9BoKf43mdCFGn2rVa/ZK4wODNtCGpGYZ7tVOJdLJdha6gA0LRZ5zhIvhrnhy8 gn6o2Ak+wci1cqUL0RdpiG0pjk5WSky1L/T5gf2k= To: freebsd-arm@freebsd.org From: aggaz Subject: FreeBSD 12-CURRENT on OrangePi One Message-ID: <8eae97a3-6f3d-2273-31fb-67627ce4bd15@paranoici.org> Date: Fri, 28 Apr 2017 12:03:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 10:03:16 -0000 Dear list, recently I was able to build a working FreeBSD 12-CURRENT image for OrangePi One by using crochet. This particular board is partially supported. It uses SoC H3 which is supported by FreeBSD, and there is a u-boot package available in ports. However there is no ready-made crochet-specific configuration. I am going to write here what I did, hoping that someone else will find this information useful, and hoping that crochet developers are reading this. I do not have a github account and I can not contact them on that particular portal. 1. Freebsd and crochet sources. I am using FreeBSD 12-CURRENT and last crochet, sources of both downloaded on April 26 2017. 2. OrangePi One config In crochet, I created a new board, called "OrangePi-One" using the config from "OrangePi-Plus2E" as a template. I corrected paths and a little bug on the setup.sh file, which follows: ========================================================================= % cat setup.sh KERNCONF=ALLWINNER UBLDR_LOADADDR=0x42000000 SUNXI_UBOOT="u-boot-orangepi-one" SUNXI_UBOOT_BIN="u-boot.img" IMAGE_SIZE=$((1000 * 1000 * 1000 * 2)) TARGET_ARCH=armv6 UBOOT_PATH="/usr/local/share/u-boot/${SUNXI_UBOOT}" allwinner_partition_image ( ) { echo "Installing U-Boot files" dd if=${UBOOT_PATH}/u-boot-sunxi-with-spl.bin conv=notrunc,sync of=/dev/${DISK_MD} bs=1024 seek=8 dd if=${UBOOT_PATH}/u-boot.img conv=notrunc,sync of=/dev/${DISK_MD} bs=1024 seek=40 disk_partition_mbr disk_fat_create 32m 16 1m disk_ufs_create } strategy_add $PHASE_PARTITION_LWW allwinner_partition_image allwinner_check_uboot ( ) { uboot_port_test ${SUNXI_UBOOT} ${SUNXI_UBOOT_BIN} } strategy_add $PHASE_CHECK allwinner_check_uboot strategy_add $PHASE_BUILD_OTHER freebsd_ubldr_build UBLDR_LOADADDR=${UBLDR_LOADADDR} strategy_add $PHASE_BOOT_INSTALL freebsd_ubldr_copy_ubldr . # BeagleBone puts the kernel on the FreeBSD UFS partition. strategy_add $PHASE_FREEBSD_BOARD_INSTALL board_default_installkernel . # overlay/etc/fstab mounts the FAT partition at /boot/msdos strategy_add $PHASE_FREEBSD_BOARD_INSTALL mkdir -p boot/msdos # ubldr help and config files go on the UFS partition (after boot dir exists) strategy_add $PHASE_FREEBSD_BOARD_INSTALL freebsd_ubldr_copy boot ========================================================================= basically, I am using u-boot for OrangePi One from ports (line 3, 8, 12, 13). Line 12 was causing problems, same as described by someone else here: https://github.com/freebsd/crochet/issues/191 I added the parameters "conv=notrunc,sync" and now it works. 4. DTB file There is no dtb file for OrangePi One. In a previous attempt, by using old freebsd/crochet sources, I tried to use the DTB file compiled for OrangePi-Plus2E. It was working, but it took a lot to boot (I had issues with timers apparently), and I was not able to use ethernet connection. Then I tried the DTB from NanoPi-Neo, which is also based on H3 Soc, and thing seems to work fine. So now, I basically copied the DTB file /boot/dtb/nanopi-neo.dtb to /boot/dtb/sun8i-h3-orangepi-one.dtb 5. Issuses For some reason, I can not use the GrowFS option. At boot I get errors. The following line is continuously printed and the sistem wont boot. ---- vm_fault: pager read error, pid 1 (init) ---- I will try to grow the partition manually. For the time being, this is it. Hope this report is useful, if some developer wish to use my board and my time to test stuff to make the support of this board more stable, I am available for testing. Regards Aggaz From owner-freebsd-arm@freebsd.org Fri Apr 28 10:18:47 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25267D54BA4 for ; Fri, 28 Apr 2017 10:18:47 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) 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 G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD3011EA4 for ; Fri, 28 Apr 2017 10:18:46 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x229.google.com with SMTP id f76so48873456qke.2 for ; Fri, 28 Apr 2017 03:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=M5vxM8hfKHtw4IysItOpOYEUIK2kekZ+BMx7NwotFyU=; b=LhIgZjVe7L0H4BF13jMg7Kdhe1pEvYa9YUB4hKhbjClCorPneFKYiig/vJRpvlcjjw gPxCGVGINWM5cvcOEiasSlmsfunZVa1h44rhlkgRzWkjxDCA01aI/XN2vJGDQ5vLrIpB Q745DckNQvIbwvE+qVsVg6foFFIscCQ3NO5mo= 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; bh=M5vxM8hfKHtw4IysItOpOYEUIK2kekZ+BMx7NwotFyU=; b=cEcqpG0J2sGuZ8z/ZvwU0z10saBBKRsQuij+UUemGXQntKgkUoCkHgjtoOhPDvREXz hgb9dfbq4ti0QgkyaKTD223xMoCYirJzicNsp+Z+TFjBJCkbVx1nkmUlkslVTNYIqGTM X+BoyAfDAXd4NU/8LL3iuZXG/vTVgITjJsSt7WDe5Dxc1pLTHfKUyK14yqL6usCXU8vq 8ITktzb9JN1o1HVSlvR4ouXanN7Mg+Ae7IlsjWrXRjYUmD+XwX13cB1Pxj1hPOCLdK++ sNV0ZXcZXPGzvfJCy3UyED8jmXUtZ2VIfMc9lFpi75lXIPg7mbzNfb1UKSzHlET51nm0 xkRw== X-Gm-Message-State: AN3rC/7OOv3aGe4tSRUXmthoI5/JjLCVXtxcpajZQqB+6uXMYzotkd92 X4yKcqJj5jhyZb9k X-Received: by 10.55.102.198 with SMTP id a189mr8973098qkc.249.1493374725555; Fri, 28 Apr 2017 03:18:45 -0700 (PDT) Received: from ?IPv6:2804:54:19ef:cc00:30f9:247:939:2f09? ([2804:54:19ef:cc00:30f9:247:939:2f09]) by smtp.googlemail.com with ESMTPSA id z63sm3333320qkc.6.2017.04.28.03.18.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 03:18:45 -0700 (PDT) Subject: Re: FreeBSD 12-CURRENT on OrangePi One To: freebsd-arm@freebsd.org References: <8eae97a3-6f3d-2273-31fb-67627ce4bd15@paranoici.org> From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <3e0ebfa5-65d1-d7a0-816b-a0c72b3fe15b@bsd.com.br> Date: Fri, 28 Apr 2017 07:18:41 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8eae97a3-6f3d-2273-31fb-67627ce4bd15@paranoici.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 10:18:47 -0000 Em 28/04/2017 07:03, aggaz escreveu: > Dear list, > > recently I was able to build a working FreeBSD 12-CURRENT image for > OrangePi One by using crochet. > > This particular board is partially supported. It uses SoC H3 which is > supported by FreeBSD, and there is a u-boot package available in ports. > However there is no ready-made crochet-specific configuration. > > I am going to write here what I did, hoping that someone else will find > this information useful, and hoping that crochet developers are reading > this. I do not have a github account and I can not contact them on that > particular portal. > > > 1. Freebsd and crochet sources. > I am using FreeBSD 12-CURRENT and last crochet, sources of both > downloaded on April 26 2017. > > > 2. OrangePi One config > In crochet, I created a new board, called "OrangePi-One" using the > config from "OrangePi-Plus2E" as a template. > I corrected paths and a little bug on the setup.sh file, which follows: > > ========================================================================= > % cat setup.sh > KERNCONF=ALLWINNER > UBLDR_LOADADDR=0x42000000 > SUNXI_UBOOT="u-boot-orangepi-one" > SUNXI_UBOOT_BIN="u-boot.img" > IMAGE_SIZE=$((1000 * 1000 * 1000 * 2)) > TARGET_ARCH=armv6 > > UBOOT_PATH="/usr/local/share/u-boot/${SUNXI_UBOOT}" > > allwinner_partition_image ( ) { > echo "Installing U-Boot files" > dd if=${UBOOT_PATH}/u-boot-sunxi-with-spl.bin conv=notrunc,sync > of=/dev/${DISK_MD} bs=1024 seek=8 > dd if=${UBOOT_PATH}/u-boot.img conv=notrunc,sync of=/dev/${DISK_MD} > bs=1024 seek=40 > disk_partition_mbr > disk_fat_create 32m 16 1m > disk_ufs_create > } > strategy_add $PHASE_PARTITION_LWW allwinner_partition_image > > allwinner_check_uboot ( ) { > uboot_port_test ${SUNXI_UBOOT} ${SUNXI_UBOOT_BIN} > } > strategy_add $PHASE_CHECK allwinner_check_uboot > > strategy_add $PHASE_BUILD_OTHER freebsd_ubldr_build > UBLDR_LOADADDR=${UBLDR_LOADADDR} > strategy_add $PHASE_BOOT_INSTALL freebsd_ubldr_copy_ubldr . > > # BeagleBone puts the kernel on the FreeBSD UFS partition. > strategy_add $PHASE_FREEBSD_BOARD_INSTALL board_default_installkernel . > # overlay/etc/fstab mounts the FAT partition at /boot/msdos > strategy_add $PHASE_FREEBSD_BOARD_INSTALL mkdir -p boot/msdos > # ubldr help and config files go on the UFS partition (after boot dir > exists) > strategy_add $PHASE_FREEBSD_BOARD_INSTALL freebsd_ubldr_copy boot > ========================================================================= > > basically, I am using u-boot for OrangePi One from ports (line 3, 8, 12, > 13). > Line 12 was causing problems, same as described by someone else here: > https://github.com/freebsd/crochet/issues/191 > > I added the parameters "conv=notrunc,sync" and now it works. > > > 4. DTB file > There is no dtb file for OrangePi One. > In a previous attempt, by using old freebsd/crochet sources, I tried to > use the DTB file compiled for OrangePi-Plus2E. > It was working, but it took a lot to boot (I had issues with timers > apparently), and I was not able to use ethernet connection. > Then I tried the DTB from NanoPi-Neo, which is also based on H3 Soc, and > thing seems to work fine. > So now, I basically copied the DTB file /boot/dtb/nanopi-neo.dtb to > /boot/dtb/sun8i-h3-orangepi-one.dtb > > > 5. Issuses > For some reason, I can not use the GrowFS option. At boot I get errors. > The following line is continuously printed and the sistem wont boot. > ---- > vm_fault: pager read error, pid 1 (init) > ---- > I will try to grow the partition manually. > > > For the time being, this is it. > Hope this report is useful, if some developer wish to use my board and > my time to test stuff to make the support of this board more stable, I > am available for testing. > > Regards > Aggaz I'm getting exactly this same error on RPI3 and beaglebone black (vm_fault: pager read error, pid 1 (init)). And I reported here: http://freebsd.1045724.x6.nabble.com/HEAD-on-RPI3-td6181434.html The new gotcha is your report that this is related with Growfs. Thank you by your report. Now I know that my environment is clean and I'm not crazy. []'s -Otacilio From owner-freebsd-arm@freebsd.org Fri Apr 28 12:08:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D115CD54811 for ; Fri, 28 Apr 2017 12:08:29 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2001:888:2000:56::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.autistici.org", Issuer "Autistici/Inventati Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D58E1A38 for ; Fri, 28 Apr 2017 12:08:29 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: aggaz@paranoici.org) by localhost (Postfix) with ESMTPSA id 4D6BC120832 for ; Fri, 28 Apr 2017 12:08:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paranoici.org; s=stigmate; t=1493381299; bh=6woXrsXYk/L2PDDSJ+OqMsqZ8YnfAmF5SaM4pz0wer0=; h=Subject:To:References:From:Date:In-Reply-To; b=HYwmZD5sodCnwqmWfILLNe7MGYBJPbpjwY2edSnccV+H4tkwLqZK7Mq3trxbIVEof qj1Rovwl25SU2l0QfkFoMmf6f8IchYL/ekM7Ak19wK1fskpgcFbLSnE7mhX1SYu+OW jVi39x8PSVQBOIdW8HsNrE5OAmTHghFenuOrIL88= Subject: Re: FreeBSD 12-CURRENT on OrangePi One To: freebsd-arm@freebsd.org References: From: aggaz Message-ID: Date: Fri, 28 Apr 2017 14:08:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 12:08:29 -0000 Glad it helped. To solve your problem try to disable growfs in /etc/rc.conf. Then you can grow the partition manually as described here: https://www.freebsd.org/doc/handbook/disks-growing.html If you want to do it in ssh and you get strange errors try to use growfs as a service and not as a command as described here: https://www.digitalocean.com/community/questions/freebsd-growfs-operation-not-permitted-aka-enlarge-your-partition I just did that on OrangePi One and it worked. aggaz Il 28/04/2017 14:00, freebsd-arm-request@freebsd.org ha scritto: > I'm getting exactly this same error on RPI3 and beaglebone black > (vm_fault: pager read error, pid 1 (init)). And I reported here: > > http://freebsd.1045724.x6.nabble.com/HEAD-on-RPI3-td6181434.html > > The new gotcha is your report that this is related with Growfs. Thank > you by your report. Now I know that my environment is clean and I'm not > crazy. > > []'s > -Otacilio From owner-freebsd-arm@freebsd.org Fri Apr 28 17:44:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 624CAD546CA for ; Fri, 28 Apr 2017 17:44:11 +0000 (UTC) (envelope-from rogiel@rogiel.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 G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2473C1231 for ; Fri, 28 Apr 2017 17:44:11 +0000 (UTC) (envelope-from rogiel@rogiel.com) Received: by mail-qt0-x230.google.com with SMTP id y33so55842304qta.2 for ; Fri, 28 Apr 2017 10:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogiel.com; s=google; h=date:from:to:message-id:subject:mime-version; bh=gx3+XKM/fDiSVOn0T8a2PbI2Bgk7zmO9YJ/vFSBn6Pw=; b=NZNzLVhC9m9TWcNBQPe1bgXq9HeWGP23slwhNPPo+3PGlFOd/DcaspMKhEFRLQXJiC /D4Ys/FdjD1QbFum38gvqEfM9lsjsDl1jZtXUFNPa1O8uk7KTMtzvGSHzFhhiOT/YBNh GBjtneeGMKNWPJkZbXvPfa16dKzghi2RVoajU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version; bh=gx3+XKM/fDiSVOn0T8a2PbI2Bgk7zmO9YJ/vFSBn6Pw=; b=o0LD+b4p4UDdQWLTTn0l/iIUMSupZb+FFAmx7KRpaz3zZ4yD0VDdQ54QP9bPJJJNsF yMUxglCYnFVEmaNW8qJdkRBJdz2io3GK+AJLOITqj9t/R+/lu1Jc7FD0EvVd37JpIT/s YS42WnDslHFNM1EWcZPj+e9f9XoQV61b5l0R09Bs90keDnbjX63zsCptej/U0M5e8TJZ r5f9HWXtO0mAUwyXC4UJ7D72tbU/FXoDOuMmWowKMczHltgPBRdf/1THyhrCSLkRiHjd okPnTO0UyknZ93Fwya/kquH6zSa0EPk/MsW/pjaRFaOVlq1iRDm5qsht4PbeDI1edGbe N6Bg== X-Gm-Message-State: AN3rC/7dOPYbf5Rp6b4aqABR9i0b2u3cLNc2uFp2pzk/+7L0yx+/0wli hrG28EyjjiJhbLNZJzU= X-Received: by 10.237.42.29 with SMTP id c29mr11984270qtd.113.1493401450025; Fri, 28 Apr 2017 10:44:10 -0700 (PDT) Received: from [192.168.2.149] (191-243-5-204.brasrede.psi.br. [191.243.5.204]) by smtp.gmail.com with ESMTPSA id n9sm4142977qtc.68.2017.04.28.10.44.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 10:44:09 -0700 (PDT) Date: Fri, 28 Apr 2017 14:39:12 -0300 From: Rogiel Sulzbach To: freebsd-arm@freebsd.org Message-ID: Subject: U-boot patch for Wandboard rev d1 X-Readdle-Message-ID: ffff43e8-4ead-4f03-af5b-cb4c8a4fda4e@Spark MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="59037f65_41b71efb_1e9" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 17:44:11 -0000 --59037f65_41b71efb_1e9 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Recently a new Wandboard was released and it broke the network support on FreeBSD. This new revision has a PMIC which controls the ethernet PHY. This patch will automatically reset the PHY and configure it properly for this board. These patches were taken directly from the official Wandboard u-boot fork (https://github.com/wandboard-org/uboot-imx/tree/imx_v2015.04_4.1.15_1.0.0_ga) A pull request on GitHub bsdimp/u-boot was also opened with the same patch. https://github.com/bsdimp/u-boot/pull/1 It is important to note that I only have a Wandboard Quad, so I could not test on other versions, but I don't see anything that would prevent it from working since the changes came directly from the official fork. --59037f65_41b71efb_1e9 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="u-boot-wandboard-revd1-support.patch" RnJvbSBiYzE5ZmM5NzBmYmU2MmQ3ZTE0MmU3N2ExNzY4MGRmMmUwNzkxMDc4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSaWNoYXJkIEh1IDxyaWNoYXJkLmh1QHRlY2huZXhpb24uY29t PgpEYXRlOiBNb24sIDIzIEphbiAyMDE3IDE0OjU4OjU0ICswODAwClN1YmplY3Q6IFtQQVRDSCAx LzJdIHdhbmRib2FyZDogYWRkIHdhbmRib2FyZCByZXYuRDEgc3VwcG9ydAoKd2FuZGJvYXJkIHJl di5EMSBhZGRzIFBNSUMgYW5kIHJlcGxhY2VzIGV0aGVybmV0IHBoeSBBUjgwMzEgd2l0aCBBUjgw MzUuClVwZ3JhZGUgV0lGSS9CVCBjaGlwIHRvIEJDTTQzMzkvQkNNNDM0MzAgZnJvbSBCQ000MzI5 L0JDTTQzMzAuCgojIENvbmZsaWN0czoKIwlib2FyZC93YW5kYm9hcmQvd2FuZGJvYXJkLmMKIwlp bmNsdWRlL2NvbmZpZ3Mvd2FuZGJvYXJkLmgKLS0tCiBib2FyZC93YW5kYm9hcmQvd2FuZGJvYXJk LmMgfCAxNjcgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0KIGlu Y2x1ZGUvY29uZmlncy93YW5kYm9hcmQuaCB8ICAzMSArKysrKysrKwogMiBmaWxlcyBjaGFuZ2Vk LCAxODYgaW5zZXJ0aW9ucygrKSwgMTIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvYm9hcmQv d2FuZGJvYXJkL3dhbmRib2FyZC5jIGIvYm9hcmQvd2FuZGJvYXJkL3dhbmRib2FyZC5jCmluZGV4 IDJjOWRjOGIuLjdmZDQ0ZGQgMTAwNjQ0Ci0tLSBhL2JvYXJkL3dhbmRib2FyZC93YW5kYm9hcmQu YworKysgYi9ib2FyZC93YW5kYm9hcmQvd2FuZGJvYXJkLmMKQEAgLTMwLDYgKzMwLDggQEAKICNp bmNsdWRlIDxwaHkuaD4KICNpbmNsdWRlIDxpbnB1dC5oPgogI2luY2x1ZGUgPGkyYy5oPgorI2lu Y2x1ZGUgPHBvd2VyL3BtaWMuaD4KKyNpbmNsdWRlIDxwb3dlci9wZnV6ZTEwMF9wbWljLmg+CiAK IERFQ0xBUkVfR0xPQkFMX0RBVEFfUFRSOwogCkBAIC01Myw2ICs1NSw4IEBAIERFQ0xBUkVfR0xP QkFMX0RBVEFfUFRSOwogI2RlZmluZSBFVEhfUEhZX1JFU0VUCQlJTVhfR1BJT19OUigzLCAyOSkK ICNkZWZpbmUgUkVWX0RFVEVDVElPTgkJSU1YX0dQSU9fTlIoMiwgMjgpCiAKK3N0YXRpYyBib29s IHdpdGhfcG1pYyA9IGZhbHNlOworCiBpbnQgZHJhbV9pbml0KHZvaWQpCiB7CiAJZ2QtPnJhbV9z aXplID0gaW14X2Rkcl9zaXplKCk7CkBAIC0xMjAsNyArMTI0LDcgQEAgc3RhdGljIHZvaWQgc2V0 dXBfaW9tdXhfZW5ldCh2b2lkKQogewogCVNFVFVQX0lPTVVYX1BBRFMoZW5ldF9wYWRzKTsKIAot CS8qIFJlc2V0IEFSODAzMSBQSFkgKi8KKwkvKiBSZXNldCBBUjgwMzEvQVI4MDM1IFBIWSAqLwog CWdwaW9fZGlyZWN0aW9uX291dHB1dChFVEhfUEhZX1JFU0VULCAwKTsKIAltZGVsYXkoMTApOwog CWdwaW9fc2V0X3ZhbHVlKEVUSF9QSFlfUkVTRVQsIDEpOwpAQCAtMTkzLDE0ICsxOTcsMjEgQEAg c3RhdGljIGludCBhcjgwMzFfcGh5X2ZpeHVwKHN0cnVjdCBwaHlfZGV2aWNlICpwaHlkZXYpCiB7 CiAJdW5zaWduZWQgc2hvcnQgdmFsOwogCi0JLyogVG8gZW5hYmxlIEFSODAzMSBvdXB1dCBhIDEy NU1IeiBjbGsgZnJvbSBDTEtfMjVNICovCisJLyogVG8gZW5hYmxlIEFSODAzMS9BUjgwMzUgb3Vw dXQgYSAxMjVNSHogY2xrIGZyb20gQ0xLXzI1TSAqLwogCXBoeV93cml0ZShwaHlkZXYsIE1ESU9f REVWQURfTk9ORSwgMHhkLCAweDcpOwogCXBoeV93cml0ZShwaHlkZXYsIE1ESU9fREVWQURfTk9O RSwgMHhlLCAweDgwMTYpOwogCXBoeV93cml0ZShwaHlkZXYsIE1ESU9fREVWQURfTk9ORSwgMHhk LCAweDQwMDcpOwogCiAJdmFsID0gcGh5X3JlYWQocGh5ZGV2LCBNRElPX0RFVkFEX05PTkUsIDB4 ZSk7Ci0JdmFsICY9IDB4ZmZlMzsKLQl2YWwgfD0gMHgxODsKKwlpZiAod2l0aF9wbWljKSB7CisJ CS8qIEFSODAzNSAqLworCQl2YWwgJj0gMHhmZmU3OworCQl2YWwgfD0gMHgxODsKKwl9IGVsc2Ug eworCQkvKiBBUjgwMzEgKi8KKwkJdmFsICY9IDB4ZmZlMzsKKwkJdmFsIHw9IDB4MTg7CisJfQog CXBoeV93cml0ZShwaHlkZXYsIE1ESU9fREVWQURfTk9ORSwgMHhlLCB2YWwpOwogCiAJLyogaW50 cm9kdWNlIHR4IGNsb2NrIGRlbGF5ICovCkBAIC0yMjIsNiArMjMzLDc0IEBAIGludCBib2FyZF9w aHlfY29uZmlnKHN0cnVjdCBwaHlfZGV2aWNlICpwaHlkZXYpCiAJcmV0dXJuIDA7CiB9CiAKK3N0 cnVjdCBpMmNfcGFkc19pbmZvIG14NnFfaTJjMV9wYWRfaW5mbyA9IHsKKwkuc2NsID0geworCQku aTJjX21vZGUgPSBNWDZRX1BBRF9FSU1fRDIxX19JMkMxX1NDTAorCQkJfCBNVVhfUEFEX0NUUkwo STJDX1BBRF9DVFJMKSwKKwkJLmdwaW9fbW9kZSA9IE1YNlFfUEFEX0VJTV9EMjFfX0dQSU8zX0lP MjEKKwkJCXwgTVVYX1BBRF9DVFJMKEkyQ19QQURfQ1RSTCksCisJCS5ncCA9IElNWF9HUElPX05S KDMsIDIxKQorCX0sCisJLnNkYSA9IHsKKwkJLmkyY19tb2RlID0gTVg2UV9QQURfRUlNX0QyOF9f STJDMV9TREEKKwkJCXwgTVVYX1BBRF9DVFJMKEkyQ19QQURfQ1RSTCksCisJCS5ncGlvX21vZGUg PSBNWDZRX1BBRF9FSU1fRDI4X19HUElPM19JTzI4CisJCQl8IE1VWF9QQURfQ1RSTChJMkNfUEFE X0NUUkwpLAorCQkuZ3AgPSBJTVhfR1BJT19OUigzLCAyOCkKKwl9Cit9OworCitzdHJ1Y3QgaTJj X3BhZHNfaW5mbyBteDZkbF9pMmMxX3BhZF9pbmZvID0geworCS5zY2wgPSB7CisJCS5pMmNfbW9k ZSA9IE1YNkRMX1BBRF9FSU1fRDIxX19JMkMxX1NDTAorCQkJfCBNVVhfUEFEX0NUUkwoSTJDX1BB RF9DVFJMKSwKKwkJLmdwaW9fbW9kZSA9IE1YNkRMX1BBRF9FSU1fRDIxX19HUElPM19JTzIxCisJ CQl8IE1VWF9QQURfQ1RSTChJMkNfUEFEX0NUUkwpLAorCQkuZ3AgPSBJTVhfR1BJT19OUigzLCAy MSkKKwl9LAorCS5zZGEgPSB7CisJCS5pMmNfbW9kZSA9IE1YNkRMX1BBRF9FSU1fRDI4X19JMkMx X1NEQQorCQkJfCBNVVhfUEFEX0NUUkwoSTJDX1BBRF9DVFJMKSwKKwkJLmdwaW9fbW9kZSA9IE1Y NkRMX1BBRF9FSU1fRDI4X19HUElPM19JTzI4CisJCQl8IE1VWF9QQURfQ1RSTChJMkNfUEFEX0NU UkwpLAorCQkuZ3AgPSBJTVhfR1BJT19OUigzLCAyOCkKKwl9Cit9OworCitzdHJ1Y3QgaTJjX3Bh ZHNfaW5mbyBteDZxX2kyYzNfcGFkX2luZm8gPSB7CisJLnNjbCA9IHsKKwkJLmkyY19tb2RlID0g TVg2UV9QQURfR1BJT181X19JMkMzX1NDTAorCQkJfCBNVVhfUEFEX0NUUkwoSTJDX1BBRF9DVFJM KSwKKwkJLmdwaW9fbW9kZSA9IE1YNlFfUEFEX0dQSU9fNV9fR1BJTzFfSU8wNQorCQkJfCBNVVhf UEFEX0NUUkwoSTJDX1BBRF9DVFJMKSwKKwkJLmdwID0gSU1YX0dQSU9fTlIoMSwgNSkKKwl9LAor CS5zZGEgPSB7CisJCS5pMmNfbW9kZSA9IE1YNlFfUEFEX0dQSU9fMTZfX0kyQzNfU0RBCisJCQl8 IE1VWF9QQURfQ1RSTChJMkNfUEFEX0NUUkwpLAorCQkuZ3Bpb19tb2RlID0gTVg2UV9QQURfR1BJ T18xNl9fR1BJTzdfSU8xMQorCQkJfCBNVVhfUEFEX0NUUkwoSTJDX1BBRF9DVFJMKSwKKwkJLmdw ID0gSU1YX0dQSU9fTlIoNywgMTEpCisJfQorfTsKKworc3RydWN0IGkyY19wYWRzX2luZm8gbXg2 ZGxfaTJjM19wYWRfaW5mbyA9IHsKKwkuc2NsID0geworCQkuaTJjX21vZGUgPSBNWDZETF9QQURf R1BJT181X19JMkMzX1NDTAorCQkJfCBNVVhfUEFEX0NUUkwoSTJDX1BBRF9DVFJMKSwKKwkJLmdw aW9fbW9kZSA9IE1YNkRMX1BBRF9HUElPXzVfX0dQSU8xX0lPMDUKKwkJCXwgTVVYX1BBRF9DVFJM KEkyQ19QQURfQ1RSTCksCisJCS5ncCA9IElNWF9HUElPX05SKDEsIDUpCisJfSwKKwkuc2RhID0g eworCQkuaTJjX21vZGUgPSBNWDZETF9QQURfR1BJT18xNl9fSTJDM19TREEKKwkJCXwgTVVYX1BB RF9DVFJMKEkyQ19QQURfQ1RSTCksCisJCS5ncGlvX21vZGUgPSBNWDZETF9QQURfR1BJT18xNl9f R1BJTzdfSU8xMQorCQkJfCBNVVhfUEFEX0NUUkwoSTJDX1BBRF9DVFJMKSwKKwkJLmdwID0gSU1Y X0dQSU9fTlIoNywgMTEpCisJfQorfTsKKwogI2lmIGRlZmluZWQoQ09ORklHX1ZJREVPX0lQVVYz KQogc3RydWN0IGkyY19wYWRzX2luZm8gbXg2cV9pMmMyX3BhZF9pbmZvID0gewogCS5zY2wgPSB7 CkBAIC0yODUsNiArMzY0LDQxIEBAIHN0YXRpYyBpb211eF92M19jZmdfdCBjb25zdCBmd2FkYXB0 Xzd3dmdhX3BhZHNbXSA9IHsKIAlJT01VWF9QQURTKFBBRF9TRDRfREFUM19fR1BJTzJfSU8xMSB8 IE1VWF9QQURfQ1RSTChOT19QQURfQ1RSTCkpLCAvKiBESVNQMF9WRERFTiAqLwogfTsKIAorc3Rh dGljIHZvaWQgc2V0dXBfaW9tdXhfaTJjKHZvaWQpCit7CisJaWYgKGlzX2NwdV90eXBlKE1YQ19D UFVfTVg2USkgfHwgaXNfY3B1X3R5cGUoTVhDX0NQVV9NWDZEKSkgeworCQlzZXR1cF9pMmMoMSwg Q09ORklHX1NZU19JMkNfU1BFRUQsIDB4N2YsICZteDZxX2kyYzJfcGFkX2luZm8pOworCQlzZXR1 cF9pMmMoMiwgQ09ORklHX1NZU19JMkNfU1BFRUQsIDB4N2YsICZteDZxX2kyYzNfcGFkX2luZm8p OworCX0gZWxzZSB7CisJCXNldHVwX2kyYygxLCBDT05GSUdfU1lTX0kyQ19TUEVFRCwgMHg3Ziwg Jm14NmRsX2kyYzJfcGFkX2luZm8pOworCQlzZXR1cF9pMmMoMiwgQ09ORklHX1NZU19JMkNfU1BF RUQsIDB4N2YsICZteDZkbF9pMmMzX3BhZF9pbmZvKTsKKwl9Cit9CisKKy8qIHNldHVwIGJvYXJk IHNwZWNpZmljIFBNSUMgKi8KK2ludCBwb3dlcl9pbml0X2JvYXJkKHZvaWQpCit7CisJc3RydWN0 IHBtaWMgKnA7CisJdTMyIHJlZzsKKworCS8qIGNvbmZpZ3VyZSBQRlVaRTEwMCBQTUlDICovCisJ cG93ZXJfcGZ1emUxMDBfaW5pdChDT05GSUdfSTJDX1BNSUMpOworCXAgPSBwbWljX2dldCgiUEZV WkUxMDAiKTsKKwlpZiAocCAmJiAhcG1pY19wcm9iZShwKSkgeworCQlwbWljX3JlZ19yZWFkKHAs IFBGVVpFMTAwX0RFVklDRUlELCAmcmVnKTsKKwkJcHJpbnRmKCJQTUlDOiAgUEZVWkUxMDAgSUQ9 MHglMDJ4XG4iLCByZWcpOworCQl3aXRoX3BtaWMgPSB0cnVlOworCisJCS8qIFNldCBWR0VOMiB0 byAxLjVWIGFuZCBlbmFibGUgKi8KKwkJcG1pY19yZWdfcmVhZChwLCBQRlVaRTEwMF9WR0VOMlZP TCwgJnJlZyk7CisJCXJlZyAmPSB+KExET19WT0xfTUFTSyk7CisJCXJlZyB8PSAoTERPQV8xXzUw ViB8ICgxIDw8IChMRE9fRU4pKSk7CisJCXBtaWNfcmVnX3dyaXRlKHAsIFBGVVpFMTAwX1ZHRU4y Vk9MLCByZWcpOworCX0KKworCXJldHVybiAwOworfQorCiBzdGF0aWMgdm9pZCBkb19lbmFibGVf aGRtaShzdHJ1Y3QgZGlzcGxheV9pbmZvX3QgY29uc3QgKmRldikKIHsKIAlpbXhfZW5hYmxlX2hk bWlfcGh5KCk7CkBAIC0yOTYsNiArNDEwLDI0IEBAIHN0YXRpYyBpbnQgZGV0ZWN0X2kyYyhzdHJ1 Y3QgZGlzcGxheV9pbmZvX3QgY29uc3QgKmRldikKIAkJCSgwID09IGkyY19wcm9iZShkZXYtPmFk ZHIpKTsKIH0KIAorc3RhdGljIHZvaWQgZW5hYmxlX2x2ZHMoc3RydWN0IGRpc3BsYXlfaW5mb190 IGNvbnN0ICpkZXYpCit7CisJc3RydWN0IGlvbXV4YyAqaW9tdXggPSAoc3RydWN0IGlvbXV4YyAq KQorCQkJCUlPTVVYQ19CQVNFX0FERFI7CisKKwkvKiBzZXQgQ0gwIGRhdGEgd2lkdGggdG8gMjRi aXQgKElPTVVYQ19HUFIyOjUgMD0xOGJpdCwgMT0yNGJpdCkgKi8KKwl1MzIgcmVnID0gcmVhZGwo JmlvbXV4LT5ncHJbMl0pOworCXJlZyB8PSBJT01VWENfR1BSMl9EQVRBX1dJRFRIX0NIMF8yNEJJ VDsKKwl3cml0ZWwocmVnLCAmaW9tdXgtPmdwclsyXSk7CisKKwkvKiBFbmFibGUgQmFja2xpZ2h0 IC0gdXNlIEdQSU8gZm9yIEJyaWdodG5lc3MgYWRqdXN0bWVudCAqLworCVNFVFVQX0lPTVVYX1BB RChQQURfU0Q0X0RBVDFfX0dQSU8yX0lPMDkpOworCWdwaW9fZGlyZWN0aW9uX291dHB1dChJTVhf R1BJT19OUigyLCA5KSwgMSk7CisKKwlTRVRVUF9JT01VWF9QQUQoUEFEX1NENF9EQVQwX19HUElP Ml9JTzA4KTsKKwlncGlvX2RpcmVjdGlvbl9vdXRwdXQoSU1YX0dQSU9fTlIoMiwgOCksIDEpOwor fQorCiBzdGF0aWMgdm9pZCBlbmFibGVfZndhZGFwdF83d3ZnYShzdHJ1Y3QgZGlzcGxheV9pbmZv X3QgY29uc3QgKmRldikKIHsKIAlTRVRVUF9JT01VWF9QQURTKGZ3YWRhcHRfN3d2Z2FfcGFkcyk7 CkBAIC0zNTUsNiArNDg3LDEwIEBAIHN0YXRpYyB2b2lkIHNldHVwX2Rpc3BsYXkodm9pZCkKIAll bmFibGVfaXB1X2Nsb2NrKCk7CiAJaW14X3NldHVwX2hkbWkoKTsKIAorCXJlZyA9IHJlYWRsKCZt eGNfY2NtLT5jc2NtcjIpOworCXJlZyB8PSBNWENfQ0NNX0NTQ01SMl9MREJfREkwX0lQVV9ESVY7 CisJd3JpdGVsKHJlZywgJm14Y19jY20tPmNzY21yMik7CisKIAlyZWcgPSByZWFkbCgmbXhjX2Nj bS0+Y2hzY2Nkcik7CiAJcmVnIHw9IChDSFNDQ0RSX0NMS19TRUxfTERCX0RJMAogCQk8PCBNWENf Q0NNX0NIU0NDRFJfSVBVMV9ESTBfQ0xLX1NFTF9PRkZTRVQpOwpAQCAtNDE3LDYgKzU1MywxNCBA QCBzdGF0aWMgYm9vbCBpc19yZXZjMSh2b2lkKQogCQlyZXR1cm4gZmFsc2U7CiB9CiAKK3N0YXRp YyBib29sIGlzX3JldmQxKHZvaWQpCit7CisJaWYgKHdpdGhfcG1pYykKKwkJcmV0dXJuIHRydWU7 CisJZWxzZQorCQlyZXR1cm4gZmFsc2U7Cit9CisKIGludCBib2FyZF9sYXRlX2luaXQodm9pZCkK IHsKICNpZmRlZiBDT05GSUdfQ01EX0JNT0RFCkBAIC00MjksNyArNTczLDkgQEAgaW50IGJvYXJk X2xhdGVfaW5pdCh2b2lkKQogCWVsc2UKIAkJc2V0ZW52KCJib2FyZF9yZXYiLCAiTVg2REwiKTsK IAotCWlmIChpc19yZXZjMSgpKQorCWlmIChpc19yZXZkMSgpKQorCQlzZXRlbnYoImJvYXJkX25h bWUiLCAiRDEiKTsKKwllbHNlIGlmIChpc19yZXZjMSgpKQogCQlzZXRlbnYoImJvYXJkX25hbWUi LCAiQzEiKTsKIAllbHNlCiAJCXNldGVudigiYm9hcmRfbmFtZSIsICJCMSIpOwpAQCAtNDQyLDEy ICs1ODgsNyBAQCBpbnQgYm9hcmRfaW5pdCh2b2lkKQogCS8qIGFkZHJlc3Mgb2YgYm9vdCBwYXJh bWV0ZXJzICovCiAJZ2QtPmJkLT5iaV9ib290X3BhcmFtcyA9IFBIWVNfU0RSQU0gKyAweDEwMDsK IAotI2lmIGRlZmluZWQoQ09ORklHX1ZJREVPX0lQVVYzKQotCXNldHVwX2kyYygxLCBDT05GSUdf U1lTX0kyQ19TUEVFRCwgMHg3ZiwgJm14NmRsX2kyYzJfcGFkX2luZm8pOwotCWlmIChpc19teDZk cSgpKQotCQlzZXR1cF9pMmMoMSwgQ09ORklHX1NZU19JMkNfU1BFRUQsIDB4N2YsICZteDZxX2ky YzJfcGFkX2luZm8pOwotCWVsc2UKLQkJc2V0dXBfaTJjKDEsIENPTkZJR19TWVNfSTJDX1NQRUVE LCAweDdmLCAmbXg2ZGxfaTJjMl9wYWRfaW5mbyk7CisJc2V0dXBfaW9tdXhfaTJjKCk7CiAjZW5k aWYKIAogCXJldHVybiAwOwpAQCAtNDU1LDcgKzU5Niw5IEBAIGludCBib2FyZF9pbml0KHZvaWQp CiAKIGludCBjaGVja2JvYXJkKHZvaWQpCiB7Ci0JaWYgKGlzX3JldmMxKCkpCisJaWYgKGlzX3Jl dmQxKCkpCisJCXB1dHMoIkJvYXJkOiBXYW5kYm9hcmQgcmV2IEQxXG4iKTsKKwllbHNlIGlmIChp c19yZXZjMSgpKQogCQlwdXRzKCJCb2FyZDogV2FuZGJvYXJkIHJldiBDMVxuIik7CiAJZWxzZQog CQlwdXRzKCJCb2FyZDogV2FuZGJvYXJkIHJldiBCMVxuIik7CmRpZmYgLS1naXQgYS9pbmNsdWRl L2NvbmZpZ3Mvd2FuZGJvYXJkLmggYi9pbmNsdWRlL2NvbmZpZ3Mvd2FuZGJvYXJkLmgKaW5kZXgg NDA2NTkxYy4uZDRhNDc5ZSAxMDA2NDQKLS0tIGEvaW5jbHVkZS9jb25maWdzL3dhbmRib2FyZC5o CisrKyBiL2luY2x1ZGUvY29uZmlncy93YW5kYm9hcmQuaApAQCAtMTcsNiArMTcsMTQgQEAKICNk ZWZpbmUgTUFDSF9UWVBFX1dBTkRCT0FSRAkJNDQxMgogI2RlZmluZSBDT05GSUdfTUFDSF9UWVBF CQlNQUNIX1RZUEVfV0FOREJPQVJECiAKKyNkZWZpbmUgQ09ORklHX0NNRExJTkVfVEFHCisjZGVm aW5lIENPTkZJR19TRVRVUF9NRU1PUllfVEFHUworI2RlZmluZSBDT05GSUdfSU5JVFJEX1RBRwor I2RlZmluZSBDT05GSUdfUkVWSVNJT05fVEFHCisKKyNkZWZpbmUgQ09ORklHX1NZU19HRU5FUklD X0JPQVJECisjdW5kZWYgQ09ORklHX0xET19CWVBBU1NfQ0hFQ0sKKwogLyogU2l6ZSBvZiBtYWxs b2MoKSBwb29sICovCiAjZGVmaW5lIENPTkZJR19TWVNfTUFMTE9DX0xFTgkJKDEwICogU1pfMU0p CiAKQEAgLTI3LDYgKzM1LDEyIEBACiAjZGVmaW5lIENPTkZJR19NWENfVUFSVF9CQVNFCQlVQVJU MV9CQVNFCiAKIC8qIFNBVEEgQ29uZmlncyAqLworI2RlZmluZSBDT05GSUdfRU5WX09WRVJXUklU RQorI2RlZmluZSBDT05GSUdfQ09OU19JTkRFWAkJMQorI2RlZmluZSBDT05GSUdfQkFVRFJBVEUJ CQkxMTUyMDAKKworLyogQ29tbWFuZCBkZWZpbml0aW9uICovCisjaW5jbHVkZSA8Y29uZmlnX2Nt ZF9kZWZhdWx0Lmg+CiAKICNkZWZpbmUgQ09ORklHX0NNRF9TQVRBCiAjaWZkZWYgQ09ORklHX0NN RF9TQVRBCkBAIC00MCw2ICs1NCw5IEBACiAKIC8qIENvbW1hbmQgZGVmaW5pdGlvbiAqLwogI2Rl ZmluZSBDT05GSUdfQ01EX0JNT0RFCisjZGVmaW5lIENPTkZJR19DTURfU0VURVhQUgorCisjZGVm aW5lIENPTkZJR19CT09UREVMQVkJCTEKIAogI2RlZmluZSBDT05GSUdfU1lTX01FTVRFU1RfU1RB UlQJMHgxMDAwMDAwMAogI2RlZmluZSBDT05GSUdfU1lTX01FTVRFU1RfRU5ECQkoQ09ORklHX1NZ U19NRU1URVNUX1NUQVJUICsgNTAwICogU1pfMU0pCkBAIC01MSw2ICs2OCwxMyBAQAogI2RlZmlu ZSBDT05GSUdfU1lTX0kyQ19NWENfSTJDMgkJLyogZW5hYmxlIEkyQyBidXMgMiAqLwogI2RlZmlu ZSBDT05GSUdfU1lTX0kyQ19NWENfSTJDMwkJLyogZW5hYmxlIEkyQyBidXMgMyAqLwogI2RlZmlu ZSBDT05GSUdfU1lTX0kyQ19TUEVFRAkJMTAwMDAwCisjZGVmaW5lIENPTkZJR19JMkNfUE1JQwkJ CTIKKworLyogUE1JQyAqLworI2RlZmluZSBDT05GSUdfUE9XRVIKKyNkZWZpbmUgQ09ORklHX1BP V0VSX0kyQworI2RlZmluZSBDT05GSUdfUE9XRVJfUEZVWkUxMDAKKyNkZWZpbmUgQ09ORklHX1BP V0VSX1BGVVpFMTAwX0kyQ19BRERSCTB4MDgKIAogLyogTU1DIENvbmZpZ3VyYXRpb24gKi8KICNk ZWZpbmUgQ09ORklHX1NZU19GU0xfVVNESENfTlVNCTIKQEAgLTExNCw2ICsxMzgsMTAgQEAKIAkJ CSJmaTsgIglcCiAJCSJmaVwwIiBcCiAJImZpbmRmZHQ9IlwKKwkJImlmIHRlc3QgJGJvYXJkX25h bWUgPSBEMSAmJiB0ZXN0ICRib2FyZF9yZXYgPSBNWDZRIDsgdGhlbiAiIFwKKwkJCSJzZXRlbnYg ZmR0ZmlsZSBpbXg2cS13YW5kYm9hcmQtcmV2ZDEuZHRiOyBmaTsgIiBcCisJCSJpZiB0ZXN0ICRi b2FyZF9uYW1lID0gRDEgJiYgdGVzdCAkYm9hcmRfcmV2ID0gTVg2REwgOyB0aGVuICIgXAorCQkJ InNldGVudiBmZHRmaWxlIGlteDZkbC13YW5kYm9hcmQtcmV2ZDEuZHRiOyBmaTsgIiBcCiAJCSJp ZiB0ZXN0ICRib2FyZF9uYW1lID0gQzEgJiYgdGVzdCAkYm9hcmRfcmV2ID0gTVg2USA7IHRoZW4g IiBcCiAJCQkic2V0ZW52IGZkdGZpbGUgaW14NnEtd2FuZGJvYXJkLmR0YjsgZmk7ICIgXAogCQki aWYgdGVzdCAkYm9hcmRfbmFtZSA9IEMxICYmIHRlc3QgJGJvYXJkX3JldiA9IE1YNkRMIDsgdGhl biAiIFwKQEAgLTE1Nyw2ICsxODUsOSBAQAogI2RlZmluZSBDT05GSUdfU1lTX0lOSVRfU1BfQURE UiBcCiAJKENPTkZJR19TWVNfSU5JVF9SQU1fQUREUiArIENPTkZJR19TWVNfSU5JVF9TUF9PRkZT RVQpCiAKKy8qIEZMQVNIIGFuZCBlbnZpcm9ubWVudCBvcmdhbml6YXRpb24gKi8KKyNkZWZpbmUg Q09ORklHX1NZU19OT19GTEFTSAorCiAvKiBFbnZpcm9ubWVudCBvcmdhbml6YXRpb24gKi8KICNk ZWZpbmUgQ09ORklHX0VOVl9TSVpFCQkJKDggKiAxMDI0KQogCgpGcm9tIDY5ZGEzM2RjODIzMGUy OWZmODI3NDMyNDUxMTZjMjA2MjljOTAzZTkgTW9uIFNlcCAxNyAwMDowMDowMCAyMDAxCkZyb206 IFJpY2hhcmQgSHUgPHJpY2hhcmQuaHVAdGVjaG5leGlvbi5jb20+CkRhdGU6IE1vbiwgMTMgRmVi IDIwMTcgMTg6MzQ6MjMgKzA4MDAKU3ViamVjdDogW1BBVENIIDIvMl0gd2FuZGJvYXJkOiBhZGQg dUVudi50eHQgc3VwcG9ydAoKIyBDb25mbGljdHM6CiMJaW5jbHVkZS9jb25maWdzL3dhbmRib2Fy ZC5oCi0tLQogYm9hcmQvd2FuZGJvYXJkL3dhbmRib2FyZC5jIHwgMTYgKysrKysrKysrKysrKyst LQogaW5jbHVkZS9jb25maWdzL3dhbmRib2FyZC5oIHwgMTIgKysrKy0tLS0tLS0tCiAyIGZpbGVz IGNoYW5nZWQsIDE4IGluc2VydGlvbnMoKyksIDEwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBh L2JvYXJkL3dhbmRib2FyZC93YW5kYm9hcmQuYyBiL2JvYXJkL3dhbmRib2FyZC93YW5kYm9hcmQu YwppbmRleCA3ZmQ0NGRkLi4xY2I0MDM2IDEwMDY0NAotLS0gYS9ib2FyZC93YW5kYm9hcmQvd2Fu ZGJvYXJkLmMKKysrIGIvYm9hcmQvd2FuZGJvYXJkL3dhbmRib2FyZC5jCkBAIC01Myw2ICs1Myw3 IEBAIERFQ0xBUkVfR0xPQkFMX0RBVEFfUFRSOwogI2RlZmluZSBVU0RIQzFfQ0RfR1BJTwkJSU1Y X0dQSU9fTlIoMSwgMikKICNkZWZpbmUgVVNESEMzX0NEX0dQSU8JCUlNWF9HUElPX05SKDMsIDkp CiAjZGVmaW5lIEVUSF9QSFlfUkVTRVQJCUlNWF9HUElPX05SKDMsIDI5KQorI2RlZmluZSBFVEhf UEhZX0FSODAzNV9QT1dFUglJTVhfR1BJT19OUig3LCAxMykKICNkZWZpbmUgUkVWX0RFVEVDVElP TgkJSU1YX0dQSU9fTlIoMiwgMjgpCiAKIHN0YXRpYyBib29sIHdpdGhfcG1pYyA9IGZhbHNlOwpA QCAtMTA3LDEwICsxMDgsMTUgQEAgc3RhdGljIGlvbXV4X3YzX2NmZ190IGNvbnN0IGVuZXRfcGFk c1tdID0gewogCUlPTVVYX1BBRFMoUEFEX1JHTUlJX1JEMl9fUkdNSUlfUkQyICB8IE1VWF9QQURf Q1RSTChFTkVUX1BBRF9DVFJMKSksCiAJSU9NVVhfUEFEUyhQQURfUkdNSUlfUkQzX19SR01JSV9S RDMgIHwgTVVYX1BBRF9DVFJMKEVORVRfUEFEX0NUUkwpKSwKIAlJT01VWF9QQURTKFBBRF9SR01J SV9SWF9DVExfX1JHTUlJX1JYX0NUTCB8IE1VWF9QQURfQ1RSTChFTkVUX1BBRF9DVFJMKSksCi0J LyogQVI4MDMxIFBIWSBSZXNldCAqLworCS8qIEFSODAzMS9BUjgwMzUgUEhZIFJlc2V0ICovCiAJ SU9NVVhfUEFEUyhQQURfRUlNX0QyOV9fR1BJTzNfSU8yOSAgICB8IE1VWF9QQURfQ1RSTChOT19Q QURfQ1RSTCkpLAogfTsKIAorc3RhdGljIGlvbXV4X3YzX2NmZ190IGNvbnN0IGVuZXRfYXI4MDM1 X3Bvd2VyX3BhZHNbXSA9IHsKKwkvKiBBUjgwMzUgUE9XRVIgKi8KKwlJT01VWF9QQURTKFBBRF9H UElPXzE4X19HUElPN19JTzEzICAgIHwgTVVYX1BBRF9DVFJMKE5PX1BBRF9DVFJMKSksCit9Owor CiBzdGF0aWMgaW9tdXhfdjNfY2ZnX3QgY29uc3QgcmV2X2RldGVjdGlvbl9wYWRbXSA9IHsKIAlJ T01VWF9QQURTKFBBRF9FSU1fRUIwX19HUElPMl9JTzI4ICB8IE1VWF9QQURfQ1RSTChOT19QQURf Q1RSTCkpLAogfTsKQEAgLTEyNCw2ICsxMzAsMTMgQEAgc3RhdGljIHZvaWQgc2V0dXBfaW9tdXhf ZW5ldCh2b2lkKQogewogCVNFVFVQX0lPTVVYX1BBRFMoZW5ldF9wYWRzKTsKIAorCWlmICh3aXRo X3BtaWMpIHsKKwkJU0VUVVBfSU9NVVhfUEFEUyhlbmV0X2FyODAzNV9wb3dlcl9wYWRzKTsKKwkJ LyogZW5hYmxlIEFSODAzNSBQT1dFUiAqLworCQlncGlvX2RpcmVjdGlvbl9vdXRwdXQoRVRIX1BI WV9BUjgwMzVfUE9XRVIsIDApOworCX0KKwkvKiB3YWl0IHVudGlsIDMuM1Ygb2YgUEhZIGFuZCBj bG9jayBiZWNvbWUgc3RhYmxlICovCisJbWRlbGF5KDEwKTsKIAkvKiBSZXNldCBBUjgwMzEvQVI4 MDM1IFBIWSAqLwogCWdwaW9fZGlyZWN0aW9uX291dHB1dChFVEhfUEhZX1JFU0VULCAwKTsKIAlt ZGVsYXkoMTApOwpAQCAtNTg5LDcgKzYwMiw2IEBAIGludCBib2FyZF9pbml0KHZvaWQpCiAJZ2Qt PmJkLT5iaV9ib290X3BhcmFtcyA9IFBIWVNfU0RSQU0gKyAweDEwMDsKIAogCXNldHVwX2lvbXV4 X2kyYygpOwotI2VuZGlmCiAKIAlyZXR1cm4gMDsKIH0KZGlmZiAtLWdpdCBhL2luY2x1ZGUvY29u Zmlncy93YW5kYm9hcmQuaCBiL2luY2x1ZGUvY29uZmlncy93YW5kYm9hcmQuaAppbmRleCBkNGE0 NzllLi4zODQ1OTlhIDEwMDY0NAotLS0gYS9pbmNsdWRlL2NvbmZpZ3Mvd2FuZGJvYXJkLmgKKysr IGIvaW5jbHVkZS9jb25maWdzL3dhbmRib2FyZC5oCkBAIC0zOSw5ICszOSw2IEBACiAjZGVmaW5l IENPTkZJR19DT05TX0lOREVYCQkxCiAjZGVmaW5lIENPTkZJR19CQVVEUkFURQkJCTExNTIwMAog Ci0vKiBDb21tYW5kIGRlZmluaXRpb24gKi8KLSNpbmNsdWRlIDxjb25maWdfY21kX2RlZmF1bHQu aD4KLQogI2RlZmluZSBDT05GSUdfQ01EX1NBVEEKICNpZmRlZiBDT05GSUdfQ01EX1NBVEEKICNk ZWZpbmUgQ09ORklHX0RXQ19BSFNBVEEKQEAgLTU0LDkgKzUxLDYgQEAKIAogLyogQ29tbWFuZCBk ZWZpbml0aW9uICovCiAjZGVmaW5lIENPTkZJR19DTURfQk1PREUKLSNkZWZpbmUgQ09ORklHX0NN RF9TRVRFWFBSCi0KLSNkZWZpbmUgQ09ORklHX0JPT1RERUxBWQkJMQogCiAjZGVmaW5lIENPTkZJ R19TWVNfTUVNVEVTVF9TVEFSVAkweDEwMDAwMDAwCiAjZGVmaW5lIENPTkZJR19TWVNfTUVNVEVT VF9FTkQJCShDT05GSUdfU1lTX01FTVRFU1RfU1RBUlQgKyA1MDAgKiBTWl8xTSkKQEAgLTEzOCwx NCArMTMyLDE2IEBACiAJCQkiZmk7ICIJXAogCQkiZmlcMCIgXAogCSJmaW5kZmR0PSJcCisJCSJp ZiB0ZXN0ICRib2FyZF9uYW1lID0gRDEgJiYgdGVzdCAkYm9hcmRfcmV2ID0gTVg2UVAgOyB0aGVu ICIgXAorCQkJInNldGVudiBmZHRmaWxlIGlteDZxcC13YW5kYm9hcmQtcmV2ZDEuZHRiOyBmaTsg IiBcCiAJCSJpZiB0ZXN0ICRib2FyZF9uYW1lID0gRDEgJiYgdGVzdCAkYm9hcmRfcmV2ID0gTVg2 USA7IHRoZW4gIiBcCiAJCQkic2V0ZW52IGZkdGZpbGUgaW14NnEtd2FuZGJvYXJkLXJldmQxLmR0 YjsgZmk7ICIgXAogCQkiaWYgdGVzdCAkYm9hcmRfbmFtZSA9IEQxICYmIHRlc3QgJGJvYXJkX3Jl diA9IE1YNkRMIDsgdGhlbiAiIFwKIAkJCSJzZXRlbnYgZmR0ZmlsZSBpbXg2ZGwtd2FuZGJvYXJk LXJldmQxLmR0YjsgZmk7ICIgXAogCQkiaWYgdGVzdCAkYm9hcmRfbmFtZSA9IEMxICYmIHRlc3Qg JGJvYXJkX3JldiA9IE1YNlEgOyB0aGVuICIgXAotCQkJInNldGVudiBmZHRmaWxlIGlteDZxLXdh bmRib2FyZC5kdGI7IGZpOyAiIFwKKwkJCSJzZXRlbnYgZmR0ZmlsZSBpbXg2cS13YW5kYm9hcmQt cmV2YzEuZHRiOyBmaTsgIiBcCiAJCSJpZiB0ZXN0ICRib2FyZF9uYW1lID0gQzEgJiYgdGVzdCAk Ym9hcmRfcmV2ID0gTVg2REwgOyB0aGVuICIgXAotCQkJInNldGVudiBmZHRmaWxlIGlteDZkbC13 YW5kYm9hcmQuZHRiOyBmaTsgIiBcCisJCQkic2V0ZW52IGZkdGZpbGUgaW14NmRsLXdhbmRib2Fy ZC1yZXZjMS5kdGI7IGZpOyAiIFwKIAkJImlmIHRlc3QgJGJvYXJkX25hbWUgPSBCMSAmJiB0ZXN0 ICRib2FyZF9yZXYgPSBNWDZRIDsgdGhlbiAiIFwKIAkJCSJzZXRlbnYgZmR0ZmlsZSBpbXg2cS13 YW5kYm9hcmQtcmV2YjEuZHRiOyBmaTsgIiBcCiAJCSJpZiB0ZXN0ICRib2FyZF9uYW1lID0gQjEg JiYgdGVzdCAkYm9hcmRfcmV2ID0gTVg2REwgOyB0aGVuICIgXAo= --59037f65_41b71efb_1e9-- From owner-freebsd-arm@freebsd.org Sat Apr 29 18:44:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6E3FD568C6; Sat, 29 Apr 2017 18:44:34 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) (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 ABC9E1EFC; Sat, 29 Apr 2017 18:44:34 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from 178-164-201-217.pool.digikabel.hu ([178.164.201.217] helo=[10.219.16.1]) by marvin.harmless.hu with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1d4XGS-000BCz-0U; Sat, 29 Apr 2017 18:38:40 +0000 To: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, FreeBSD Current From: Gergely Czuczy Subject: RPi3 booting issues: vm_fault pager read error pid 1 Message-ID: <14e0226d-d144-9aaa-f2fe-b1098a9c6ecb@harmless.hu> Date: Sat, 29 Apr 2017 20:38:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 18:44:35 -0000 Hello, I would like to ask for some help. I'm trying to build a freebsd image using crochet, however recent builds, since roughly march, are failing to boot on an RPi3. Currently once the kernel boots up and hands it over to init, the error message "vm_fault pager read error pid 1 (init)" is flooding the screen. Sadly, I don't really know how to debug and fix the cause of this, and I would like to ask some help on fixing this. The image I'm trying to boot (if boots, u/p aegir:aegir): http://czg.harmless.hu/aegir/FreeBSD-aarch64-12.0-AEGIR-317411.img.gz The kernel config: http://czg.harmless.hu/aegir/AEGIR And the crochet config I'm using: http://czg.harmless.hu/aegir/aegir.sh I would like to have a refreshed build, because the one I'm using currently does not have working i2c support, which should be the next thing on my project I'm using this for. Would be nice if someone could take a look into this. Best regards, Gergely From owner-freebsd-arm@freebsd.org Sat Apr 29 21:13:27 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1F59D56CD6 for ; Sat, 29 Apr 2017 21:13:27 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6612915F7 for ; Sat, 29 Apr 2017 21:13:27 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x243.google.com with SMTP id h123so50592qke.2 for ; Sat, 29 Apr 2017 14:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=smZ0v07SzaMkYrC49rzC6pKkDMjM1sAm9xIyF70A11w=; b=L2TGKyh9Wrrz7hjZcKeGxzQJm+Ho+mw+h12ZZoaegHh7kST7HD9fiul4Th8lelyztu PBNQ3NxyTg4o7KibBNEA2y4pacq05KvzfsuPZu2BqNtVwJU7aEzF3pcxVIxI6RCP5n/S m2D5PoUOEr8dbgpw8UvuZzwZiEJQbPmWn5oe8= 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; bh=smZ0v07SzaMkYrC49rzC6pKkDMjM1sAm9xIyF70A11w=; b=UZdvZjj7MMz5TWdP9v+K3gcVoMaM3S41mBkPtH0R3qAodn77lhRJkY0J9CJDO8DcSc /azwwAawaT/JrQHQIqKbauGJCHuD4L3cftBmoAw8uVqnlls7RqdiHrbKMTZqtze4CFzC sxSzRDHsv3D2QFE3MgyrTWy2AB41sXkLvg/B/I0UjG0o1BuEw6eUbWsHzH0J2/4I9WI0 Yh2oiYrtqay9Ks7v+cxXy0J/lqBjkJLnxQnouIIspR1KSgAkZ2SWXgn53wwVcCpDz9Eo jrXuI088ulNN/NyqD1tngCcuK2oQvme8siOoAr8MUwTOJh5oV86Ht599Xl5xyy60UPcV rtwg== X-Gm-Message-State: AN3rC/5hHYwscbuQHQ8PqG+vXublNPdD+r8bdlV8RFst78bkgzBMyRRZ IOoLavDXOU98+Vyo X-Received: by 10.55.121.3 with SMTP id u3mr9766173qkc.29.1493500406152; Sat, 29 Apr 2017 14:13:26 -0700 (PDT) Received: from ?IPv6:2804:54:19ef:cc00:829:e564:ee0b:324b? ([2804:54:19ef:cc00:829:e564:ee0b:324b]) by smtp.googlemail.com with ESMTPSA id g66sm6547654qkb.55.2017.04.29.14.13.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Apr 2017 14:13:25 -0700 (PDT) Subject: Re: RPi3 booting issues: vm_fault pager read error pid 1 To: freebsd-arm@freebsd.org References: <14e0226d-d144-9aaa-f2fe-b1098a9c6ecb@harmless.hu> From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <266a5c90-4552-d7f4-fd42-59887610b88b@bsd.com.br> Date: Sat, 29 Apr 2017 18:13:19 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <14e0226d-d144-9aaa-f2fe-b1098a9c6ecb@harmless.hu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 21:13:27 -0000 Em 29/04/2017 15:38, Gergely Czuczy escreveu: > Hello, > > I would like to ask for some help. I'm trying to build a freebsd image > using crochet, however recent builds, since roughly march, are failing > to boot on an RPi3. Currently once the kernel boots up and hands it > over to init, the error message "vm_fault pager read error pid 1 > (init)" is flooding the screen. Sadly, I don't really know how to > debug and fix the cause of this, and I would like to ask some help on > fixing this. > > The image I'm trying to boot (if boots, u/p aegir:aegir): > http://czg.harmless.hu/aegir/FreeBSD-aarch64-12.0-AEGIR-317411.img.gz > > The kernel config: > http://czg.harmless.hu/aegir/AEGIR > > And the crochet config I'm using: > http://czg.harmless.hu/aegir/aegir.sh > > I would like to have a refreshed build, because the one I'm using > currently does not have working i2c support, which should be the next > thing on my project I'm using this for. > > Would be nice if someone could take a look into this. > > Best regards, > Gergely > The answer to your question is this thread: http://freebsd.1045724.x6.nabble.com/FreeBSD-12-CURRENT-on-OrangePi-One-tt6183253.html#none []'s -Otacilio