From owner-freebsd-arm@freebsd.org Sun Nov 12 05:56: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 43530E6987C for ; Sun, 12 Nov 2017 05:56:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-147.reflexion.net [208.70.210.147]) (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 099FE7D7DA for ; Sun, 12 Nov 2017 05:56:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20608 invoked from network); 12 Nov 2017 05:29:30 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Nov 2017 05:29:30 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 12 Nov 2017 00:29:30 -0500 (EST) Received: (qmail 22061 invoked from network); 12 Nov 2017 05:29:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Nov 2017 05:29:29 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2D579EC9024 for ; Sat, 11 Nov 2017 21:29:29 -0800 (PST) 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 -r325700 booting BPI-M3 (currently unsupported officially): some notes for how it can be set up Message-Id: <5EB8AF59-1E8B-4EEA-9E0E-846C357DEF43@dsl-only.net> Date: Sat, 11 Nov 2017 21:29:28 -0800 To: Freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 05:56:18 -0000 [A later point will be: Is the loader or kernel having problems picking up material from the long-standing u-boot for the BPI-M3?] Overall the things I'm now doing to keep the BPI-M3 going in my local environment are: In /boot/loader.conf : fdt_file=3D"/boot/dtb/sinovoip-bpi-m3.dtb" (The above is new and previously nothing like it was needed.) I use: WORLD_FLAGS=3D"${WORLD_FLAGS} UBLDR_LOADADDR=3D0x42000000" during builds and the BPI-M3 boots via ubldr . (sysutils/u-boot-sinovoip-bpi-m3 is old, not modern, although I've not tried to force ubldr.bin use to see if it would work.) # svnlite diff /usr/src/sys/modules/dtb/allwinner/Makefile = /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi = /usr/src/sys/arm/allwinner/aw_usbphy.c Index: /usr/src/sys/modules/dtb/allwinner/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/modules/dtb/allwinner/Makefile (revision 325700) +++ /usr/src/sys/modules/dtb/allwinner/Makefile (working copy) @@ -3,6 +3,7 @@ DTS=3D \ nanopi-neo.dts \ orangepi-plus-2e.dts \ + sinovoip-bpi-m3.dts \ sun4i-a10-cubieboard.dts \ sun4i-a10-olinuxino-lime.dts \ sun6i-a31s-sinovoip-bpi-m2.dts \ Index: /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/fdt/dts/arm/a83t.dtsi (revision 325700) +++ /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (working copy) @@ -179,6 +179,9 @@ reg =3D <0x01c19400 0x2c>, <0x01c1a800 0x4>, <0x01c1b800 0x4>; + reg-names =3D "phy_ctrl", + "pmu1", + "pmu2"; clocks =3D <&usb_clk 8>, <&usb_clk 9>, <&usb_clk 10>, Index: /usr/src/sys/arm/allwinner/aw_usbphy.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/allwinner/aw_usbphy.c (revision 325700) +++ /usr/src/sys/arm/allwinner/aw_usbphy.c (working copy) @@ -58,6 +58,7 @@ AWUSBPHY_TYPE_A13, AWUSBPHY_TYPE_A20, AWUSBPHY_TYPE_A31, + AWUSBPHY_TYPE_A83T, AWUSBPHY_TYPE_H3, AWUSBPHY_TYPE_A64 }; @@ -90,6 +91,13 @@ .phy0_route =3D false, }; =20 +static const struct aw_usbphy_conf a83t_usbphy_conf =3D { + .num_phys =3D 3, // USB-DRD/OTG and 2 USB hosts + .phy_type =3D AWUSBPHY_TYPE_A83T, + .pmu_unk1 =3D false, + .phy0_route =3D false, +}; + static const struct aw_usbphy_conf a31_usbphy_conf =3D { .num_phys =3D 3, .phy_type =3D AWUSBPHY_TYPE_A31, @@ -116,6 +124,7 @@ { "allwinner,sun5i-a13-usb-phy", = (uintptr_t)&a13_usbphy_conf }, { "allwinner,sun6i-a31-usb-phy", = (uintptr_t)&a31_usbphy_conf }, { "allwinner,sun7i-a20-usb-phy", = (uintptr_t)&a20_usbphy_conf }, + { "allwinner,sun8i-a83t-usb-phy", = (uintptr_t)&a83t_usbphy_conf }, { "allwinner,sun8i-h3-usb-phy", = (uintptr_t)&h3_usbphy_conf }, { "allwinner,sun50i-a64-usb-phy", = (uintptr_t)&a64_usbphy_conf }, { NULL, 0 } Notes on the parts of the above recently added: As of -r324822 the BPI-M3 is unsupported: its .dts file was removed from: sys/modules/dtb/allwinner/Makefile Things are progressing towards use of Linux .dts files but are not there yet. I'd been able to keep going with a few local changes (a83t.dtsi and aw_usbphy.c and UBLDR_LOADADDR above) but the jump from -r324743 to -r325700 got: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 No valid device tree blob found! unlike before. To my prior local changes (a83t.dtsi and aw_usbphy.c and UBLDR_LOADADDR above) I ended up adding: fdt_file=3D"/boot/dtb/sinovoip-bpi-m3.dtb" to /boot/loader.conf in order for the .dtb to be found the file. I also reverted the removal that was in sys/modules/dtb/allwinner/Makefile . These took care of the problem. I've not found what made the difference in the file lookup from -r324743, -r324743 did not need anything like that fdt_file line. sysutils/u-boot-sinovoip-bpi-m3 has not changed in 10 months and that was for Makefile issues. Its core material is unchanged from when it was created. And I'd not updated and, so, was using the same version as before. Is the loader or kernel having problems picking up material from the long-standing u-boot? (I do not know at this point.) I also learned that apparently Linux has progressed its naming from: sun8i-a83t-sinovoip-bpi-m3.dt* to: sun8i-a83t-bananapi-m3.dt* (Hard linking those names to sinovoip-bpi-m3.dtb did not help prior to the loader.conf addition.) Other details for my amd64 -> BPI-M3 cross build environment: # more = ~/sys_build_scripts.amd64-host/make_bpim3_nodebug_clang_bootstrap-amd64-ho= st.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_bpim3_nodebug_clang_bootstrap-amd64-host= -$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.armv7-clang-bootstrap.amd64-hos= t" \ WITH_META_MODE=3Dyes \ WORLD_FLAGS=3D"${WORLD_FLAGS} UBLDR_LOADADDR=3D0x42000000" \ MAKEOBJDIRPREFIX=3D"/usr/obj/bpim3_clang/arm.armv7" \ make $* # more ~/src.configs/make.conf CFLAGS.gcc+=3D -v # more ~/src.configs/src.conf.armv7-clang-bootstrap.amd64-host TO_TYPE=3Darmv7 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv7 WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Nov 12 07:06:50 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 0E419E6AA5E for ; Sun, 12 Nov 2017 07:06:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-109.reflexion.net [208.70.210.109]) (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 B62F77F02F for ; Sun, 12 Nov 2017 07:06:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5760 invoked from network); 12 Nov 2017 07:06:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 12 Nov 2017 07:06:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 12 Nov 2017 02:06:42 -0500 (EST) Received: (qmail 28481 invoked from network); 12 Nov 2017 07:06:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Nov 2017 07:06:42 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AE65EEC9024; Sat, 11 Nov 2017 23:06:41 -0800 (PST) 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 -r325700: BPI-M3 u-boot vs. FreeBSD kernel/loader and finding sinovoip-bpi-m3.dtb: fails [ -r324743 head worked] Message-Id: <8ECC1284-8843-420E-8496-9F33DF979A02@dsl-only.net> Date: Sat, 11 Nov 2017 23:06:41 -0800 Cc: Kyle Evans To: Warner Losh , Freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 07:06:50 -0000 On a BPI-M3 in u-boot: =3D> printenv . . . fdt_addr_r=3D0x43000000 fdtcontroladdr=3Dbbf42f68 fdtfile=3Dsinovoip-bpi-m3.dtb . . . But for -r325700 /boot/dtb/sinovoip-bpi-m3.dtb was not found (unlike for -r324743 where the BPI-M3 had been before): No valid device tree blob found! To work around the lack of finding the file, in /boot/loader.conf I added: fdt_file=3D"/boot/dtb/sinovoip-bpi-m3.dtb" sysutils/u-boot-sinovoip-bpi-m3 has not changed in 10 months and that was for Makefile issues. Its core material is unchanged from when it was created. And I'd not updated and, so, was using the same version as before (when the BPI-M3 was at -r324743). It would appear that the change(s) must be on the FreeBSD side of things someplace. Does it look like something that would be BPI-M3 specific? I'd guess not. Notes (if you care): As of -r324822 the BPI-M3 is officially unsupported: its .dts file was removed from: sys/modules/dtb/allwinner/Makefile Things are progressing towards use of Linux .dts files but are not there yet. I'd been able to keep going with a few local changes. Overall the things I'm now doing to keep the BPI-M3 going in my local environment are. . . In /boot/loader.conf : fdt_file=3D"/boot/dtb/sinovoip-bpi-m3.dtb" (The above is new and previously nothing like it was needed.) I use: WORLD_FLAGS=3D"${WORLD_FLAGS} UBLDR_LOADADDR=3D0x42000000" during builds and the BPI-M3 boots via ubldr . (sysutils/u-boot-sinovoip-bpi-m3 is old, not modern, although I've not tried to force ubldr.bin use to see if it would work.) # svnlite diff /usr/src/sys/modules/dtb/allwinner/Makefile = /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi = /usr/src/sys/arm/allwinner/aw_usbphy.c Index: /usr/src/sys/modules/dtb/allwinner/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/modules/dtb/allwinner/Makefile (revision 325700) +++ /usr/src/sys/modules/dtb/allwinner/Makefile (working copy) @@ -3,6 +3,7 @@ DTS=3D \ nanopi-neo.dts \ orangepi-plus-2e.dts \ + sinovoip-bpi-m3.dts \ sun4i-a10-cubieboard.dts \ sun4i-a10-olinuxino-lime.dts \ sun6i-a31s-sinovoip-bpi-m2.dts \ Index: /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/boot/fdt/dts/arm/a83t.dtsi (revision 325700) +++ /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi (working copy) @@ -179,6 +179,9 @@ reg =3D <0x01c19400 0x2c>, <0x01c1a800 0x4>, <0x01c1b800 0x4>; + reg-names =3D "phy_ctrl", + "pmu1", + "pmu2"; clocks =3D <&usb_clk 8>, <&usb_clk 9>, <&usb_clk 10>, Index: /usr/src/sys/arm/allwinner/aw_usbphy.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/allwinner/aw_usbphy.c (revision 325700) +++ /usr/src/sys/arm/allwinner/aw_usbphy.c (working copy) @@ -58,6 +58,7 @@ AWUSBPHY_TYPE_A13, AWUSBPHY_TYPE_A20, AWUSBPHY_TYPE_A31, + AWUSBPHY_TYPE_A83T, AWUSBPHY_TYPE_H3, AWUSBPHY_TYPE_A64 }; @@ -90,6 +91,13 @@ .phy0_route =3D false, }; +static const struct aw_usbphy_conf a83t_usbphy_conf =3D { + .num_phys =3D 3, // USB-DRD/OTG and 2 USB hosts + .phy_type =3D AWUSBPHY_TYPE_A83T, + .pmu_unk1 =3D false, + .phy0_route =3D false, +}; + static const struct aw_usbphy_conf a31_usbphy_conf =3D { .num_phys =3D 3, .phy_type =3D AWUSBPHY_TYPE_A31, @@ -116,6 +124,7 @@ { "allwinner,sun5i-a13-usb-phy", = (uintptr_t)&a13_usbphy_conf }, { "allwinner,sun6i-a31-usb-phy", = (uintptr_t)&a31_usbphy_conf }, { "allwinner,sun7i-a20-usb-phy", = (uintptr_t)&a20_usbphy_conf }, + { "allwinner,sun8i-a83t-usb-phy", = (uintptr_t)&a83t_usbphy_conf }, { "allwinner,sun8i-h3-usb-phy", = (uintptr_t)&h3_usbphy_conf }, { "allwinner,sun50i-a64-usb-phy", = (uintptr_t)&a64_usbphy_conf }, { NULL, 0 } =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Nov 12 13:27:54 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 14B3BE71A5C for ; Sun, 12 Nov 2017 13:27:54 +0000 (UTC) (envelope-from kwhite@eecs.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "courriel.site.uottawa.ca", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6AC467AD6; Sun, 12 Nov 2017 13:27:53 +0000 (UTC) (envelope-from kwhite@eecs.uottawa.ca) Received: from e6220 (dyn-pppoe-142-51-199-208.vianet.ca [142.51.199.208] (may be forged)) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id vACDBLvP062887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Nov 2017 08:11:22 -0500 (EST) (envelope-from kwhite@eecs.uottawa.ca) Date: Sun, 12 Nov 2017 08:11:21 -0500 (EST) From: Keith White X-X-Sender: root@e6220 To: freebsd-arm@freebsd.org cc: imp@freebsd.org Subject: RPI3 fails to boot: boot1.efi as bootaa64.efi on RPI3 [patch] Message-ID: User-Agent: Alpine 2.21 (BSF 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 13:27:54 -0000 I've tried FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20171030-r325156.img and it fails to boot with an error similar to one reported by Mark Millard in https://lists.freebsd.org/pipermail/freebsd-arm/2017-September/016643.html (Synchronous abort after displaying Load Path). After I sprinkled some printf()s in boot1.c, it appears that efi_devpath_name() may return NULL on this platform. The following "works for me". Salt to taste. ...keith Index: /usr/src/sys/boot/efi/boot1/boot1.c =================================================================== --- /usr/src/sys/boot/efi/boot1/boot1.c (revision 325521) +++ /usr/src/sys/boot/efi/boot1/boot1.c (working copy) @@ -460,9 +460,11 @@ imgpath = NULL; if (status == EFI_SUCCESS) { text = efi_devpath_name(img->FilePath); - printf(" Load Path: %S\n", text); - efi_setenv_freebsd_wcs("Boot1Path", text); - efi_free_devpath_name(text); + if (text != NULL) { /* XXX aarch64 RPI3 */ + printf(" Load Path: %S\n", text); + efi_setenv_freebsd_wcs("Boot1Path", text); + efi_free_devpath_name(text); + } status = BS->HandleProtocol(img->DeviceHandle, &DevicePathGUID, (void **)&imgpath); @@ -471,9 +473,11 @@ EFI_ERROR_CODE(status)); } else { text = efi_devpath_name(imgpath); - printf(" Load Device: %S\n", text); - efi_setenv_freebsd_wcs("Boot1Dev", text); - efi_free_devpath_name(text); + if (text != NULL) { /* XXX aarch64 RPI3 */ + printf(" Load Device: %S\n", text); + efi_setenv_freebsd_wcs("Boot1Dev", text); + efi_free_devpath_name(text); + } } } From owner-freebsd-arm@freebsd.org Sun Nov 12 14:50: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 9D156E7369D for ; Sun, 12 Nov 2017 14:50:14 +0000 (UTC) (envelope-from kwhite@eecs.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "courriel.site.uottawa.ca", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 695426A6A0; Sun, 12 Nov 2017 14:50:13 +0000 (UTC) (envelope-from kwhite@eecs.uottawa.ca) Received: from e6220 (dyn-pppoe-142-51-199-208.vianet.ca [142.51.199.208] (may be forged)) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id vACEoLe7066937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Nov 2017 09:50:21 -0500 (EST) (envelope-from kwhite@eecs.uottawa.ca) Date: Sun, 12 Nov 2017 09:50:20 -0500 (EST) From: Keith White X-X-Sender: root@e6220 To: Keith White cc: freebsd-arm@freebsd.org, imp@freebsd.org Subject: Re: RPI3 fails to boot: boot1.efi as bootaa64.efi on RPI3 [patch] In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (BSF 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 14:50:14 -0000 Umm, forget it. I see it's fixed now (r325681). ...keith On Sun, 12 Nov 2017, Keith White wrote: > I've tried FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20171030-r325156.img > and it fails to boot with an error similar to one reported by Mark Millard > in https://lists.freebsd.org/pipermail/freebsd-arm/2017-September/016643.html > (Synchronous abort after displaying Load Path). > > After I sprinkled some printf()s in boot1.c, it appears that > efi_devpath_name() may return NULL on this platform. > > The following "works for me". Salt to taste. > > ...keith > > Index: /usr/src/sys/boot/efi/boot1/boot1.c > =================================================================== > --- /usr/src/sys/boot/efi/boot1/boot1.c (revision 325521) > +++ /usr/src/sys/boot/efi/boot1/boot1.c (working copy) > @@ -460,9 +460,11 @@ > imgpath = NULL; > if (status == EFI_SUCCESS) { > text = efi_devpath_name(img->FilePath); > - printf(" Load Path: %S\n", text); > - efi_setenv_freebsd_wcs("Boot1Path", text); > - efi_free_devpath_name(text); > + if (text != NULL) { /* XXX aarch64 RPI3 */ > + printf(" Load Path: %S\n", text); > + efi_setenv_freebsd_wcs("Boot1Path", text); > + efi_free_devpath_name(text); > + } > > status = BS->HandleProtocol(img->DeviceHandle, > &DevicePathGUID, > (void **)&imgpath); > @@ -471,9 +473,11 @@ > EFI_ERROR_CODE(status)); > } else { > text = efi_devpath_name(imgpath); > - printf(" Load Device: %S\n", text); > - efi_setenv_freebsd_wcs("Boot1Dev", text); > - efi_free_devpath_name(text); > + if (text != NULL) { /* XXX aarch64 RPI3 */ > + printf(" Load Device: %S\n", text); > + efi_setenv_freebsd_wcs("Boot1Dev", text); > + efi_free_devpath_name(text); > + } > } > > } > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Sun Nov 12 14:56: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 6BF8EE738A4 for ; Sun, 12 Nov 2017 14:56:04 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3091C6AA00; Sun, 12 Nov 2017 14:56:04 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x231.google.com with SMTP id n134so7545648itg.0; Sun, 12 Nov 2017 06:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AO+eIVKJfGZk5c6rfJOvzND4B+v040CBfy2S/vwZkyk=; b=ofQwV3g0beH880WfJqFHznlMH+AsaOqen+JvgAVIfbxNONspq6VFCADGffZxrRFhL5 jqFVZS5slC1gmqAYdrIUUExl7U8tfEguEkuwrFB5T6iGsfzKS44MStvsStVBifYV+tud IbrnPB2LhxxkNgD1DutjclbAihB+33xM7LbEoNP4DJO6CFSiX6UEpet4vS/Un5SZdJXu uzGpTiL+0tsJ2Vdc8rGZPrcKDbKiFqmoROmhgJbnVpJTMhc4KRPqJPnJGnE3FRNgI6lx Awzf68PbHxC/xLN76BmJn75z4uZNolJCaz66wqKHy/sGLUd6KgyF1Tx2LUcvw63A0hwp B9CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AO+eIVKJfGZk5c6rfJOvzND4B+v040CBfy2S/vwZkyk=; b=CXsJ++TAEag6wz1Wa8iFNXkmZb5/6YMSXjYSeKBPumbMsiuO0f5zWDUGPixHUQZEmF LVva7v21CdNVwOe7mBp0XeQQXt9HZl3Ej8t4iExTx+nOBWdhIdXHZKWBdRmHjRZ1QJdP 2G+fCyqymGpYNXIGBFbp1W6KpPyAL6AnIg73tQbDSygGpcnJCORf/TA6t4ELTQaeOTfI fpz9k5n2EdJOfQy/js+BoiwUMFH1+374Cj/7jTMWHmH+mKuFd50fJMaGzK3jkyUSWHz0 ZOJZA6cU1LpTTqzzwOTJcFpW6+nLf622TQMMgFIIEYleK/BYZ/MUxdMZV4JB9I8XAIZ0 3ATw== X-Gm-Message-State: AJaThX5FLYDhOYLqIwF0isvUpjTj2Lm6fm6AVG6zTacRK+jfkpUB8vHb aOwtj2fKQq9qr2Pl1FQspIpFnP+pHO1e1Nnhv9fkfGcB X-Google-Smtp-Source: AGs4zMbbyHfP2F0TEIyf0OYxVijkZZoy1+vLtvv1gO1vOgifmo66ejdphnd3YOkKEs2Jx2UVwWyuAIGckwfjIBCxc8M= X-Received: by 10.36.93.72 with SMTP id w69mr7217722ita.103.1510498563627; Sun, 12 Nov 2017 06:56:03 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.14.208 with HTTP; Sun, 12 Nov 2017 06:55:43 -0800 (PST) In-Reply-To: References: From: Ed Maste Date: Sun, 12 Nov 2017 09:55:43 -0500 X-Google-Sender-Auth: oHrJ54ohq33-WethQjAxUH3gI4k Message-ID: Subject: Re: RPI3 fails to boot: boot1.efi as bootaa64.efi on RPI3 [patch] To: Keith White Cc: "freebsd-arm@freebsd.org" , Warner Losh Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 14:56:04 -0000 On 12 November 2017 at 08:11, Keith White wrote: > I've tried FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20171030-r325156.img > and it fails to boot with an error similar to one reported by Mark Millard > in > https://lists.freebsd.org/pipermail/freebsd-arm/2017-September/016643.html > (Synchronous abort after displaying Load Path). Yes, unfortunately boot1.efi has been broken on PRi3 for months. A fix was committed in r325681 and will be in the next round of snapshots https://svnweb.freebsd.org/changeset/base/325681 jhb@ suggested checking the device for NULL as well, as in your patch, and I'll make that change shortly. In practice if the first call works the second will as well, but your version is an improvement in correctness. From owner-freebsd-arm@freebsd.org Sun Nov 12 15:40: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 658D3C0815E for ; Sun, 12 Nov 2017 15:40:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 333C16B9BB for ; Sun, 12 Nov 2017 15:40:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id u42so93380ioi.9 for ; Sun, 12 Nov 2017 07:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4+c4xHKPjGGrpDiotHZ5lkzvtrSBSakIoJ+RZy47A3A=; b=ovZW9I8TcHXMxuE2XH9jByhnoLKIdZ+s8M9lu1a0dNINg5h3s905FpiW25CKemqzhA 0XpAphH1ntyRPjnb8NYYdEVq+GgtE67ZtDwrk9ZUFKVnMbOnS6J7Qrqfh9VBgGUtTVc1 nynZ6Zwg9cdZvb1558BDXBgfCqNeo+0SPFF4AxOH1Xb3+qaeULw4NcRK+47NRtU0ZBsb 3RIb9zGYPe5EO2J1FxI4tc8lWMIqgeo1YTvt25FLns1QpbvWh6fiywBw0ChkdmvyPoA1 1RiDUltGkgWPDybPKCSjXj7I2xAXBi4PKoRmngTQfdzfnv7AW/FLFlhGoEDD/nMcOYnr JiSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4+c4xHKPjGGrpDiotHZ5lkzvtrSBSakIoJ+RZy47A3A=; b=Ww3ao/QDUw+gnWdEPieR+rbETUV2f2qnMe8NujAU061oDOqVIUEVZ6FAhSidtbuxcY pFUAF7D74hUtyoiPJyWIfTeWBvqwA14XRepmTMGB1BKit+JvBtvDldPgReMY2u+bDyH7 77kpyIbp12YckPzCLHXLWb6OfvpKUT8fA+0KK+MSI9ChILxGW6g+XZVu6Vk4FofzjdAN 4nG8DbQuahdJ37mzLJV53CunieuwtP972U0b+xlsecKCdZhM0REQ4m+XU4JMZm4ZFKca 6sIKKw+UC2lr0bSiwEDXr4bndhXUkPGLs+PwWISoHNUl0oclrwC6bOOMweXdZorji4+N Qdjg== X-Gm-Message-State: AJaThX7T69QxKEl20nVvSohD+BgfyPzrKqEQcGX6xegrbJza3bFPKaK0 y+BkNTOxWkWoVgZ28CYkB6lCvskyxPPY4n1T4Ju25Q== X-Google-Smtp-Source: AGs4zMYmJJgLMFuBAgCMwZ7gdjHcxtSUojN5zi+uz8jYWDuYkJo9VzJBLskFjFEGYx4ZmgNJlIo8RyDncILRp2TaTO0= X-Received: by 10.107.48.76 with SMTP id w73mr7267009iow.301.1510501226207; Sun, 12 Nov 2017 07:40:26 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sun, 12 Nov 2017 07:40:25 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:d8ae:193d:d5ec:7c8] Received: by 10.79.108.204 with HTTP; Sun, 12 Nov 2017 07:40:25 -0800 (PST) In-Reply-To: References: From: Warner Losh Date: Sun, 12 Nov 2017 08:40:25 -0700 X-Google-Sender-Auth: 8i2FAySGEjqmqAPhXZ3jEzKXWeY Message-ID: Subject: Re: RPI3 fails to boot: boot1.efi as bootaa64.efi on RPI3 [patch] To: Ed Maste Cc: Keith White , freebsd-arm@freebsd.org, Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 15:40:27 -0000 On Nov 12, 2017 7:56 AM, "Ed Maste" wrote: On 12 November 2017 at 08:11, Keith White wrote: > I've tried FreeBSD-12.0-CURRENT-arm64-aarch64-RPI3-20171030-r325156.img > and it fails to boot with an error similar to one reported by Mark Millard > in > https://lists.freebsd.org/pipermail/freebsd-arm/2017-September/016643.html > (Synchronous abort after displaying Load Path). Yes, unfortunately boot1.efi has been broken on PRi3 for months. A fix was committed in r325681 and will be in the next round of snapshots https://svnweb.freebsd.org/changeset/base/325681 jhb@ suggested checking the device for NULL as well, as in your patch, and I'll make that change shortly. In practice if the first call works the second will as well, but your version is an improvement in correctness. Makes sense to me. My fix for that just skipped it all if the first path was null. Of course, boot1.edi will be booted from the tree in the near term, so long term correctness doesn't matter. Warner From owner-freebsd-arm@freebsd.org Sun Nov 12 15:51:07 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 3B044C0879A for ; Sun, 12 Nov 2017 15:51:07 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) (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 07C746BF32 for ; Sun, 12 Nov 2017 15:51:06 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-io0-f178.google.com with SMTP id w127so721201iow.11 for ; Sun, 12 Nov 2017 07:51:06 -0800 (PST) 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=arlXX4FyGJfRq7fB7EQnGzS0Q8Ucp93VPfDNZ4G4XjM=; b=KtO+O4n/3eZPTcQJBaNEqLRtJ6J4P5OjjkMmQ2kv69Gb6YGoo6dfdCzQoLUfRtBLXu 8kj38sxgEONGjl0ZpGhmRaeRnXLM6qW0T15mg/rpJw/nGtlTFw4GKIzTGvdP8xDhs5KV pcYZsDLtS2LbpGIDhAQhAGVo7x4hPP5XkRmBygzYHJRnpF8S4vdvOR8d8QfRJjcs7fxy sg6e+Inh6YwKGqqDxCrKybQcwo8AJf5dNKxIyrwrk1p3x1OrJ3hydmNq8l4MDAjjWJM/ 0SCH72BoDU6DTVkkYMJYmrotQ8kb9C4Ox420zO6ZfKwQ92NWjujOMclF3SSDjEQeQXB5 yN7Q== X-Gm-Message-State: AJaThX4jlEmHp8qZ0cm1lJOAOvhWf8aT/fz8TMHNKEcJYbXKwcRrybZa D5VLPh8nnNYfCydux8jwTXfvPs4y X-Google-Smtp-Source: AGs4zMYdHjJcprVZ3ZvYdqebVYKbhE7vgJmvMi5dowSpnSS/LVGeIN8AfJyZEuaRauvxTbjsGdXePQ== X-Received: by 10.107.107.22 with SMTP id g22mr7628326ioc.77.1510501416618; Sun, 12 Nov 2017 07:43:36 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id k9sm312535ith.25.2017.11.12.07.43.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 07:43:36 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id p186so18102383ioe.12 for ; Sun, 12 Nov 2017 07:43:36 -0800 (PST) X-Received: by 10.107.46.216 with SMTP id u85mr6522018iou.136.1510501415955; Sun, 12 Nov 2017 07:43:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.23.129 with HTTP; Sun, 12 Nov 2017 07:43:35 -0800 (PST) Received: by 10.107.23.129 with HTTP; Sun, 12 Nov 2017 07:43:35 -0800 (PST) In-Reply-To: <8ECC1284-8843-420E-8496-9F33DF979A02@dsl-only.net> References: <8ECC1284-8843-420E-8496-9F33DF979A02@dsl-only.net> From: Kyle Evans Date: Sun, 12 Nov 2017 09:43:35 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: head -r325700: BPI-M3 u-boot vs. FreeBSD kernel/loader and finding sinovoip-bpi-m3.dtb: fails [ -r324743 head worked] To: Mark Millard Cc: Warner Losh , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 15:51:07 -0000 On Nov 12, 2017 1:06 AM, "Mark Millard" wrote: On a BPI-M3 in u-boot: =3D> printenv . . . fdt_addr_r=3D0x43000000 fdtcontroladdr=3Dbbf42f68 fdtfile=3Dsinovoip-bpi-m3.dtb . . . But for -r325700 /boot/dtb/sinovoip-bpi-m3.dtb was not found (unlike for -r324743 where the BPI-M3 had been before): No valid d=E2=84=A2evice tree blob found! Interesting- I had a similar issue, but it was presumably due to having locally updated the u-boot port to use u-boot-master. IIRC, I worked around this for the time being by adding a LINKS entry in the same makefile: sinovoip-bpi-m3.dtb sun8i-a83t-sinovoip-bpi-m3.dtb Or was it sunxi-? I believe it matched a .dts in gnu/, so I would double check that- not at a usable machine at the moment. Either way, this alone caused a recent -HEAD to boot. This is what I currently boot on my bpi-m3: https://github.com/kevans91/freebsd/tree/clkng Thanks, Kyle Evans From owner-freebsd-arm@freebsd.org Sun Nov 12 16:43: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 49C10C0A819 for ; Sun, 12 Nov 2017 16:43:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-147.reflexion.net [208.70.210.147]) (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 0EE4B6D568 for ; Sun, 12 Nov 2017 16:43:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28312 invoked from network); 12 Nov 2017 16:36:24 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Nov 2017 16:36:24 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 12 Nov 2017 11:36:24 -0500 (EST) Received: (qmail 8099 invoked from network); 12 Nov 2017 16:36:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Nov 2017 16:36:24 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AFBD8EC8B8B; Sun, 12 Nov 2017 08:36:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r325700: BPI-M3 u-boot vs. FreeBSD kernel/loader and finding sinovoip-bpi-m3.dtb: fails [ -r324743 head worked] From: Mark Millard In-Reply-To: Date: Sun, 12 Nov 2017 08:36:23 -0800 Cc: Warner Losh , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6CFB609E-DE25-492D-96AC-782010FE6EF9@dsl-only.net> References: <8ECC1284-8843-420E-8496-9F33DF979A02@dsl-only.net> To: Kyle Evans X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 16:43:06 -0000 [Kyle's Makefile update is not a fix for what I reported.] On 2017-Nov-12, at 7:43 AM, Kyle Evans wrote: > On Nov 12, 2017 1:06 AM, "Mark Millard" = wrote: > On a BPI-M3 in u-boot: >=20 > =3D> printenv > . . . > fdt_addr_r=3D0x43000000 > fdtcontroladdr=3Dbbf42f68 > fdtfile=3Dsinovoip-bpi-m3.dtb > . . . >=20 > But for -r325700 /boot/dtb/sinovoip-bpi-m3.dtb > was not found (unlike for -r324743 where the > BPI-M3 had been before): >=20 > No valid d=E2=84=A2evice tree blob found! >=20 > Interesting- I had a similar issue, but it was presumably due to = having locally updated the u-boot port to use u-boot-master. >=20 > IIRC, I worked around this for the time being by adding a LINKS entry = in the same makefile: >=20 > sinovoip-bpi-m3.dtb sun8i-a83t-sinovoip-bpi-m3.dtb >=20 > Or was it sunxi-? I believe it matched a .dts in gnu/, so I would = double check that- not at a usable machine at the moment. [I was not using anything based on u-boot-master. I was using: sysutils/u-boot-sinovoip-bpi-m3 which has not been updated.] It was sun8i- but that change does not fix my example, quoting a different message. . . [The wording was not explicit about the .dtb were what I hard linked, not source code files.] QUOTE I also learned that apparently Linux has progressed its naming from: sun8i-a83t-sinovoip-bpi-m3.dt* to: sun8i-a83t-bananapi-m3.dt* (Hard linking those names to sinovoip-bpi-m3.dtb did not help prior to the loader.conf addition.) END QUOTE. And, in fact, as I reported u-boot reported the name in fdtfile: fdtfile=3Dsinovoip-bpi-m3.dtb but the FreeBSD code did not pick it up: /usr/src/sys/boot/uboot/fdt/uboot_fdt.c has fdt_platform_load_dtb that has: s =3D getenv("fdt_file"); if (s =3D=3D NULL) s =3D ub_env_get("fdtfile"); if (s =3D=3D NULL) s =3D ub_env_get("fdt_file"); if (s !=3D NULL && *s !=3D '\0') { if (fdt_load_dtb_file(s) =3D=3D 0) { printf("Loaded DTB from file '%s'.\n", s); rv =3D 0; } } In -r324743 the message from fdt_load_dtb_file printed to the console and then the above "Loaded DTB . . ." message printed there. So this code block was making the binding before. I suspect that was from the ub_env_get("fdtfile") finding fdtfile above. But in -r325700 it does not work for some reason. There is earlier code: s =3D ub_env_get("fdt_addr_r"); if (s =3D=3D NULL) s =3D ub_env_get("fdtaddr"); if (s =3D=3D NULL) s =3D ub_env_get("fdt_addr"); if (s !=3D NULL && *s !=3D '\0') { hdr =3D (struct fdt_header *)strtoul(s, &p, 16); if (*p =3D=3D '\0') { if (fdt_load_dtb_addr(hdr) =3D=3D 0) { printf("Using DTB provided by U-Boot at = " "address %p.\n", hdr); return (0); } } } that overall apparently ignores the: fdt_addr_r=3D0x43000000 for some reason, even in the older -r324743. > Either way, this alone caused a recent -HEAD to boot. This is what I = currently boot on my bpi-m3: = https://github.com/kevans91/freebsd/tree/clkng I'm not sure that it would for -r325700+ . What broke may have happened between your test and my test. So, knowing what you booted with might help narrow the range if you ended up trying something after -r324743 --but after the static-images-are-broken issue was fixed [/sbin/init working again]. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Nov 12 18:03: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 BE81BC31F61 for ; Sun, 12 Nov 2017 18:03:38 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 888126F641 for ; Sun, 12 Nov 2017 18:03:38 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id D46BC27386 for ; Sun, 12 Nov 2017 13:03:03 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 0559739895A for ; Sun, 12 Nov 2017 12:03:01 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Very bizarre behavior ARM64 (Pi3) Message-ID: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> Date: Sun, 12 Nov 2017 12:02:54 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000806040109030908000202" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 18:03:38 -0000 This is a cryptographically signed message in MIME format. --------------ms000806040109030908000202 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I managed to get around the Crochet blow-up I reported the other day with another svn update, and now can Crochet myself a running image for the Pi3 which boots and (at least at first blush) works. But I have code that has been running on the Pi3 (and also on the Pi2, along with other architectures) for quite some time that no longer runs when compiled on that newly-built OS.=C2=A0 It compiles without warnings = or errors but blows up immediately when executed. I just tried to roll that build forward to the newly-built (FreeBSD 12.0-CURRENT #0 r325681M: Fri Nov 10 19:31:28 CST 2017)=C2=A0 -HEAD and a= m getting really bizarre core dumps, including (if compiled using OpenSSL libraries) a crash on initialization claiming unknown opcodes in the compiled binary. root@rpi3:/data/HD-MCP # lldb hd-mcp (lldb) target create "hd-mcp" Current executable set to 'hd-mcp' (aarch64). (lldb) run -n Process 1101 launching Process 1101 launched: '/data/HD-MCP/hd-mcp' (aarch64) Process 1101 stopped * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: illegal tr= ap =C2=A0=C2=A0=C2=A0 frame #0: 0x00000000403342e8 ->=C2=A0 0x403342e8: .long=C2=A0 0x0ee0e000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; unknown op= code =C2=A0=C2=A0=C2=A0 0x403342ec: ret =C2=A0=C2=A0=C2=A0 0x403342f0: stp=C2=A0=C2=A0=C2=A0 x28, x19, [sp, #-0x2= 0]! =C2=A0=C2=A0=C2=A0 0x403342f4: stp=C2=A0=C2=A0=C2=A0 x29, x30, [sp, #0x10= ] (lldb) bt * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: illegal tr= ap =C2=A0 * frame #0: 0x00000000403342e8 =C2=A0=C2=A0=C2=A0 frame #1: 0x0000000040082ad8 =C2=A0=C2=A0=C2=A0 frame #2: 0x0000000040081ab4 (lldb) If I compile and link with OpenSSL omitted (which is an option in the software in question) then I get blowups shortly after the software starts implying the stack is getting smashed in bizarre ways that don't make any sense. The same source has been running for months uninterrupted on 11.x hosted on a Pi2 and used to run just fine on a Pi3 from a build I last updated back in February. To top it off lldb blows up if I set a breakpoint (or get a SEGV and trap back to it) and try to print anything out of the current frame (e.g. the variables in the function that blew) so it's basically impossible to figure out what's getting hammered in the stack if I leave the OpenSSL libraries out. Are there known issues with the arm64 architecture in -HEAD at present? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000806040109030908000202 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 DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTEyMTgwMjU0 WjBPBgkqhkiG9w0BCQQxQgRA08m3W/8qVvx1BSAaySlRp3Ka1o5xjxzFrTy6ohdv0BBcfvF/ 8ane6R5a+BGqRIpIu+HsZmx+1o4WDAM1cOoT3jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBYc7Wq8lAfvWDwcLDi2Uh9oEvUX+Dv9gUB+oNrM8LACCbppFFnBYFnUqSLswBvYkYp 1BFXGOWx67xJUctUMqWcVyB5utjzfha/42nKLr1oFwBjsLGYs0pMhz1JYBbQviW7NIWBzM5w 3pN1xpgKXHZMuI+wpDghI2mERPA02jvQgxVnHh+f742V/yzs2yu85o4K026icpd1BPbRN9pG 4uEO0VyxHZ1kg9npgn2ZN98bvkcPDeDk/dvOgumDdK+DxyUBUcuqTQPrXl8lfodjnCpONEMR uJU56+pn4jNAnz/Yz3HsVtt2oz+XU46mSONhKhmrR3/rJClpp9gYOa3E/v1QqVaO07r0TrWl kJZA97B7KCRDk8TBhyzEjmLaH6utIRPfgTugshsrWspUEvDRnfJocsUg8t+qLJGLy2seMAfy Wi+MdPEHGoqnpNYDMboUZNpjoHFWwGY3Beyw+o4Amt2Ya+GUZw0dOpFnSwILr0evTdPiY670 NvGWZIJ3wmaKkS4WT/lYeTwcKC668L05/6FJAs+sowa0WZ3UXO0sRKnZwasoK3yeIsrOt0Fm LXdFFHnQL5jA9Jw/t6DAHRTg5dl3Y9IJvBfT3C3VMThrqF3GKe6PnRuD1PGtxj4kUvzhFj7T GiZXZUtte8XyLSySHgpdK4tAgcNzAbPAkKF4kuoglwAAAAAAAA== --------------ms000806040109030908000202-- From owner-freebsd-arm@freebsd.org Sun Nov 12 19:03: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 AAA80C7A469 for ; Sun, 12 Nov 2017 19:03:47 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mailbox.org", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DF2371050 for ; Sun, 12 Nov 2017 19:03:46 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id DD76A4C1A9; Sun, 12 Nov 2017 20:03:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-type:content-type:mime-version:references:in-reply-to :subject:subject:from:from:message-id:date:date:received; s= mail20150812; t=1510513416; bh=lvfs8Izu2sdb3YgIrDROJZORt9CCj7/1B AxTZs45t8E=; b=cP3hmP4tVIjLxI2d7NUsrooqRtYNKl3xh5caWeFGb3X2a50kJ J1mHZctKgcEQzQa4QBo+cBZNRd/VUhaXzsmyijUyHRMB/VTYfQJ7Kf5rM0d93RRp IUsQpv3FS/xvQgT2juT5LdAUJXDKlA/3SXKHUOY5YGpK9Qz1bu9dtPz1qHiYUy7n C29uGbm+PYKgB1dpUYYtJ+IY2+PPwm81mGhWSpxNYT3ArOGNnCEAn9TFQ+nLi2FS ntJEoQjTAVCEGN7aXZTyEUNimsRgQhbfJmegmnwJFveX7g7IfkidPuiCUTHj5eut LODAqvD5T5V+j2afMf3CcaKOH0AhNS7IaSTMg== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id B9nANF24l-qJ; Sun, 12 Nov 2017 20:03:36 +0100 (CET) Date: Sun, 12 Nov 2017 20:03:32 +0100 Message-ID: <87a7zrgvzv.wl-herbert@mailbox.org> From: "Herbert J. Skuhra" To: Claude Buisson Cc: freebsd-arm@freebsd.org Subject: Re: rpi2: cpufreq(4) support lost ? In-Reply-To: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 19:03:47 -0000 On Sat, 11 Nov 2017 12:47:47 +0100, Claude Buisson wrote: > > [I am not subscribed to this list - please answser to me] > > I recently upgraded a RPI2 Model B, from head r323691 armv6 to head > r325110 + patch D12907 (lib/libc/gen/tls.c) armv7. > > In the dmesg, the lines: > > bcm2835_cpufreq0: on cpu0 > bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF > > disappeared, and the log shows: > > /etc/rc.d/powerd start > powerd: no cpufreq(4) support -- aborting: No such file or directory > > As what seems to be a consequence, the system became much slower. > > Everything came back to normal when I copied the old rpi2.dtb to the > new /boot/msdos/ The old rpi2.dtb is from an armv6 build, right? > I tried the rpi2.dtb from the lastest snapshot > FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img > and cpufreq(4) disappeared again. > > What I am missing ? The problem obviously exists since the switch to armv7. I use rpi2.dtb from my other RPI2 (stable/11). -- Herbert From owner-freebsd-arm@freebsd.org Sun Nov 12 20:59:12 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 6A595C7C78C for ; Sun, 12 Nov 2017 20:59:12 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mailbox.org", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E1217504A; Sun, 12 Nov 2017 20:59:11 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 916D646CF5; Sun, 12 Nov 2017 21:59:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-type:content-type:mime-version:references:in-reply-to :subject:subject:from:from:message-id:date:date:received; s= mail20150812; t=1510520328; bh=k/58++Yj6H7zkpzDokcQ5iFXR/smQl7Yq CjvDCllfec=; b=pBsvm1v0rckyjnUs6LcnaDnOUi6Wed/L0wBKrbui/+hAp4p8t uN76HTx+VZa6E3sIHNdGp3uDTxI9ZgosqBJNfrmaTuLzyMEFaYD0o0HG++CzeTFF HDzx8v+lw66jwSjvMjvIAUBmILqlaYl8cX+u6PRPKm1zxD3O9//8ZrLxlsVwufUS XNVdltBP80+EgVLTKcIUh5aJl9Xe0BknVD1AJKAfmRQkTBlikFRlATOQRA2jmu0J BnZJyc1bCFU9SpRBTyg18BYEN7gLHi4np2QJ/aZm8fmjihXOOvgQAbbVPIhvrw2f 6hKWCVs1/VScKbzcG1ogeMt7OhdmddBkZjpng== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id EsKjFt-g3-Vg; Sun, 12 Nov 2017 21:58:48 +0100 (CET) Date: Sun, 12 Nov 2017 21:58:44 +0100 Message-ID: <878tfbgqnv.wl-herbert@mailbox.org> From: "Herbert J. Skuhra" To: Claude Buisson Cc: freebsd-arm@freebsd.org, ian@FreeBSD.org Subject: Re: rpi2: cpufreq(4) support lost ? In-Reply-To: <87a7zrgvzv.wl-herbert@mailbox.org> References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 20:59:12 -0000 On Sun, 12 Nov 2017 20:03:32 +0100, "Herbert J. Skuhra" wrote: > > On Sat, 11 Nov 2017 12:47:47 +0100, > Claude Buisson wrote: > > > > [I am not subscribed to this list - please answser to me] > > > > I recently upgraded a RPI2 Model B, from head r323691 armv6 to head > > r325110 + patch D12907 (lib/libc/gen/tls.c) armv7. > > > > In the dmesg, the lines: > > > > bcm2835_cpufreq0: on cpu0 > > bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF > > > > disappeared, and the log shows: > > > > /etc/rc.d/powerd start > > powerd: no cpufreq(4) support -- aborting: No such file or directory > > > > As what seems to be a consequence, the system became much slower. > > > > Everything came back to normal when I copied the old rpi2.dtb to the > > new /boot/msdos/ > > The old rpi2.dtb is from an armv6 build, right? > > > I tried the rpi2.dtb from the lastest snapshot > > FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img > > and cpufreq(4) disappeared again. > > > > What I am missing ? > > The problem obviously exists since the switch to armv7. > > I use rpi2.dtb from my other RPI2 (stable/11). I think the breakage happened earlier... r324184. rpi2.dtb from a r324183 kernel build (armv6) works. -- Herbert From owner-freebsd-arm@freebsd.org Sun Nov 12 22:36:13 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 8362DC7E2AD for ; Sun, 12 Nov 2017 22:36:13 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EA27B77AC8 for ; Sun, 12 Nov 2017 22:36:11 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from localhost ([92.134.207.235]) by mwinf5d11 with ME id ZAc81w00455FxF803Ac8JK; Sun, 12 Nov 2017 23:36:08 +0100 X-ME-Helo: localhost X-ME-Auth: Y2xidWlzc29uQHdhbmFkb28uZnI= X-ME-Date: Sun, 12 Nov 2017 23:36:08 +0100 X-ME-IP: 92.134.207.235 Subject: Re: rpi2: cpufreq(4) support lost ? To: "Herbert J. Skuhra" Cc: freebsd-arm@freebsd.org, ian@FreeBSD.org References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> <878tfbgqnv.wl-herbert@mailbox.org> From: Claude Buisson Message-ID: <7788f998-bc35-7077-1d1e-42388721038c@orange.fr> Date: Sun, 12 Nov 2017 23:36:07 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <878tfbgqnv.wl-herbert@mailbox.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 22:36:13 -0000 On 11/12/2017 21:58, Herbert J. Skuhra wrote: > On Sun, 12 Nov 2017 20:03:32 +0100, > "Herbert J. Skuhra" wrote: >> >> On Sat, 11 Nov 2017 12:47:47 +0100, >> Claude Buisson wrote: >>> >>> [I am not subscribed to this list - please answser to me] >>> >>> I recently upgraded a RPI2 Model B, from head r323691 armv6 to head >>> r325110 + patch D12907 (lib/libc/gen/tls.c) armv7. >>> >>> In the dmesg, the lines: >>> >>> bcm2835_cpufreq0: on cpu0 >>> bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF >>> >>> disappeared, and the log shows: >>> >>> /etc/rc.d/powerd start >>> powerd: no cpufreq(4) support -- aborting: No such file or directory >>> >>> As what seems to be a consequence, the system became much slower. >>> >>> Everything came back to normal when I copied the old rpi2.dtb to the >>> new /boot/msdos/ >> >> The old rpi2.dtb is from an armv6 build, right? >> >>> I tried the rpi2.dtb from the lastest snapshot >>> FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img >>> and cpufreq(4) disappeared again. >>> >>> What I am missing ? >> >> The problem obviously exists since the switch to armv7. >> >> I use rpi2.dtb from my other RPI2 (stable/11). > > I think the breakage happened earlier... r324184. This was my own hypothesis, which leads me nowhere.. > > rpi2.dtb from a r324183 kernel build (armv6) works. > > - > Herbert > Further more the latest snapshot (where cpufreq is missing) does not boot as is: "Unable to read file ubldr" and /boot/unldr must be copied to /boot/msdos Claude Buisson From owner-freebsd-arm@freebsd.org Sun Nov 12 22:38:20 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 F1EB3C7E30C for ; Sun, 12 Nov 2017 22:38:20 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) by mx1.freebsd.org (Postfix) with ESMTP id 935F477B55 for ; Sun, 12 Nov 2017 22:38:19 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from localhost ([92.134.207.235]) by mwinf5d11 with ME id ZAWh1w00A55FxF803AWiyW; Sun, 12 Nov 2017 23:30:42 +0100 X-ME-Helo: localhost X-ME-Auth: Y2xidWlzc29uQHdhbmFkb28uZnI= X-ME-Date: Sun, 12 Nov 2017 23:30:42 +0100 X-ME-IP: 92.134.207.235 Subject: Re: rpi2: cpufreq(4) support lost ? To: "Herbert J. Skuhra" Cc: freebsd-arm@freebsd.org References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> From: Claude Buisson Message-ID: <2cedd4c6-1db0-04e7-b131-b0f0fc2f0500@orange.fr> Date: Sun, 12 Nov 2017 23:30:41 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <87a7zrgvzv.wl-herbert@mailbox.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 22:38:21 -0000 On 11/12/2017 20:03, Herbert J. Skuhra wrote: > On Sat, 11 Nov 2017 12:47:47 +0100, > Claude Buisson wrote: >> >> [I am not subscribed to this list - please answser to me] >> >> I recently upgraded a RPI2 Model B, from head r323691 armv6 to head >> r325110 + patch D12907 (lib/libc/gen/tls.c) armv7. >> >> In the dmesg, the lines: >> >> bcm2835_cpufreq0: on cpu0 >> bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF >> >> disappeared, and the log shows: >> >> /etc/rc.d/powerd start >> powerd: no cpufreq(4) support -- aborting: No such file or directory >> >> As what seems to be a consequence, the system became much slower. >> >> Everything came back to normal when I copied the old rpi2.dtb to the >> new /boot/msdos/ > > The old rpi2.dtb is from an armv6 build, right? Yes: from head r323691 armv6 as documented supra > >> I tried the rpi2.dtb from the lastest snapshot >> FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img >> and cpufreq(4) disappeared again. >> >> What I am missing ? > > The problem obviously exists since the switch to armv7. > > I use rpi2.dtb from my other RPI2 (stable/11). > > -- > Herbert > From owner-freebsd-arm@freebsd.org Sun Nov 12 23:07: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 3C968C7EAA4 for ; Sun, 12 Nov 2017 23:07:04 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 D5E14787E3 for ; Sun, 12 Nov 2017 23:07:03 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x55b14bfb.dyn.telefonica.de [85.177.75.251]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vACN6ogp072727; Mon, 13 Nov 2017 00:06:51 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: "Herbert J. Skuhra" CC: Claude Buisson , freebsd-arm@freebsd.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Mon, 13 Nov 2017 00:06:50 +0100 (CET) Message-ID: <4afca2e89cf.30d26e45@mail.schwarzes.net> In-Reply-To: <87a7zrgvzv.wl-herbert@mailbox.org> References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: rpi2: cpufreq(4) support lost ? MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Mon, 13 Nov 2017 00:06:51 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 23:07:04 -0000 On 12.11.17, Herbert J. Skuhra wrote: >> I tried the rpi2.dtb from the lastest snapshot >> FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img >> and cpufreq(4) disappeared again. >> >> What I am missing ? > > The problem obviously exists since the switch to armv7. It is also there with recent armv6 builds. I run into the problem with r325464 (armv6). I always update the dtb when installing a new world/kernel. So, something musst be wrong with the dtb file. I'm using now a file from r323309, where cpufreq is available again. -asc From owner-freebsd-arm@freebsd.org Mon Nov 13 00:23: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 3D0E1C7FED0 for ; Mon, 13 Nov 2017 00:23:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-166.reflexion.net [208.70.210.166]) (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 E08FE7A2F1 for ; Mon, 13 Nov 2017 00:23:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31855 invoked from network); 12 Nov 2017 23:23:40 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Nov 2017 23:23:40 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 12 Nov 2017 18:23:40 -0500 (EST) Received: (qmail 9304 invoked from network); 12 Nov 2017 23:23:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Nov 2017 23:23:40 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B227DEC941C; Sun, 12 Nov 2017 15:23:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: rpi2: cpufreq(4) support lost ? From: Mark Millard In-Reply-To: <2cedd4c6-1db0-04e7-b131-b0f0fc2f0500@orange.fr> Date: Sun, 12 Nov 2017 15:23:39 -0800 Cc: Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> <2cedd4c6-1db0-04e7-b131-b0f0fc2f0500@orange.fr> To: Claude Buisson , "Herbert J. Skuhra" , Andreas Schwarz X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 00:23:48 -0000 [This is a Linux *.dt* source issue, not specific to amrmv6 vs. armv7: FreeBSD has switched to Linux *.dt* source files, 4.13 most recently if I remember right.] On 2017-Nov-12, at 2:30 PM, Claude Buisson = wrote: > On 11/12/2017 20:03, Herbert J. Skuhra wrote: >> On Sat, 11 Nov 2017 12:47:47 +0100, >> Claude Buisson wrote: >>>=20 >>> [I am not subscribed to this list - please answser to me] >>>=20 >>> I recently upgraded a RPI2 Model B, from head r323691 armv6 to head >>> r325110 + patch D12907 (lib/libc/gen/tls.c) armv7. >>>=20 >>> In the dmesg, the lines: >>>=20 >>> bcm2835_cpufreq0: on cpu0 >>> bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF >>>=20 >>> disappeared, and the log shows: >>>=20 >>> /etc/rc.d/powerd start >>> powerd: no cpufreq(4) support -- aborting: No such file or directory >>>=20 >>> As what seems to be a consequence, the system became much slower. >>>=20 >>> Everything came back to normal when I copied the old rpi2.dtb to the >>> new /boot/msdos/ >> The old rpi2.dtb is from an armv6 build, right? >=20 > Yes: from head r323691 armv6 as documented supra >=20 >>> I tried the rpi2.dtb from the lastest snapshot >>> FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img >>> and cpufreq(4) disappeared again. >>>=20 >>> What I am missing ? >> The problem obviously exists since the switch to armv7. >> I use rpi2.dtb from my other RPI2 (stable/11). Also there was the note: > On 12.11.17, Herbert J. Skuhra wrote: >=20 >>> I tried the rpi2.dtb from the lastest snapshot >>> FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img >>> and cpufreq(4) disappeared again. >>>=20 >>> What I am missing ? >>=20 >> The problem obviously exists since the switch to armv7. >=20 > It is also there with recent armv6 builds. I run into the problem with=20= > r325464 (armv6). I always update the dtb when installing a new = world/kernel. >=20 > So, something musst be wrong with the dtb file. I'm using now a file = from=20 > r323309, where cpufreq is available again. FreeBSD's 12.0 has switched to using the Linux *.dt* source files, even if they are not functionally equivalent to what FreeBSD had before. (I do not track 11.x most of the time and so have not checked there.) The way to get functionality back is to submit *.dt* changes to Linux that are accepted and later FreeBSD will pick up the changes from the Linux update that includes the changes, such as from the future 4.14 update. At least that is my understanding. This went so far as dropping support for things that did not have Linux support at the time, such as for the BPI-M3: the *.dts involved was removed from the Makefile. The *.dt* files are still there but a *.dts needs a patch. USB support for A83T (which the BPI-M3 is an example of) was eliminated from some source code in its conversion as well --and needs a patch to be enabled again. (Part of the issue for the BPI-M3 is what FreeBSD committers have one vs. not having one to test.) Folks that are willing can locally restore BPI-M3 support. The sysutils/u-boot-sinovoip-bpi-m3 port was not removed but has not been modernized to be based on sysutils/u-boot-master --but that is from lack of Linux support as of 4.13 as far as I can tell. (Once 4.14 is grabbed sysutils/u-boot-sinovoip-bpi-m3 might update at some point.) One of the FreeBSD folks has set up for when 4.14 adds BPI-M3 support. But I do not know about the detailed functionality comparison since the *.dt* source files might issues similar to the rpi2. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Nov 13 06:04: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 C0DF0D1F29E for ; Mon, 13 Nov 2017 06:04:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95BE5354A for ; Mon, 13 Nov 2017 06:04:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vAD64ixA099214 for ; Mon, 13 Nov 2017 06:04:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223642] ds3231 iic driver can't initialise a new device Date: Mon, 13 Nov 2017 06:04:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bscott@bunyatech.com.au X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 06:04:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223642 Bug ID: 223642 Summary: ds3231 iic driver can't initialise a new device Product: Base System Version: 11.1-STABLE Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: bscott@bunyatech.com.au Created attachment 187954 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D187954&action= =3Dedit Patch to change failures to start the oscillator and acknowledge interrupts= to be warnings During initialisation of the ds3231 rtc driver it attempts to enable the oscillator and acknowledge any alarm conditions. For a brand new, never powered device this is rejected until the time has b= een set, however because these calls fail the device isn't started and the time= is never set. Writing a quick and dirty program based on the i2c utility I have initialis= ed the device without using the driver. When loaded, the driver proceeds norma= lly and uses the device as intended. I have patched the driver (sys/dev/iicbus/ds3231.c) to just warn on failure= s of the two calls mentioned earlier. I haven't found any way to return one of the chips back to pristine conditi= on. Fortunately I had another device that I had purchased but never used that I could use to test the change with and had the device accepted properly (wit= h a few extra warning messages on first boot). It's quite possible that other suppliers actually test these devices before selling them and that normally they have some time setting when first installed. Mine where $2 each from Malaysia with free shipping so I couldn't really expect much. I don't know if other people would experience the same problem. While debugging this, I have also noticed that the device is initialised wi= th a zero based day of week (i.e. 0-6) but the specification for the device is f= or a value from 1 to 7. The value returned by the device is never used so this shouldn't matter unless some version of the chip in the future enforces the specification for some reason. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Nov 13 09:54: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 A6AB8D7EF31 for ; Mon, 13 Nov 2017 09:54:40 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1066567E41 for ; Mon, 13 Nov 2017 09:54:39 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 3fc2834e; Mon, 13 Nov 2017 10:54:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=M+V/aFxfVvBz/DuCV24hWDafCeA=; b=kBZZljax1Xq3Z7asLD3pedNjvQpV UowQYRlR2gS6iUcby8IDHwpfpz0sZHa/A2Boiz6V9ZdF2pp1VX4LjLa5rlHBW2ju c/RXdRIjnTeIYec+xQ7QQawpilRKL9a+UI7EGFZYBzfDliVUKHzpl4mvAU3oljwg bDn5zEvkfUZyziI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=Lmb6jgDadWzQ314GKfLyT8uHDZq5UfHpr5jL0VyuxvDUIK83ueLjgmFn brKABucrK2BZmWxFc2sZ6hu2qdZ+N61Bt4oZuCsepkwnSUxWSO0eb/7r0Xr/VQN7 mGoz9gPpHFiqqFXpk+MrGmYpYBnkL+sLtV57Ym/ziVYYqnasVQU= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id e962cfb4 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 13 Nov 2017 10:54:30 +0100 (CET) Date: Mon, 13 Nov 2017 10:54:30 +0100 From: Emmanuel Vadot To: Mark Millard Cc: Claude Buisson , "Herbert J. Skuhra" , Andreas Schwarz , Freebsd-arm Subject: Re: rpi2: cpufreq(4) support lost ? Message-Id: <20171113105430.720cdb0f887138b89c8e271e@bidouilliste.com> In-Reply-To: References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> <2cedd4c6-1db0-04e7-b131-b0f0fc2f0500@orange.fr> X-Mailer: Sylpheed 3.6.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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:54:40 -0000 On Sun, 12 Nov 2017 15:23:39 -0800 Mark Millard wrote: > [This is a Linux *.dt* source issue, not specific to > amrmv6 vs. armv7: FreeBSD has switched to Linux *.dt* > source files, 4.13 most recently if I remember right.] This we do not use the DTS from Linux for RPI1/2 I doubt that. > On 2017-Nov-12, at 2:30 PM, Claude Buisson wrote: > > > On 11/12/2017 20:03, Herbert J. Skuhra wrote: > >> On Sat, 11 Nov 2017 12:47:47 +0100, > >> Claude Buisson wrote: > >>> > >>> [I am not subscribed to this list - please answser to me] > >>> > >>> I recently upgraded a RPI2 Model B, from head r323691 armv6 to head > >>> r325110 + patch D12907 (lib/libc/gen/tls.c) armv7. > >>> > >>> In the dmesg, the lines: > >>> > >>> bcm2835_cpufreq0: on cpu0 > >>> bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF > >>> > >>> disappeared, and the log shows: > >>> > >>> /etc/rc.d/powerd start > >>> powerd: no cpufreq(4) support -- aborting: No such file or directory > >>> > >>> As what seems to be a consequence, the system became much slower. > >>> > >>> Everything came back to normal when I copied the old rpi2.dtb to the > >>> new /boot/msdos/ > >> The old rpi2.dtb is from an armv6 build, right? > > > > Yes: from head r323691 armv6 as documented supra > > > >>> I tried the rpi2.dtb from the lastest snapshot > >>> FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img > >>> and cpufreq(4) disappeared again. > >>> > >>> What I am missing ? > >> The problem obviously exists since the switch to armv7. > >> I use rpi2.dtb from my other RPI2 (stable/11). > > Also there was the note: > > > On 12.11.17, Herbert J. Skuhra wrote: > > > >>> I tried the rpi2.dtb from the lastest snapshot > >>> FreeBSD-12.0-CURRENT-arm-armv7-RPI2-20171109-r325595.img > >>> and cpufreq(4) disappeared again. > >>> > >>> What I am missing ? > >> > >> The problem obviously exists since the switch to armv7. > > > > It is also there with recent armv6 builds. I run into the problem with > > r325464 (armv6). I always update the dtb when installing a new world/kernel. > > > > So, something musst be wrong with the dtb file. I'm using now a file from > > r323309, where cpufreq is available again. > > FreeBSD's 12.0 has switched to using the Linux > *.dt* source files, even if they are not functionally > equivalent to what FreeBSD had before. (I do not > track 11.x most of the time and so have not checked > there.) Not true, it depends on boards/SoC. Even FreeBSD 11 uses Linux DTS for Allwinner for example. > The way to get functionality back is to submit *.dt* > changes to Linux that are accepted and later FreeBSD > will pick up the changes from the Linux update that > includes the changes, such as from the future 4.14 > update. At least that is my understanding. The way to get functionality back is to find the real problem. > This went so far as dropping support for things that > did not have Linux support at the time, such as for > the BPI-M3: the *.dts involved was removed from the > Makefile. The *.dt* files are still there but a > *.dts needs a patch. USB support for A83T (which the > BPI-M3 is an example of) was eliminated from some > source code in its conversion as well --and needs a > patch to be enabled again. > > (Part of the issue for the BPI-M3 is what FreeBSD > committers have one vs. not having one to test.) > > Folks that are willing can locally restore BPI-M3 > support. The sysutils/u-boot-sinovoip-bpi-m3 port > was not removed but has not been modernized to be > based on sysutils/u-boot-master --but that is from > lack of Linux support as of 4.13 as far as I can > tell. (Once 4.14 is grabbed > sysutils/u-boot-sinovoip-bpi-m3 might update > at some point.) > > One of the FreeBSD folks has set up for when 4.14 > adds BPI-M3 support. But I do not know about the > detailed functionality comparison since the *.dt* > source files might issues similar to the rpi2. > > === > Mark Millard > markmi at dsl-only.net All this is mostly wrong and doesn't have anything to do with the cpufreq problem on RPI2. Please stay focus. > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Nov 13 11:44:55 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 CAADDDB0FA9 for ; Mon, 13 Nov 2017 11:44:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-104.reflexion.net [208.70.210.104]) (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 7D3476AE23 for ; Mon, 13 Nov 2017 11:44:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28783 invoked from network); 13 Nov 2017 11:18:08 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Nov 2017 11:18:08 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 13 Nov 2017 06:18:08 -0500 (EST) Received: (qmail 15763 invoked from network); 13 Nov 2017 11:18:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Nov 2017 11:18:08 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7A71EEC7A08; Mon, 13 Nov 2017 03:18:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: rpi2: cpufreq(4) support lost ? From: Mark Millard In-Reply-To: <20171113105430.720cdb0f887138b89c8e271e@bidouilliste.com> Date: Mon, 13 Nov 2017 03:18:06 -0800 Cc: Claude Buisson , "Herbert J. Skuhra" , Andreas Schwarz , Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> <2cedd4c6-1db0-04e7-b131-b0f0fc2f0500@orange.fr> <20171113105430.720cdb0f887138b89c8e271e@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 11:44:55 -0000 [sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c does not list "brcm,bcm2836": That is what I would have found if I had looked at the details before babbling incoherently.] On 2017-Nov-13, at 1:54 AM, Emmanuel Vadot = wrote: > On Sun, 12 Nov 2017 15:23:39 -0800 > Mark Millard wrote: >=20 >> [This is a Linux *.dt* source issue, not specific to >> amrmv6 vs. armv7: FreeBSD has switched to Linux *.dt* >> source files, 4.13 most recently if I remember right.] >=20 > This we do not use the DTS from Linux for RPI1/2 I doubt that. My apologies to all for the mistake for the rpi* context. >> On 2017-Nov-12, at 2:30 PM, Claude Buisson = wrote: >>=20 >>> On 11/12/2017 20:03, Herbert J. Skuhra wrote: >>> . . . >>>=20 >>> So, something musst be wrong with the dtb file. I'm using now a file = from=20 >>> r323309, where cpufreq is available again. >> . . . >=20 > The way to get functionality back is to find the real problem. Looking around, if I gather right, the only *.dt* source change after -r323309 was in -r324184 in rpi2.dts : compatible =3D "brcm,bcm2709"; was replaced by: compatible =3D "brcm,bcm2836"; Folks are reporting that the new code works with the old .dtb from before this change. This suggests that may be the differences between the lines: FDT_PLATFORM_DEF2(bcm2836, bcm2836_legacy, "bcm2836 (legacy)", 0, = "brcm,bcm2709", 100); FDT_PLATFORM_DEF2(bcm2836, bcm2836, "bcm2836", 0, "brcm,bcm2836", 100); in sys/arm/broadcom/bcm2835/bcm2835_machdep.c might be involved in some way. In fact: /usr/src/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c has: static struct ofw_compat_data compat_data[] =3D { { "broadcom,bcm2835-vc", 1 }, { "broadcom,bcm2708-vc", 1 }, { "brcm,bcm2709", 1 }, { NULL, 0 } }; which does not list "brcm,bcm2836" as an alternative but does list the "brcm,bcm2709" alternative. My guess is this explains the cpufreq code working for the older *.dtb files but not the newer ones. >> . . . >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > All this is mostly wrong and doesn't have anything to do with the > cpufreq problem on RPI2. Again: sorry for the misapplied context. > Please stay focus. I clearly did not do appropriate investigation and incorrectly presumed what context would apply. My mistake for sure. Side note relative to BPI-M3 . . . FYI: The beginning of: = https://lists.freebsd.org/pipermail/freebsd-arm/2017-November/017039.html lists what I've done locally to keep the BPI-M3 going as of head -r325700 . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Nov 13 12:20: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 57DA8DB926F for ; Mon, 13 Nov 2017 12:20:04 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C59D96C1FA for ; Mon, 13 Nov 2017 12:20:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id d335377e; Mon, 13 Nov 2017 13:20:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=wDzq8FeI+I4LPmrFuw6m/eWW84U=; b=eZ7vLbQiHw7kUuClu1vpTAEe66Nq Md1t8S5LXj7Twqcgy8UrjpXK7Fu6g3QBgHm1jxtA0rDAIQs+AS7QagmOh03eJYBV 3OBRp8yx4lpuaFRpCr1Q1A+sXtWYpsMAb3q+sdb1Gl6TPqt9uNcXF+avJmoPuEDD k96bWd0Alui/Fas= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=Eq+uW2urMKIVWb7p30p3qr/70aXKqcWNuFjKe8xRrRCN1Kw4aF8uQFmg HCbB1qbHa2gPIciWipeyFkfZ+dp5MhfeQg3pm3H6Mq8Vol1z5OI5onzgKJIDViqo yXHrzTpYDLyxrxJxqi9LgdZI+M699IKPkMxOwQks/wKNDLVUKaQ= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 3c46c1b0 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 13 Nov 2017 13:20:00 +0100 (CET) Date: Mon, 13 Nov 2017 13:20:00 +0100 From: Emmanuel Vadot To: Mark Millard Cc: Claude Buisson , "Herbert J. Skuhra" , Andreas Schwarz , Freebsd-arm Subject: Re: rpi2: cpufreq(4) support lost ? Message-Id: <20171113132000.1d680b95d87bd034c3945bb5@bidouilliste.com> In-Reply-To: References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> <2cedd4c6-1db0-04e7-b131-b0f0fc2f0500@orange.fr> <20171113105430.720cdb0f887138b89c8e271e@bidouilliste.com> X-Mailer: Sylpheed 3.6.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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 12:20:04 -0000 On Mon, 13 Nov 2017 03:18:06 -0800 Mark Millard wrote: > [sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c does not > list "brcm,bcm2836": That is what I would have found > if I had looked at the details before babbling > incoherently.] That seems to be the problem yes. I'll confirm tonight and commit a fix if nobody does it before me. > On 2017-Nov-13, at 1:54 AM, Emmanuel Vadot wrote: > > > On Sun, 12 Nov 2017 15:23:39 -0800 > > Mark Millard wrote: > > > >> [This is a Linux *.dt* source issue, not specific to > >> amrmv6 vs. armv7: FreeBSD has switched to Linux *.dt* > >> source files, 4.13 most recently if I remember right.] > > > > This we do not use the DTS from Linux for RPI1/2 I doubt that. > > My apologies to all for the mistake for the rpi* context. > > >> On 2017-Nov-12, at 2:30 PM, Claude Buisson wrote: > >> > >>> On 11/12/2017 20:03, Herbert J. Skuhra wrote: > >>> . . . > >>> > >>> So, something musst be wrong with the dtb file. I'm using now a file from > >>> r323309, where cpufreq is available again. > >> . . . > > > > The way to get functionality back is to find the real problem. > > Looking around, if I gather right, the only *.dt* > source change after -r323309 was in -r324184 > in rpi2.dts : > > compatible = "brcm,bcm2709"; > > was replaced by: > > compatible = "brcm,bcm2836"; > > Folks are reporting that the new code works with > the old .dtb from before this change. This suggests > that may be the differences between the lines: > > FDT_PLATFORM_DEF2(bcm2836, bcm2836_legacy, "bcm2836 (legacy)", 0, "brcm,bcm2709", 100); > FDT_PLATFORM_DEF2(bcm2836, bcm2836, "bcm2836", 0, "brcm,bcm2836", 100); > > in sys/arm/broadcom/bcm2835/bcm2835_machdep.c might > be involved in some way. In fact: > > /usr/src/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c > > has: > > static struct ofw_compat_data compat_data[] = { > { "broadcom,bcm2835-vc", 1 }, > { "broadcom,bcm2708-vc", 1 }, > { "brcm,bcm2709", 1 }, > { NULL, 0 } > }; > > which does not list "brcm,bcm2836" as an alternative > but does list the "brcm,bcm2709" alternative. > > My guess is this explains the cpufreq code working > for the older *.dtb files but not the newer ones. > > >> . . . > >> > >> === > >> Mark Millard > >> markmi at dsl-only.net > > > > All this is mostly wrong and doesn't have anything to do with the > > cpufreq problem on RPI2. > > Again: sorry for the misapplied context. > > > Please stay focus. > > I clearly did not do appropriate investigation > and incorrectly presumed what context would apply. > My mistake for sure. > > > Side note relative to BPI-M3 . . . > > FYI: The beginning of: > > https://lists.freebsd.org/pipermail/freebsd-arm/2017-November/017039.html > > lists what I've done locally to keep the BPI-M3 going as > of head -r325700 . > > === > Mark Millard > markmi at dsl-only.net -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Nov 13 15:38: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 72E68DBD5E3 for ; Mon, 13 Nov 2017 15:38:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 573407265F for ; Mon, 13 Nov 2017 15:38:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vADFcem7004721 for ; Mon, 13 Nov 2017 15:38:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223653] Extremely serious string manipulation problem in -HEAD Date: Mon, 13 Nov 2017 15:38:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: karl@denninger.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:38:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223653 Bug ID: 223653 Summary: Extremely serious string manipulation problem in -HEAD Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: karl@denninger.net Take the following tiny code snippet: #include #include int main(argc, argv) int argc; char *argv[]; { char tmp[132]; char tmp2[132]; strcpy(tmp, "00 01 02 03 04 05 06"); printf("First: [%s]\n", tmp); strcpy(tmp, &tmp[3]); printf("Second: [%s]\n", tmp); strcpy(tmp, &tmp[3]); printf("Third: [%s]\n", tmp); strcpy(tmp, &tmp[3]); printf("Fourth: [%s]\n", tmp); strcpy(tmp, "00 01 02 03 04 05 06"); printf("2-First: [%s]\n", tmp); strcpy(tmp2, &tmp[3]); strcpy(tmp, tmp2); printf("2-Second: [%s]\n", tmp); strcpy(tmp2, &tmp[3]); strcpy(tmp, tmp2); printf("2-Third: [%s]\n", tmp); strcpy(tmp2, &tmp[3]); strcpy(tmp, tmp2); printf("2-Fourth: [%s]\n", tmp); } Compile it on FreeBSD 12.0-CURRENT #0 r325754: Mon Nov 13 08:02:13 CST 2017= on an RPI3 and run it. root@rpi3:/data/HD-MCP # ./test2 First: [00 01 02 03 04 05 06] Second: [02 04 05 05 06 06] Third: [04 05 05 06 06] Fourth: [05 05 06 06] 2-First: [00 01 02 03 04 05 06] 2-Second: [01 02 03 04 05 06] 2-Third: [02 03 04 05 06] 2-Fourth: [03 04 05 06] root@rpi3:/data/HD-MCP # Yes, I'm aware that strcpy with overlapping strings is not safe in all instances (strcpy is of course unsafe if the source can be longer than where you are copying into) but historically it has been safe when used to remove some number of bytes from the left side ("front") of a string as the destination cannot overflow and on a byte-wise copy code that is generated = it stops as expected after the trailing null is copied over. There's also no note in the current man page that this is unsafe. Rewriting the strcpys to use memmove corrects the above problem (memmove specifically= is ok to use in all cases of overlapping storage of course) but this change is likely to bite a material number of people and has not been a problem on any architecture I've seen under FreeBSD until fairly recently (it did not cause problems with a February build of -HEAD on the RPI3/arm64, for example.) I note that if I try to link OPENSSL into a piece of code I have here I get= a trap immediately on an "illegal opcode" when I try to execute the resulting binary, which may be due to this happening somewhere in the initialization code. I get no frame labels on the backtrace, and the trap occurs before main() starts executing (a breakpoint set on the first actual instruction in main() fails to be reached) so unfortunately I do not have a better trace on what's going on. I suspect the behavior above, or some other artifact of t= he same change, is responsible for the below; the code in question has been running on an RPI2 (which right now I am using under FreeBSD 11.0-STABLE #1 r313159M) and various Intel (i386 and Amd64) architectures, also under 11-Stable, for a long period of time: root@rpi3:/data/HD-MCP # lldb hd-mcp (lldb) target create "hd-mcp" Current executable set to 'hd-mcp' (aarch64). (lldb) run -n Process 924 launching Process 924 launched: '/data/HD-MCP/hd-mcp' (aarch64) Process 924 stopped * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: illegal trap frame #0: 0x00000000403342e8 -> 0x403342e8: .long 0x0ee0e000 ; unknown opcode 0x403342ec: ret 0x403342f0: stp x28, x19, [sp, #-0x20]! 0x403342f4: stp x29, x30, [sp, #0x10] (lldb) bt * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: illegal trap * frame #0: 0x00000000403342e8 frame #1: 0x0000000040082ad8 frame #2: 0x0000000040081ab4 (lldb) If I leave OpenSSL out (I have a "no security" version that #ifdef's it out) then the code compiles and runs fine. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Nov 13 15:54: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 B98FCDBDB97 for ; Mon, 13 Nov 2017 15:54:34 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 926C072E3B for ; Mon, 13 Nov 2017 15:54:34 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id E9E0627334 for ; Mon, 13 Nov 2017 10:54:33 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 040113B0496 for ; Mon, 13 Nov 2017 09:54:31 -0600 (CST) Subject: Re: Very bizarre behavior ARM64 (Pi3) To: freebsd-arm@freebsd.org References: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> From: Karl Denninger Message-ID: <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> Date: Mon, 13 Nov 2017 09:54:30 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010708020002080602010301" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:54:34 -0000 This is a cryptographically signed message in MIME format. --------------ms010708020002080602010301 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/12/2017 12:02, Karl Denninger wrote: > I managed to get around the Crochet blow-up I reported the other day > with another svn update, and now can Crochet myself a running image for= > the Pi3 which boots and (at least at first blush) works. > > But I have code that has been running on the Pi3 (and also on the Pi2, > along with other architectures) for quite some time that no longer runs= > when compiled on that newly-built OS.=C2=A0 It compiles without warning= s or > errors but blows up immediately when executed. > > I just tried to roll that build forward to the newly-built (FreeBSD > 12.0-CURRENT #0 r325681M: Fri Nov 10 19:31:28 CST 2017)=C2=A0 -HEAD and= am > getting really bizarre core dumps, including (if compiled using OpenSSL= > libraries) a crash on initialization claiming unknown opcodes in the > compiled binary. > > root@rpi3:/data/HD-MCP # lldb hd-mcp > (lldb) target create "hd-mcp" > Current executable set to 'hd-mcp' (aarch64). > (lldb) run -n > Process 1101 launching > Process 1101 launched: '/data/HD-MCP/hd-mcp' (aarch64) > Process 1101 stopped > * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: illegal = trap > =C2=A0=C2=A0=C2=A0 frame #0: 0x00000000403342e8 > ->=C2=A0 0x403342e8: .long=C2=A0 0x0ee0e000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; unknown op= code > =C2=A0=C2=A0=C2=A0 0x403342ec: ret > =C2=A0=C2=A0=C2=A0 0x403342f0: stp=C2=A0=C2=A0=C2=A0 x28, x19, [sp, #-0= x20]! > =C2=A0=C2=A0=C2=A0 0x403342f4: stp=C2=A0=C2=A0=C2=A0 x29, x30, [sp, #0x= 10] > (lldb) bt > * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: illegal = trap > =C2=A0 * frame #0: 0x00000000403342e8 > =C2=A0=C2=A0=C2=A0 frame #1: 0x0000000040082ad8 > =C2=A0=C2=A0=C2=A0 frame #2: 0x0000000040081ab4 > (lldb) > > If I compile and link with OpenSSL omitted (which is an option in the > software in question) then I get blowups shortly after the software > starts implying the stack is getting smashed in bizarre ways that don't= > make any sense. > > The same source has been running for months uninterrupted on 11.x hoste= d > on a Pi2 and used to run just fine on a Pi3 from a build I last updated= > back in February. > > To top it off lldb blows up if I set a breakpoint (or get a SEGV and > trap back to it) and try to print anything out of the current frame > (e.g. the variables in the function that blew) so it's basically > impossible to figure out what's getting hammered in the stack if I leav= e > the OpenSSL libraries out. > > Are there known issues with the arm64 architecture in -HEAD at present?= I MAY know what is going on here; see this report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223653 If I link without OpenSSL (no -lcrypto and no -lssl) then my code runs fine (I have a build-time option to not use encryption of any sort for demonstration reasons.)=C2=A0 But even attempting to link the SSL librari= es causes the above blowup in front of main(); a breakpoint on the first actual statement in main() (which is an initialization of a variable) is not reached; the trap comes first. Why the above behavior would cause code linked with SSL libraries to blow up on start I do not know, and there is nothing in the backtrace that helps me identify exactly where it dies...... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010708020002080602010301 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 DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTEzMTU1NDMw WjBPBgkqhkiG9w0BCQQxQgRAnImZ8hFGjzklzeGf7iWt/Ts0PC+Rrz6NBzSUEd3UloP1WSQK KwmmR1mIQuYLPtGhEysaKrk5qFr0NvfzmvjvmzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgB7bPGX8WyKgarC9TNRwDc48izh4rBrj4ZU+KTTlBgoBnrMs4dRlf+iQeG+0b+iWTuN 5UUZXUf45WL26rVRe9nEQnlht72S+WZ2sSqQ0MNAyeiklRkIJqsNf4W5nvUamlLLuqF8AeLf l9jKcN4TVG5mLhsfcYPVtSIWDAVei7hKlsoiwFXSDAWydX+2ho/Tlr3oaxNtXCxG7eijPQEj 3s65Xyyh88gBW19Etlb5EMrSUmIOAmvk0yzbX7LHWV+4jK5Jm7xXLNevLEBQH3Nj9abfneEV GwYkFQa+RK1gsrmXtpwjra9ypByGXyGK5f1yXhQwqkBmWFn8R+XUeeJaF8SMRQstiP6Yumsn CB8FWchTj+e1RNa02W2IMHgrrj9O5i7aiXm9K+pEk7/+nXfhnjFdivmRUi1kgiTlLJjYpAH2 aktNLafIuW7RMdA01LEvyC56IQh3gE134bS3pNXd2Va6t4RN5Fl4C1EgdRfPsw9x2w/tNYcT 8zbIBCtpJumKZfd+xCpl7g4ZB5EfAv21+XvY8j4rrivmqFE5u5rbJ6uburrFh+jDTbyL90yH /YDiJd2a0Ly3tTvVUr+nMOswdlgvupvlyWUlzYmoUO6nVPRzJ4+yWZCRKInqQEZNgh4OVA+d +FmW+xbogm4O4ApXF6SnNlRMUm9Fsfwaw9RjXTILZwAAAAAAAA== --------------ms010708020002080602010301-- From owner-freebsd-arm@freebsd.org Mon Nov 13 16:26: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 057C1DBE89B for ; Mon, 13 Nov 2017 16:26:06 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8857373F48 for ; Mon, 13 Nov 2017 16:26:05 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id r68so15986309wmr.1 for ; Mon, 13 Nov 2017 08:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2gl4YLDqT6gqbejm/gvklqrXbpM+Tz644EVdIBlR1uM=; b=P1WX7HnsOo052oDXtcjDNLwQupnijZWrGj5i1jCbD9/LB/PBVePlntv/Zhqik8WXeC NTZ7jhofWoA5zSi5/qpML07Yhmo33abmx6OrZ3Y0djW/suE8vrOh+eN2jGyT5+huiIjJ gODRv5j1R29P6ez7BoE6KFXmDSRMLrOIPdNCVXkJWFbPCYdPebUjILx+tAXEsz7K+0Hx 8ewdE90b8MxSk2U0VvTjzy66XmFN3qm5DeN6Cri5ClReqsx6RfT9Z5C1qKZMr02/u9yN W2NYVjmW945xgWNWfFYJ7Xt9YAl1VJmwnv/iB2Ptwn4YDQUYIM6tvfKOOCI078ncRMbs nVwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2gl4YLDqT6gqbejm/gvklqrXbpM+Tz644EVdIBlR1uM=; b=F5F5uVU2SWptg2OhQBj8IWPgTCLaavozWLGhzFvpSTDUKoUZ1uoxOZVda2XyGeA52o CC1KBqCGZGuMAZO33zlSZEOsnun8rsiuq3S8bSzA9FMhb0E80Lw1kFrMCO8HrGALNfaY 9e6RkcBhyT19qWj+9D7WCoELpn17Af/BZ38bgYCDKxOkE979reZ/TKbaHAP/FlcT61MM mhlcVM7095bRs7FxWNIT6ntn9r1MD5X33OXJmneVet5uDtfHtgvoh3otpWiPbW5MR6gm JHKdttEMqZuNN1/Qb+SnyG/A02RDfQLg12eVdL6qfI+BOP8y2arPmL4HoqFWqw8/d9pI DLPg== X-Gm-Message-State: AJaThX6DGxEg1h3dmyHU837onAknPJeKy8X0mVa+XoyjltsJ5GlEeQim x2fO6FCy8xnVcR8rM0dnta7RGOqZ X-Google-Smtp-Source: AGs4zMbmBiGDB6N45lIbum0hE0nxdsINsxXldPBqAp1f8rSAiJ+19mkBwbRcr6ksBdTjutBs1h/AyQ== X-Received: by 10.80.136.113 with SMTP id c46mr12076423edc.112.1510590363696; Mon, 13 Nov 2017 08:26:03 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id 3sm12556352edv.50.2017.11.13.08.26.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 08:26:03 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: meloun.michal@gmail.com Subject: Re: Very bizarre behavior ARM64 (Pi3) To: freebsd-arm@freebsd.org References: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> Message-ID: Date: Mon, 13 Nov 2017 17:26:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 16:26:06 -0000 On 13.11.2017 16:54, Karl Denninger wrote: > On 11/12/2017 12:02, Karl Denninger wrote: >> I managed to get around the Crochet blow-up I reported the other day >> with another svn update, and now can Crochet myself a running image for >> the Pi3 which boots and (at least at first blush) works. >> >> But I have code that has been running on the Pi3 (and also on the Pi2, >> along with other architectures) for quite some time that no longer runs >> when compiled on that newly-built OS. It compiles without warnings or >> errors but blows up immediately when executed. >> >> I just tried to roll that build forward to the newly-built (FreeBSD >> 12.0-CURRENT #0 r325681M: Fri Nov 10 19:31:28 CST 2017) -HEAD and am >> getting really bizarre core dumps, including (if compiled using OpenSSL >> libraries) a crash on initialization claiming unknown opcodes in the >> compiled binary. >> >> root@rpi3:/data/HD-MCP # lldb hd-mcp >> (lldb) target create "hd-mcp" >> Current executable set to 'hd-mcp' (aarch64). >> (lldb) run -n >> Process 1101 launching >> Process 1101 launched: '/data/HD-MCP/hd-mcp' (aarch64) >> Process 1101 stopped >> * thread #1, name = 'hd-mcp', stop reason = signal SIGILL: illegal trap >> frame #0: 0x00000000403342e8 >> -> 0x403342e8: .long 0x0ee0e000 ; unknown opcode >> 0x403342ec: ret >> 0x403342f0: stp x28, x19, [sp, #-0x20]! >> 0x403342f4: stp x29, x30, [sp, #0x10] >> (lldb) bt >> * thread #1, name = 'hd-mcp', stop reason = signal SIGILL: illegal trap >> * frame #0: 0x00000000403342e8 >> frame #1: 0x0000000040082ad8 >> frame #2: 0x0000000040081ab4 >> (lldb) >> That is pretty standard behavior. 0x0ee0e000 opcode is optional pmull crypto extension instruction and OpenSSL tests the availability of these optional instructions in this way. It have SIGILL handler installed and if a signal is hit, it means that these extensions are not available. Simply hit 'c' and ignore it... Michal >> If I compile and link with OpenSSL omitted (which is an option in the >> software in question) then I get blowups shortly after the software >> starts implying the stack is getting smashed in bizarre ways that don't >> make any sense. >> >> The same source has been running for months uninterrupted on 11.x hosted >> on a Pi2 and used to run just fine on a Pi3 from a build I last updated >> back in February. >> >> To top it off lldb blows up if I set a breakpoint (or get a SEGV and >> trap back to it) and try to print anything out of the current frame >> (e.g. the variables in the function that blew) so it's basically >> impossible to figure out what's getting hammered in the stack if I leave >> the OpenSSL libraries out. >> >> Are there known issues with the arm64 architecture in -HEAD at present? > > I MAY know what is going on here; see this report: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223653 > > If I link without OpenSSL (no -lcrypto and no -lssl) then my code runs > fine (I have a build-time option to not use encryption of any sort for > demonstration reasons.) But even attempting to link the SSL libraries > causes the above blowup in front of main(); a breakpoint on the first > actual statement in main() (which is an initialization of a variable) is > not reached; the trap comes first. > > Why the above behavior would cause code linked with SSL libraries to > blow up on start I do not know, and there is nothing in the backtrace > that helps me identify exactly where it dies...... > From owner-freebsd-arm@freebsd.org Mon Nov 13 16:33:02 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 7055CDBEAB2 for ; Mon, 13 Nov 2017 16:33:02 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 43ADB74280 for ; Mon, 13 Nov 2017 16:33:01 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 315D827334 for ; Mon, 13 Nov 2017 11:33:02 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 579FD3935A7 for ; Mon, 13 Nov 2017 10:33:00 -0600 (CST) Subject: Re: Very bizarre behavior ARM64 (Pi3) To: freebsd-arm@freebsd.org References: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> From: Karl Denninger Message-ID: <9e053fe6-90af-a96b-970a-cdb07f802cca@denninger.net> Date: Mon, 13 Nov 2017 10:32:58 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030008080208080408050600" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 16:33:02 -0000 This is a cryptographically signed message in MIME format. --------------ms030008080208080408050600 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 T24gMTEvMTMvMjAxNyAxMDoyNiwgTWljaGFsIE1lbG91biB3cm90ZToNCj4NCj4gT24gMTMu MTEuMjAxNyAxNjo1NCwgS2FybCBEZW5uaW5nZXIgd3JvdGU6DQo+PiBPbiAxMS8xMi8yMDE3 IDEyOjAyLCBLYXJsIERlbm5pbmdlciB3cm90ZToNCj4+PiBJIG1hbmFnZWQgdG8gZ2V0IGFy b3VuZCB0aGUgQ3JvY2hldCBibG93LXVwIEkgcmVwb3J0ZWQgdGhlIG90aGVyIGRheQ0KPj4+ IHdpdGggYW5vdGhlciBzdm4gdXBkYXRlLCBhbmQgbm93IGNhbiBDcm9jaGV0IG15c2VsZiBh IHJ1bm5pbmcgaW1hZ2UgZm9yDQo+Pj4gdGhlIFBpMyB3aGljaCBib290cyBhbmQgKGF0IGxl YXN0IGF0IGZpcnN0IGJsdXNoKSB3b3Jrcy4NCj4+Pg0KPj4+IEJ1dCBJIGhhdmUgY29kZSB0 aGF0IGhhcyBiZWVuIHJ1bm5pbmcgb24gdGhlIFBpMyAoYW5kIGFsc28gb24gdGhlIFBpMiwN Cj4+PiBhbG9uZyB3aXRoIG90aGVyIGFyY2hpdGVjdHVyZXMpIGZvciBxdWl0ZSBzb21lIHRp bWUgdGhhdCBubyBsb25nZXIgcnVucw0KPj4+IHdoZW4gY29tcGlsZWQgb24gdGhhdCBuZXds eS1idWlsdCBPUy4gIEl0IGNvbXBpbGVzIHdpdGhvdXQgd2FybmluZ3Mgb3INCj4+PiBlcnJv cnMgYnV0IGJsb3dzIHVwIGltbWVkaWF0ZWx5IHdoZW4gZXhlY3V0ZWQuDQo+Pj4NCj4+PiBJ IGp1c3QgdHJpZWQgdG8gcm9sbCB0aGF0IGJ1aWxkIGZvcndhcmQgdG8gdGhlIG5ld2x5LWJ1 aWx0IChGcmVlQlNEDQo+Pj4gMTIuMC1DVVJSRU5UICMwIHIzMjU2ODFNOiBGcmkgTm92IDEw IDE5OjMxOjI4IENTVCAyMDE3KSAgLUhFQUQgYW5kIGFtDQo+Pj4gZ2V0dGluZyByZWFsbHkg Yml6YXJyZSBjb3JlIGR1bXBzLCBpbmNsdWRpbmcgKGlmIGNvbXBpbGVkIHVzaW5nIE9wZW5T U0wNCj4+PiBsaWJyYXJpZXMpIGEgY3Jhc2ggb24gaW5pdGlhbGl6YXRpb24gY2xhaW1pbmcg dW5rbm93biBvcGNvZGVzIGluIHRoZQ0KPj4+IGNvbXBpbGVkIGJpbmFyeS4NCj4+Pg0KPj4+ IHJvb3RAcnBpMzovZGF0YS9IRC1NQ1AgIyBsbGRiIGhkLW1jcA0KPj4+IChsbGRiKSB0YXJn ZXQgY3JlYXRlICJoZC1tY3AiDQo+Pj4gQ3VycmVudCBleGVjdXRhYmxlIHNldCB0byAnaGQt bWNwJyAoYWFyY2g2NCkuDQo+Pj4gKGxsZGIpIHJ1biAtbg0KPj4+IFByb2Nlc3MgMTEwMSBs YXVuY2hpbmcNCj4+PiBQcm9jZXNzIDExMDEgbGF1bmNoZWQ6ICcvZGF0YS9IRC1NQ1AvaGQt bWNwJyAoYWFyY2g2NCkNCj4+PiBQcm9jZXNzIDExMDEgc3RvcHBlZA0KPj4+ICogdGhyZWFk ICMxLCBuYW1lID0gJ2hkLW1jcCcsIHN0b3AgcmVhc29uID0gc2lnbmFsIFNJR0lMTDogaWxs ZWdhbCB0cmFwDQo+Pj4gICAgIGZyYW1lICMwOiAweDAwMDAwMDAwNDAzMzQyZTgNCj4+PiAt PiAgMHg0MDMzNDJlODogLmxvbmcgIDB4MGVlMGUwMDAgICAgICAgICAgICAgICAgOyB1bmtu b3duIG9wY29kZQ0KPj4+ICAgICAweDQwMzM0MmVjOiByZXQNCj4+PiAgICAgMHg0MDMzNDJm MDogc3RwICAgIHgyOCwgeDE5LCBbc3AsICMtMHgyMF0hDQo+Pj4gICAgIDB4NDAzMzQyZjQ6 IHN0cCAgICB4MjksIHgzMCwgW3NwLCAjMHgxMF0NCj4+PiAobGxkYikgYnQNCj4+PiAqIHRo cmVhZCAjMSwgbmFtZSA9ICdoZC1tY3AnLCBzdG9wIHJlYXNvbiA9IHNpZ25hbCBTSUdJTEw6 IGlsbGVnYWwgdHJhcA0KPj4+ICAgKiBmcmFtZSAjMDogMHgwMDAwMDAwMDQwMzM0MmU4DQo+ Pj4gICAgIGZyYW1lICMxOiAweDAwMDAwMDAwNDAwODJhZDgNCj4+PiAgICAgZnJhbWUgIzI6 IDB4MDAwMDAwMDA0MDA4MWFiNA0KPj4+IChsbGRiKQ0KPj4+DQo+IFRoYXQgaXMgcHJldHR5 IHN0YW5kYXJkIGJlaGF2aW9yLg0KPiAweDBlZTBlMDAwIG9wY29kZSBpcyBvcHRpb25hbCBw bXVsbCBjcnlwdG8gZXh0ZW5zaW9uIGluc3RydWN0aW9uIGFuZA0KPiBPcGVuU1NMIHRlc3Rz IHRoZSBhdmFpbGFiaWxpdHkgb2YgdGhlc2Ugb3B0aW9uYWwgaW5zdHJ1Y3Rpb25zIGluIHRo aXMgd2F5Lg0KPiBJdCBoYXZlIFNJR0lMTCBoYW5kbGVyIGluc3RhbGxlZCBhbmQgaWYgYSBz aWduYWwgaXMgaGl0LCBpdCBtZWFucyB0aGF0DQo+IHRoZXNlIGV4dGVuc2lvbnMgYXJlIG5v dCBhdmFpbGFibGUuDQo+IFNpbXBseSBoaXQgJ2MnIGFuZCBpZ25vcmUgaXQuLi4NCj4gTWlj aGFsDQo+DQoNCkFoYS7CoCBHb3QgaXQuDQoNCkhvd2V2ZXIsIHRoaXMgcmVtYWlucyBhIHBy b2JsZW0gYW5kIGlzIGxpbmtlZCwgSSBzdXNwZWN0LCB0byB0aGUgYWJvdmUNCmJ1ZyByZXBv cnQ6DQoNCnJvb3RAcnBpMzovZGF0YS9IRC1NQ1AgIyBsbGRiIGhkLW1jcC5mcmVld2FyZQ0K KGxsZGIpIHRhcmdldCBjcmVhdGUgImhkLW1jcC5mcmVld2FyZSINCkN1cnJlbnQgZXhlY3V0 YWJsZSBzZXQgdG8gJ2hkLW1jcC5mcmVld2FyZScgKGFhcmNoNjQpLg0KKGxsZGIpIGIgMTI3 NTINCkJyZWFrcG9pbnQgMTogd2hlcmUgPSBoZC1tY3AuZnJlZXdhcmVgbWFpbiArIDE5MiBh dCBoZC1tY3AuYzoxMjc1MiwNCmFkZHJlc3MgPSAweDAwMDAwMDAwMDAwNDA5NzQNCg0KKDEy NzUxIGlzIHRoZSBmaXJzdCAicmVhbCIgYXNzaWdubWVudCBpbiBtYWluKCk7IHNvIHN0b3Ag cmlnaHQgYWZ0ZXIgdGhlDQpidWZmZXIgaXMgaW5pdGlhbGl6ZWQpDQoNCihsbGRiKSBsIDEy NzUxDQrCoMKgIDEyNzUxwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHgxMF9mYWls X2V2ZW50WzBdID0gMDsNCsKgwqAgMTI3NTLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgc3RhdHVzX2J1ZmZlclswXSA9IDA7DQrCoMKgIDEyNzUzwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHN0YXR1c19tb2QgPSAwOw0KwqDCoCAxMjc1NA0KwqDCoCAxMjc1NcKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBlbWl0X2h0bWw1X3NjcmlwdFswXSA9IDA7 DQrCoMKgIDEyNzU2DQrCoMKgIDEyNzU3wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IGludMKgwqDCoMKgIGR5bmFtaWNfdGltZTsNCsKgwqAgMTI3NTgNCsKgwqAgMTI3NTnCoMKg wqDCoMKgwqDCoCAjaWZkZWbCoCBPUEVOU1NMDQrCoMKgIDEyNzYwwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIFNTTMKgwqDCoMKgICpzc2xfc29ja2V0Ow0KKGxsZGIpIHIgLW4N ClByb2Nlc3MgMTI3NyBsYXVuY2hpbmcNClByb2Nlc3MgMTI3NyBsYXVuY2hlZDogJy9kYXRh L0hELU1DUC9oZC1tY3AuZnJlZXdhcmUnIChhYXJjaDY0KQ0KUHJvY2VzcyAxMjc3IHN0b3Bw ZWQNCiogdGhyZWFkICMxLCBuYW1lID0gJ2hkLW1jcC5mcmVld2FyZScsIHN0b3AgcmVhc29u ID0gYnJlYWtwb2ludCAxLjENCsKgwqDCoCBmcmFtZSAjMDogMHgwMDAwMDAwMDAwMDQwOTc0 IGhkLW1jcC5mcmVld2FyZWBtYWluKGFyZ2M9MiwNCmFyZ3Y9MHgwMDAwZmZmZmZmZmZlYmM4 KSBhdCBoZC1tY3AuYzoxMjc1Mg0KwqDCoCAxMjc0OQ0KwqDCoCAxMjc1MA0KwqDCoCAxMjc1 McKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB4MTBfZmFpbF9ldmVudFswXSA9IDA7 DQotPiAxMjc1MsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzdGF0dXNfYnVmZmVy WzBdID0gMDsNCsKgwqAgMTI3NTPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc3Rh dHVzX21vZCA9IDA7DQrCoMKgIDEyNzU0DQrCoMKgIDEyNzU1wqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIGVtaXRfaHRtbDVfc2NyaXB0WzBdID0gMDsNCihsbGRiKSBwIHgxMF9m YWlsX2V2ZW50DQpTZWdtZW50YXRpb24gZmF1bHQgKGNvcmUgZHVtcGVkKQ0Kcm9vdEBycGkz Oi9kYXRhL0hELU1DUCAjDQoNCg0KLS0gDQpLYXJsIERlbm5pbmdlcg0Ka2FybEBkZW5uaW5n ZXIubmV0IDxtYWlsdG86a2FybEBkZW5uaW5nZXIubmV0Pg0KL1RoZSBNYXJrZXQgVGlja2Vy Lw0KL1tTL01JTUUgZW5jcnlwdGVkIGVtYWlsIHByZWZlcnJlZF0vDQo= --------------ms030008080208080408050600 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 DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTEzMTYzMjU4 WjBPBgkqhkiG9w0BCQQxQgRAtsmb5033aHCmqPz0hNQoYTn3iVMlIn/BhESTlsG3mlOjg6sK uCE8D3lxCYs9aTgn3fDp/D5DmQMh4eG9sNyl1DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBvFsX2DphTEMC/nXZ2CGRtQDunMm2cY5VuPHSlwPlSMAcyzwWhtf6kluQ45UciK/AG jj4LPA/JLvOCRR9UIfJxokY5A4bQTu3G4xBFvYazzz7UD3p9hpYzZxKTN+hfRVcrSD45clwL tsrGHnWQulCYJb53LUuzFFcgqIpN6ipi14bzjpXAJ5smGuf0NzJ0SOoiCJYyC4+NKgDFmVrZ D8zMntnp6GE9X1W3QAlZUY7HYstHAmQ0rs3Thzs1lOvn6Ds6v60CeQKLG5Nr3CG/gMzvGMIB iOIU++7iDwgkGaF0haQxewAsiObjqw2N5ueaUgxAw2j58DbSixKnIfMEUWgRbFQlVVpGONKF fL/J2ma3mu6xWzwRYyHsyM4wv2ZvcjA1yxaDvwueYSCasZmqdhAj3+wst4Xk9RUPxXLa8zLY DS8dNyInmMYZLqlSV0iTlbXme2fO7eRX73srf0McUHaCI4ebNdp/yuDF330ZSXQAlRGbnQtp QCAjUqLqjB9CsperzQhD7eOEEZFUnwty7ZPkMB32Zgz+SCdv2vtUxf3cP9cwTHEzXeG/2Lz9 TxuKcT8zakYbegCMgWGkgJ/ict3wNpQoMbcJYoZXEoDrnlNGYxrDKvYzSuXihHEqnfUJduJU xYWNVl3TtmCx/v/qnB7OM9QYn5RPaxJXHv5sHC7yrgAAAAAAAA== --------------ms030008080208080408050600-- From owner-freebsd-arm@freebsd.org Mon Nov 13 16:50:13 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 A76D3DBEF18 for ; Mon, 13 Nov 2017 16:50:13 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36E8774981 for ; Mon, 13 Nov 2017 16:50:13 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id t139so16630903wmt.1 for ; Mon, 13 Nov 2017 08:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PMx7M1CVtxMreQMuJOr7A1X8IYxcVLIBSoIo5wuDM/E=; b=oXMxXlcQAJE448xTxymVxoLLw5vdlzoMyGHFJX+rVCOlR5LWQqEernj0Tpo2aFJsvn ZrltnwltWb/hAtzLYMda3GsGNQgOVY2oLBCcj+BntcJW3oGg5Hl0wt1Zb3vfZOL6uaej HjUmnHrj2poWjGflMNfHv71/G1VSBVvL/Ylk3MLwotOvG3KtB+zxCILi5mW0PYlAr094 TFXXlV7mShpOpxT9fd0sYUqYQUWVZLIXbA/ZcAdHO43HQosKjG5ew4rNCEW5fRecdu48 k5cirfFVZAx3Em9I6Jj+LxlHXVMNFkFptu5bSkT+TOW/LodAfYcMa1OZKxQrHLfxRaVh ymVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PMx7M1CVtxMreQMuJOr7A1X8IYxcVLIBSoIo5wuDM/E=; b=kVBwzNVyfHLnop6PEFA896wcmzaQcuGtEdnKvPPfmgjlyY78kn0oDED49jwzGd8Wja OKBs7d8Dkuy+guSAeRXuPyENpBF7uDZ68Yvgso83LptZ0j/cCSWVt4ZWPLw07Fgi+SAh 2E04xFkCKw9qfV40+v46arNVE0gmCfB8lJ6L0t8DwOlWCR+InrL67nfbid65/oB1SvCu Q6fd2VjMoNRQiEkmMYCqvj0OKJyXOgKTzsKxiPCb/3am6GJLkC+EknshGmRoMUuUhbyC g3dhMDGWWAD/LFejdy+rVsjTX9YSe+hvH7gJavOolUmXznZdmtffTc0H1pNQLEAdidym OcZw== X-Gm-Message-State: AJaThX6pFSyl9Kj0MGssCpWewJuxEhnFDXutDxJGRovcYk2qjZ1aqmRa hu7vhAIikkBcLNhQwrAUY9MvQmd0 X-Google-Smtp-Source: AGs4zMbGSyGAf/ZVGaPcI45WWmyV8T3DC/1wtB0S4J3zu1TFojF5GuQOEqsDcxK83WU1dFoNAKbTug== X-Received: by 10.80.136.165 with SMTP id d34mr13648901edd.296.1510591811242; Mon, 13 Nov 2017 08:50:11 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id k5sm11966851edc.61.2017.11.13.08.50.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 08:50:10 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: meloun.michal@gmail.com Subject: Re: Very bizarre behavior ARM64 (Pi3) To: Karl Denninger , freebsd-arm@freebsd.org References: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> <9e053fe6-90af-a96b-970a-cdb07f802cca@denninger.net> Message-ID: <8127c8f1-5250-aacf-c374-a852cfaf9f96@gmail.com> Date: Mon, 13 Nov 2017 17:50:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <9e053fe6-90af-a96b-970a-cdb07f802cca@denninger.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 16:50:13 -0000 On 13.11.2017 17:32, Karl Denninger wrote: > On 11/13/2017 10:26, Michal Meloun wrote: >> >> On 13.11.2017 16:54, Karl Denninger wrote: >>> On 11/12/2017 12:02, Karl Denninger wrote: >>>> I managed to get around the Crochet blow-up I reported the other day >>>> with another svn update, and now can Crochet myself a running image for >>>> the Pi3 which boots and (at least at first blush) works. >>>> >>>> But I have code that has been running on the Pi3 (and also on the Pi2, >>>> along with other architectures) for quite some time that no longer runs >>>> when compiled on that newly-built OS. It compiles without warnings or >>>> errors but blows up immediately when executed. >>>> >>>> I just tried to roll that build forward to the newly-built (FreeBSD >>>> 12.0-CURRENT #0 r325681M: Fri Nov 10 19:31:28 CST 2017) -HEAD and am >>>> getting really bizarre core dumps, including (if compiled using OpenSSL >>>> libraries) a crash on initialization claiming unknown opcodes in the >>>> compiled binary. >>>> >>>> root@rpi3:/data/HD-MCP # lldb hd-mcp >>>> (lldb) target create "hd-mcp" >>>> Current executable set to 'hd-mcp' (aarch64). >>>> (lldb) run -n >>>> Process 1101 launching >>>> Process 1101 launched: '/data/HD-MCP/hd-mcp' (aarch64) >>>> Process 1101 stopped >>>> * thread #1, name = 'hd-mcp', stop reason = signal SIGILL: illegal trap >>>> frame #0: 0x00000000403342e8 >>>> -> 0x403342e8: .long 0x0ee0e000 ; unknown opcode >>>> 0x403342ec: ret >>>> 0x403342f0: stp x28, x19, [sp, #-0x20]! >>>> 0x403342f4: stp x29, x30, [sp, #0x10] >>>> (lldb) bt >>>> * thread #1, name = 'hd-mcp', stop reason = signal SIGILL: illegal trap >>>> * frame #0: 0x00000000403342e8 >>>> frame #1: 0x0000000040082ad8 >>>> frame #2: 0x0000000040081ab4 >>>> (lldb) >>>> >> That is pretty standard behavior. >> 0x0ee0e000 opcode is optional pmull crypto extension instruction and >> OpenSSL tests the availability of these optional instructions in this way. >> It have SIGILL handler installed and if a signal is hit, it means that >> these extensions are not available. >> Simply hit 'c' and ignore it... >> Michal >> > > Aha.  Got it. > > However, this remains a problem and is linked, I suspect, to the above > bug report: > > root@rpi3:/data/HD-MCP # lldb hd-mcp.freeware > (lldb) target create "hd-mcp.freeware" > Current executable set to 'hd-mcp.freeware' (aarch64). > (lldb) b 12752 > Breakpoint 1: where = hd-mcp.freeware`main + 192 at hd-mcp.c:12752, > address = 0x0000000000040974 > > (12751 is the first "real" assignment in main(); so stop right after the > buffer is initialized) > > (lldb) l 12751 >    12751                x10_fail_event[0] = 0; >    12752                status_buffer[0] = 0; >    12753                status_mod = 0; >    12754 >    12755                emit_html5_script[0] = 0; >    12756 >    12757                int     dynamic_time; >    12758 >    12759        #ifdef  OPENSSL >    12760                SSL     *ssl_socket; > (lldb) r -n > Process 1277 launching > Process 1277 launched: '/data/HD-MCP/hd-mcp.freeware' (aarch64) > Process 1277 stopped > * thread #1, name = 'hd-mcp.freeware', stop reason = breakpoint 1.1 >     frame #0: 0x0000000000040974 hd-mcp.freeware`main(argc=2, > argv=0x0000ffffffffebc8) at hd-mcp.c:12752 >    12749 >    12750 >    12751                x10_fail_event[0] = 0; > -> 12752                status_buffer[0] = 0; >    12753                status_mod = 0; >    12754 >    12755                emit_html5_script[0] = 0; > (lldb) p x10_fail_event > Segmentation fault (core dumped) > root@rpi3:/data/HD-MCP # Well, lldb is not a much stable. Can you try gdb (8.0.1, from ports)? Michal From owner-freebsd-arm@freebsd.org Mon Nov 13 16:55: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 E00ACDBF194 for ; Mon, 13 Nov 2017 16:55:04 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id A52CF74DEB for ; Mon, 13 Nov 2017 16:55:04 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id BB98227334 for ; Mon, 13 Nov 2017 11:54:34 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id E64A83A4B9E for ; Mon, 13 Nov 2017 10:54:32 -0600 (CST) Subject: Re: Very bizarre behavior ARM64 (Pi3) To: freebsd-arm@freebsd.org References: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> <9e053fe6-90af-a96b-970a-cdb07f802cca@denninger.net> <8127c8f1-5250-aacf-c374-a852cfaf9f96@gmail.com> From: Karl Denninger Message-ID: <761aadac-86df-da47-c9d9-ab249748a077@denninger.net> Date: Mon, 13 Nov 2017 10:54:31 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <8127c8f1-5250-aacf-c374-a852cfaf9f96@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060305060906040202040503" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 16:55:05 -0000 This is a cryptographically signed message in MIME format. --------------ms060305060906040202040503 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/13/2017 10:50, Michal Meloun wrote: > > On 13.11.2017 17:32, Karl Denninger wrote: >> On 11/13/2017 10:26, Michal Meloun wrote: >>> On 13.11.2017 16:54, Karl Denninger wrote: >>>> On 11/12/2017 12:02, Karl Denninger wrote: >>>>> I managed to get around the Crochet blow-up I reported the other da= y >>>>> with another svn update, and now can Crochet myself a running image= for >>>>> the Pi3 which boots and (at least at first blush) works. >>>>> >>>>> But I have code that has been running on the Pi3 (and also on the P= i2, >>>>> along with other architectures) for quite some time that no longer = runs >>>>> when compiled on that newly-built OS. It compiles without warnings= or >>>>> errors but blows up immediately when executed. >>>>> >>>>> I just tried to roll that build forward to the newly-built (FreeBSD= >>>>> 12.0-CURRENT #0 r325681M: Fri Nov 10 19:31:28 CST 2017) -HEAD and = am >>>>> getting really bizarre core dumps, including (if compiled using Ope= nSSL >>>>> libraries) a crash on initialization claiming unknown opcodes in th= e >>>>> compiled binary. >>>>> >>>>> root@rpi3:/data/HD-MCP # lldb hd-mcp >>>>> (lldb) target create "hd-mcp" >>>>> Current executable set to 'hd-mcp' (aarch64). >>>>> (lldb) run -n >>>>> Process 1101 launching >>>>> Process 1101 launched: '/data/HD-MCP/hd-mcp' (aarch64) >>>>> Process 1101 stopped >>>>> * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: ille= gal trap >>>>> frame #0: 0x00000000403342e8 >>>>> -> 0x403342e8: .long 0x0ee0e000 ; unknown opcode >>>>> 0x403342ec: ret >>>>> 0x403342f0: stp x28, x19, [sp, #-0x20]! >>>>> 0x403342f4: stp x29, x30, [sp, #0x10] >>>>> (lldb) bt >>>>> * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: ille= gal trap >>>>> * frame #0: 0x00000000403342e8 >>>>> frame #1: 0x0000000040082ad8 >>>>> frame #2: 0x0000000040081ab4 >>>>> (lldb) >>>>> >>> That is pretty standard behavior. >>> 0x0ee0e000 opcode is optional pmull crypto extension instruction and >>> OpenSSL tests the availability of these optional instructions in this= way. >>> It have SIGILL handler installed and if a signal is hit, it means tha= t >>> these extensions are not available. >>> Simply hit 'c' and ignore it... >>> Michal >>> >> Aha.=C2=A0 Got it. >> >> However, this remains a problem and is linked, I suspect, to the above= >> bug report: >> >> root@rpi3:/data/HD-MCP # lldb hd-mcp.freeware >> (lldb) target create "hd-mcp.freeware" >> Current executable set to 'hd-mcp.freeware' (aarch64). >> (lldb) b 12752 >> Breakpoint 1: where =3D hd-mcp.freeware`main + 192 at hd-mcp.c:12752, >> address =3D 0x0000000000040974 >> >> (12751 is the first "real" assignment in main(); so stop right after t= he >> buffer is initialized) >> >> (lldb) l 12751 >> =C2=A0=C2=A0 12751=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x10_fail_event[0] =3D 0; >> =C2=A0=C2=A0 12752=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status_buffer[0] =3D 0; >> =C2=A0=C2=A0 12753=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status_mod =3D 0; >> =C2=A0=C2=A0 12754 >> =C2=A0=C2=A0 12755=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 emit_html5_script[0] =3D 0; >> =C2=A0=C2=A0 12756 >> =C2=A0=C2=A0 12757=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int=C2=A0=C2=A0=C2=A0=C2=A0 dynamic_= time; >> =C2=A0=C2=A0 12758 >> =C2=A0=C2=A0 12759=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #ifdef=C2= =A0 OPENSSL >> =C2=A0=C2=A0 12760=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SSL=C2=A0=C2=A0=C2=A0=C2=A0 *ssl_soc= ket; >> (lldb) r -n >> Process 1277 launching >> Process 1277 launched: '/data/HD-MCP/hd-mcp.freeware' (aarch64) >> Process 1277 stopped >> * thread #1, name =3D 'hd-mcp.freeware', stop reason =3D breakpoint 1.= 1 >> =C2=A0=C2=A0=C2=A0 frame #0: 0x0000000000040974 hd-mcp.freeware`main(a= rgc=3D2, >> argv=3D0x0000ffffffffebc8) at hd-mcp.c:12752 >> =C2=A0=C2=A0 12749 >> =C2=A0=C2=A0 12750 >> =C2=A0=C2=A0 12751=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x10_fail_event[0] =3D 0; >> -> 12752=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 status_buffer[0] =3D 0; >> =C2=A0=C2=A0 12753=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status_mod =3D 0; >> =C2=A0=C2=A0 12754 >> =C2=A0=C2=A0 12755=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 emit_html5_script[0] =3D 0; >> (lldb) p x10_fail_event >> Segmentation fault (core dumped) >> root@rpi3:/data/HD-MCP # > Well, lldb is not a much stable. Can you try gdb (8.0.1, from ports)? > Michal > I didn't think gdb worked on arm64 (at all)... has that recently been corrected? If it has been I can certainly give it a shot but it may take a while since there's no package set available, I don't believe, for arm64 and self-hosting on a machine that runs off SD card is "somewhat" problematic..... :-) gdb is in the 11-STABLE "stock" crossbuild for the RPI2 but is missing from the -HEAD build for the RPI3 thus more-or-less "forcing" use of lldb, or at least that was my understanding. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060305060906040202040503 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 DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTEzMTY1NDMx WjBPBgkqhkiG9w0BCQQxQgRAsxC+pIoxGajYCLsmpujzuXZ+e9KTYT0wxzViiS1wrN/edK6N u/lRk1J/Ft9CdJvcGzVQb2OgnITFP8sqssEMKjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBceie3VpLCol7shf9BUDBZ+0VQ1bsJZ7Fur/hXbghREj7Emi/uUs3mz9JKJRCJ+QPj ATR836oQgXbodRjYYie6Z1ODqSRXMAqu+sslHCa3Ue4pjrohjomShTW0BBYe5PA6lr9WQ72G ukI3uPJWV0AnbQy0Q73os3XYitPg7YelKT/J6fEx6D8Qn83QOIrhr+ihg30zPPLNMXGkyWen FKR+7/JJc/kifnikI82A3xALrzpNEY6DrGz4AUL6J6tp+J9ewFtm3S/x0M2Z0hO5EtldypV5 GwzdkX2fibv2kvFovI1uq3f1zFvKaXDpgnkUUWRbb1w8RZpAHQFMP36+7ALhTr4u2i7067o/ ScMvqxeMmhn7skeHRY9HwYPXFPyVAQD5M/kspK5bgooU0KoYO/aocubR///sAUYHsjklX0Xf e5v1yZsGfrmoqR1G0AeuhtnOwldATEPq2kl3ow1aTr+wBfwE20hLo2gKDh58UO9xKXKIYxFA KZVcv0ZkoA01U/1jVgwH5OE3hlY9hgjQIS/040pDr12Npg4RNlfZ+ywmcVwPzixUHrom+hBs bG4LCKvoWDfvYEza7hqchjcxo/16y6vBH+mhdRU2TQ7f9NmidJzKpWqaDuU3EHj7fbRn+gwd 0zWPgOS/Ffj4IMaM68YUjoH+Rlqe8+9hmP8qfE0hFgAAAAAAAA== --------------ms060305060906040202040503-- From owner-freebsd-arm@freebsd.org Mon Nov 13 17:01:26 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 ECDA6DBF4CC for ; Mon, 13 Nov 2017 17:01:26 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A0C9E75240; Mon, 13 Nov 2017 17:01:26 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3ybH3H5Vfzzs48 Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3ybH3H5Vfzzs48; Mon, 13 Nov 2017 18:01:15 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id vADH1DIn003525 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 13 Nov 2017 18:01:14 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time To: freebsd-arm@FreeBSD.org References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> From: Henri Hennebert Cc: freebsd.asc@strcmp.org, ian@freebsd.org, markmi@dsl-only.net Message-ID: <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> Date: Mon, 13 Nov 2017 18:01:13 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4af740148ca.47a474e3@mail.schwarzes.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 17:01:27 -0000 On 11/08/2017 22:03, Andreas Schwarz wrote: > On 08.11.17, Henri Hennebert wrote: > >> I upgrade to r324743 and ntpd can't keep time. Maybe of importance, I >> was upgrading the ports after this switch to r324743. Moreover the >> problem with pf occurs really frequently (see >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126) > > I'm running a PINE A64 2G without any problems. > > dump@pinelot:~ $ uname -a > FreeBSD pinelot.schwarzes.net 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r325464: Mon Nov 6 17:44:44 CET 2017 root@pinelot.schwarzes.net:/usr/obj/usr/src/arm64.aarch64/sys/PINE64-ASC arm64 > > > dump@pinelot:~ $ ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.001 > +25000-014.cloud 131.188.3.221 2 u 58 64 377 16.366 5.450 6.000 > *epsilon.h6g-ser 192.53.103.103 2 u 50 64 377 14.943 5.812 5.511 > -y.ns.gin.ntt.ne 249.224.99.213 2 u 55 64 377 11.358 6.847 5.514 > +static.132.14.7 131.188.3.221 2 u 54 64 377 16.240 6.074 5.599 > 1b.ncomputers.o 129.187.254.32 2 u 58 64 37 19.479 -0.972 0.152 > > > What time sources are you using in you /etc/ntp.conf? When looking to your initial > mail, it seems that one of the stratum 2 sources has a problem. > > Can you add the default freebsd pool (ntpd supporting pools now) for a test? > > pool 0.freebsd.pool.ntp.org iburst I upgrade to r324563 and I use this pool and monitor ntpd with 10 minutes interval: [root@norquay log]# less ntpmonitor.log remote refid st t when poll reach delay offset jitter ============================================================================== 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 -webhost2.mitht. 193.67.79.202 2 u 287 1024 77 59.013 1.473 1.112 +ns2.telecom.lt 212.59.3.3 2 u 737 1024 37 43.029 0.513 0.988 -ntp.bserved.nl 193.67.79.202 2 u 440 1024 17 17.392 0.224 1.103 *178.32.44.208 ( 193.190.230.65 2 u 839 1024 37 14.399 0.527 0.490 +stratum2-1.NTP. 129.70.130.71 2 u 366 1024 37 28.377 1.706 0.361 -linode.ibendit. 199.102.46.77 2 u 307 1024 37 129.945 0.307 0.584 #ntp.kennisdelen 193.190.230.66 2 u 98 1024 37 15.019 0.942 0.777 #193.104.37.238 193.190.230.66 2 u 110 1024 37 14.186 0.730 0.424 remote refid st t when poll reach delay offset jitter ============================================================================== 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 -webhost2.mitht. 193.67.79.202 2 u 888 1024 77 59.013 1.473 1.112 +ns2.telecom.lt 212.59.3.3 2 u 288 1024 77 43.362 1.165 0.669 -ntp.bserved.nl 193.67.79.202 2 u 1041 1024 17 17.392 0.224 1.103 *178.32.44.208 ( 193.190.230.65 2 u 365 1024 77 14.399 0.527 0.520 +stratum2-1.NTP. 129.70.130.71 2 u 966 1024 37 28.377 1.706 0.361 -linode.ibendit. 199.102.46.77 2 u 907 1024 37 129.945 0.307 0.584 #ntp.kennisdelen 193.190.230.66 2 u 699 1024 37 15.019 0.942 0.777 #193.104.37.238 193.190.230.66 2 u 711 1024 37 14.186 0.730 0.424 remote refid st t when poll reach delay offset jitter ============================================================================== 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 -webhost2.mitht. 193.67.79.202 2 u 498 1024 177 58.815 1.451 0.932 +ns2.telecom.lt 212.59.3.3 2 u 979 1024 77 43.362 1.165 0.669 +ntp.bserved.nl 193.67.79.202 2 u 661 1024 37 17.664 0.980 0.379 -178.32.44.208 ( 193.190.230.65 2 u 1056 1024 77 14.399 0.527 0.520 *stratum2-1.NTP. 129.70.130.71 2 u 627 1024 77 28.135 1.998 0.570 -linode.ibendit. 199.102.46.77 2 u 1598 1024 76 129.945 0.307 0.584 #193.104.37.238 193.190.230.66 2 u 349 1024 77 14.977 1.321 0.821 remote refid st t when poll reach delay offset jitter ============================================================================== 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 -webhost2.mitht. 193.67.79.202 2 u 948 1024 177 58.815 1.451 0.932 +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 357913. +ntp.bserved.nl 193.67.79.202 2 u 1111 1024 37 17.664 0.980 0.379 -178.32.44.208 ( 193.190.230.65 2 u 81 1024 177 14.930 1.087 135278. *stratum2-1.NTP. 129.70.130.71 2 u 1077 1024 77 28.135 1.998 0.570 -linode.ibendit. 199.102.46.77 2 u 2048 1024 76 129.945 0.307 0.584 #193.104.37.238 193.190.230.66 2 u 799 1024 77 14.977 1.321 0.821 And after a half hour the clock was 5 minutes in the future. Henri > > > -asc > > From owner-freebsd-arm@freebsd.org Mon Nov 13 17:01:51 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 2AA1CDBF661 for ; Mon, 13 Nov 2017 17:01:51 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A813C752E8 for ; Mon, 13 Nov 2017 17:01:49 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id ba315fa5; Mon, 13 Nov 2017 18:01:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=jS3lBjNX0G2kB974mGUkFKZDak8=; b=ScVmi6rHoXvZDUkP6824yyyksESJ rrfwWHyPwcC8XyFoB0qK2iRDFEWsw7LZ6qRtran6xI0dX0Mkwe9bXmcM7JgOzbSm JSk8Qx2X/2kT/EXtQ5/P2er6oPwMBEeR3O5t9dZapOz12SnIAZhEZY6LiOfqzO8O op8NPibgTgWbSpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=HEzZ3ii7sJy5A/dEsp4sviRR/auFxxr5JFobtt1beKkF7lNoP8uPm3kl tTSqF87UAsgYZpyqMaoyyPf+clD/VxBIqdbqgeegdU3mBgsHWheQxwavfsy0vPys LJIVZ/kw+5f7938lfKAZ+v6tVa571kW2ifZqz4Pi00MzEih+LEg= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 8abb3b39 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 13 Nov 2017 18:01:46 +0100 (CET) Date: Mon, 13 Nov 2017 18:01:46 +0100 From: Emmanuel Vadot To: Karl Denninger Cc: freebsd-arm@freebsd.org Subject: Re: Very bizarre behavior ARM64 (Pi3) Message-Id: <20171113180146.2509566f345ff40a9940b267@bidouilliste.com> In-Reply-To: <761aadac-86df-da47-c9d9-ab249748a077@denninger.net> References: <7caae80e-876f-631c-23a9-957db7d7ddd5@denninger.net> <1aa5d05e-d5cb-4e46-4d94-e9e51339ca0c@denninger.net> <9e053fe6-90af-a96b-970a-cdb07f802cca@denninger.net> <8127c8f1-5250-aacf-c374-a852cfaf9f96@gmail.com> <761aadac-86df-da47-c9d9-ab249748a077@denninger.net> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 17:01:51 -0000 On Mon, 13 Nov 2017 10:54:31 -0600 Karl Denninger wrote: > On 11/13/2017 10:50, Michal Meloun wrote: > > > > On 13.11.2017 17:32, Karl Denninger wrote: > >> On 11/13/2017 10:26, Michal Meloun wrote: > >>> On 13.11.2017 16:54, Karl Denninger wrote: > >>>> On 11/12/2017 12:02, Karl Denninger wrote: > >>>>> I managed to get around the Crochet blow-up I reported the other day > >>>>> with another svn update, and now can Crochet myself a running image= for > >>>>> the Pi3 which boots and (at least at first blush) works. > >>>>> > >>>>> But I have code that has been running on the Pi3 (and also on the P= i2, > >>>>> along with other architectures) for quite some time that no longer = runs > >>>>> when compiled on that newly-built OS. It compiles without warnings= or > >>>>> errors but blows up immediately when executed. > >>>>> > >>>>> I just tried to roll that build forward to the newly-built (FreeBSD > >>>>> 12.0-CURRENT #0 r325681M: Fri Nov 10 19:31:28 CST 2017) -HEAD and = am > >>>>> getting really bizarre core dumps, including (if compiled using Ope= nSSL > >>>>> libraries) a crash on initialization claiming unknown opcodes in the > >>>>> compiled binary. > >>>>> > >>>>> root@rpi3:/data/HD-MCP # lldb hd-mcp > >>>>> (lldb) target create "hd-mcp" > >>>>> Current executable set to 'hd-mcp' (aarch64). > >>>>> (lldb) run -n > >>>>> Process 1101 launching > >>>>> Process 1101 launched: '/data/HD-MCP/hd-mcp' (aarch64) > >>>>> Process 1101 stopped > >>>>> * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: ille= gal trap > >>>>> frame #0: 0x00000000403342e8 > >>>>> -> 0x403342e8: .long 0x0ee0e000 ; unknown opcode > >>>>> 0x403342ec: ret > >>>>> 0x403342f0: stp x28, x19, [sp, #-0x20]! > >>>>> 0x403342f4: stp x29, x30, [sp, #0x10] > >>>>> (lldb) bt > >>>>> * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: ille= gal trap > >>>>> * frame #0: 0x00000000403342e8 > >>>>> frame #1: 0x0000000040082ad8 > >>>>> frame #2: 0x0000000040081ab4 > >>>>> (lldb) > >>>>> > >>> That is pretty standard behavior. > >>> 0x0ee0e000 opcode is optional pmull crypto extension instruction and > >>> OpenSSL tests the availability of these optional instructions in this= way. > >>> It have SIGILL handler installed and if a signal is hit, it means that > >>> these extensions are not available. > >>> Simply hit 'c' and ignore it... > >>> Michal > >>> > >> Aha.=A0 Got it. > >> > >> However, this remains a problem and is linked, I suspect, to the above > >> bug report: > >> > >> root@rpi3:/data/HD-MCP # lldb hd-mcp.freeware > >> (lldb) target create "hd-mcp.freeware" > >> Current executable set to 'hd-mcp.freeware' (aarch64). > >> (lldb) b 12752 > >> Breakpoint 1: where =3D hd-mcp.freeware`main + 192 at hd-mcp.c:12752, > >> address =3D 0x0000000000040974 > >> > >> (12751 is the first "real" assignment in main(); so stop right after t= he > >> buffer is initialized) > >> > >> (lldb) l 12751 > >> =A0=A0 12751=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x10_fail_eve= nt[0] =3D 0; > >> =A0=A0 12752=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 status_buffe= r[0] =3D 0; > >> =A0=A0 12753=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 status_mod = =3D 0; > >> =A0=A0 12754 > >> =A0=A0 12755=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 emit_html5_s= cript[0] =3D 0; > >> =A0=A0 12756 > >> =A0=A0 12757=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 int=A0=A0=A0= =A0 dynamic_time; > >> =A0=A0 12758 > >> =A0=A0 12759=A0=A0=A0=A0=A0=A0=A0 #ifdef=A0 OPENSSL > >> =A0=A0 12760=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SSL=A0=A0=A0= =A0 *ssl_socket; > >> (lldb) r -n > >> Process 1277 launching > >> Process 1277 launched: '/data/HD-MCP/hd-mcp.freeware' (aarch64) > >> Process 1277 stopped > >> * thread #1, name =3D 'hd-mcp.freeware', stop reason =3D breakpoint 1.1 > >> =A0=A0=A0 frame #0: 0x0000000000040974 hd-mcp.freeware`main(argc=3D2, > >> argv=3D0x0000ffffffffebc8) at hd-mcp.c:12752 > >> =A0=A0 12749 > >> =A0=A0 12750 > >> =A0=A0 12751=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x10_fail_eve= nt[0] =3D 0; > >> -> 12752=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 status_buffer[0]= =3D 0; > >> =A0=A0 12753=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 status_mod = =3D 0; > >> =A0=A0 12754 > >> =A0=A0 12755=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 emit_html5_s= cript[0] =3D 0; > >> (lldb) p x10_fail_event > >> Segmentation fault (core dumped) > >> root@rpi3:/data/HD-MCP # > > Well, lldb is not a much stable. Can you try gdb (8.0.1, from ports)? > > Michal > > > I didn't think gdb worked on arm64 (at all)... has that recently been > corrected? jhb@ worked on it recently. > If it has been I can certainly give it a shot but it may take a while > since there's no package set available, I don't believe, for arm64 and > self-hosting on a machine that runs off SD card is "somewhat" > problematic..... :-) There is : http://pkg.freebsd.org/FreeBSD:12:aarch64/latest/ > gdb is in the 11-STABLE "stock" crossbuild for the RPI2 but is missing > from the -HEAD build for the RPI3 thus more-or-less "forcing" use of > lldb, or at least that was my understanding. >=20 > --=20 > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Nov 13 20:30: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 0717ADD4EA0 for ; Mon, 13 Nov 2017 20:30:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-95.reflexion.net [208.70.210.95]) (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 C0CCE7CDE7 for ; Mon, 13 Nov 2017 20:30:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31525 invoked from network); 13 Nov 2017 20:03:29 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Nov 2017 20:03:29 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 13 Nov 2017 15:03:29 -0500 (EST) Received: (qmail 5611 invoked from network); 13 Nov 2017 20:03:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Nov 2017 20:03:29 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E545FEC8F04; Mon, 13 Nov 2017 12:03:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Mark Millard In-Reply-To: <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> Date: Mon, 13 Nov 2017 12:03:28 -0800 Cc: freebsd-arm@FreeBSD.org, freebsd.asc@strcmp.org, ian@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> To: Henri Hennebert X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 20:30:17 -0000 On 2017-Nov-13, at 9:01 AM, Henri Hennebert wrote: > On 11/08/2017 22:03, Andreas Schwarz wrote: >> On 08.11.17, Henri Hennebert wrote: >>> I upgrade to r324743 and ntpd can't keep time. Maybe of importance, = I >>> was upgrading the ports after this switch to r324743. Moreover the >>> problem with pf occurs really frequently (see >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222126) >> I'm running a PINE A64 2G without any problems. >> dump@pinelot:~ $ uname -a >> FreeBSD pinelot.schwarzes.net 12.0-CURRENT FreeBSD 12.0-CURRENT #0 = r325464: Mon Nov 6 17:44:44 CET 2017 = root@pinelot.schwarzes.net:/usr/obj/usr/src/arm64.aarch64/sys/PINE64-ASC = arm64 >> dump@pinelot:~ $ ntpq -p >> remote refid st t when poll reach delay = offset jitter >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 = 0.000 0.001 >> +25000-014.cloud 131.188.3.221 2 u 58 64 377 16.366 = 5.450 6.000 >> *epsilon.h6g-ser 192.53.103.103 2 u 50 64 377 14.943 = 5.812 5.511 >> -y.ns.gin.ntt.ne 249.224.99.213 2 u 55 64 377 11.358 = 6.847 5.514 >> +static.132.14.7 131.188.3.221 2 u 54 64 377 16.240 = 6.074 5.599 >> 1b.ncomputers.o 129.187.254.32 2 u 58 64 37 19.479 = -0.972 0.152 >> What time sources are you using in you /etc/ntp.conf? When looking to = your initial >> mail, it seems that one of the stratum 2 sources has a problem. >> Can you add the default freebsd pool (ntpd supporting pools now) for = a test? >> pool 0.freebsd.pool.ntp.org iburst >=20 > I upgrade to r324563 and I use this pool and monitor ntpd with 10 = minutes interval: >=20 > [root@norquay log]# less ntpmonitor.log > remote refid st t when poll reach delay offset = jitter > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 = 0.000 > -webhost2.mitht. 193.67.79.202 2 u 287 1024 77 59.013 1.473 = 1.112 > +ns2.telecom.lt 212.59.3.3 2 u 737 1024 37 43.029 0.513 = 0.988 > -ntp.bserved.nl 193.67.79.202 2 u 440 1024 17 17.392 0.224 = 1.103 > *178.32.44.208 ( 193.190.230.65 2 u 839 1024 37 14.399 0.527 = 0.490 > +stratum2-1.NTP. 129.70.130.71 2 u 366 1024 37 28.377 1.706 = 0.361 > -linode.ibendit. 199.102.46.77 2 u 307 1024 37 129.945 0.307 = 0.584 > #ntp.kennisdelen 193.190.230.66 2 u 98 1024 37 15.019 0.942 = 0.777 > #193.104.37.238 193.190.230.66 2 u 110 1024 37 14.186 0.730 = 0.424 > remote refid st t when poll reach delay offset = jitter > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 = 0.000 > -webhost2.mitht. 193.67.79.202 2 u 888 1024 77 59.013 1.473 = 1.112 > +ns2.telecom.lt 212.59.3.3 2 u 288 1024 77 43.362 1.165 = 0.669 > -ntp.bserved.nl 193.67.79.202 2 u 1041 1024 17 17.392 0.224 = 1.103 > *178.32.44.208 ( 193.190.230.65 2 u 365 1024 77 14.399 0.527 = 0.520 > +stratum2-1.NTP. 129.70.130.71 2 u 966 1024 37 28.377 1.706 = 0.361 > -linode.ibendit. 199.102.46.77 2 u 907 1024 37 129.945 0.307 = 0.584 > #ntp.kennisdelen 193.190.230.66 2 u 699 1024 37 15.019 0.942 = 0.777 > #193.104.37.238 193.190.230.66 2 u 711 1024 37 14.186 0.730 = 0.424 > remote refid st t when poll reach delay offset = jitter > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 = 0.000 > -webhost2.mitht. 193.67.79.202 2 u 498 1024 177 58.815 1.451 = 0.932 > +ns2.telecom.lt 212.59.3.3 2 u 979 1024 77 43.362 1.165 = 0.669 > +ntp.bserved.nl 193.67.79.202 2 u 661 1024 37 17.664 0.980 = 0.379 > -178.32.44.208 ( 193.190.230.65 2 u 1056 1024 77 14.399 0.527 = 0.520 > *stratum2-1.NTP. 129.70.130.71 2 u 627 1024 77 28.135 1.998 = 0.570 > -linode.ibendit. 199.102.46.77 2 u 1598 1024 76 129.945 0.307 = 0.584 > #193.104.37.238 193.190.230.66 2 u 349 1024 77 14.977 1.321 = 0.821 > remote refid st t when poll reach delay offset = jitter > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 = 0.000 > -webhost2.mitht. 193.67.79.202 2 u 948 1024 177 58.815 1.451 = 0.932 > +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 = 357913. > +ntp.bserved.nl 193.67.79.202 2 u 1111 1024 37 17.664 0.980 = 0.379 > -178.32.44.208 ( 193.190.230.65 2 u 81 1024 177 14.930 1.087 = 135278. > *stratum2-1.NTP. 129.70.130.71 2 u 1077 1024 77 28.135 1.998 = 0.570 > -linode.ibendit. 199.102.46.77 2 u 2048 1024 76 129.945 0.307 = 0.584 > #193.104.37.238 193.190.230.66 2 u 799 1024 77 14.977 1.321 = 0.821 >=20 > And after a half hour the clock was 5 minutes in the future. Did you notice the huge offset and jitter in your listing: (last 2 numerals in the line below) +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 = 357913. And there is another huge jitter: (last numeral) -178.32.44.208 ( 193.190.230.65 2 u 81 1024 177 14.930 1.087 = 135278. (That last suggests a previous huge offset that still shows up as history via the jitter being large.) man ntpq indicates: offset offset of server relative to this host Jitter is not described in detail but I expect that it is based on the history of variations in offset. What is said is: The jitter and wander statistics are exponentially-weighted RMS = averages. The system jitter is defined in the NTPv4 specification; the clock = jitter statistic is computed by the clock discipline module. So it looks like you are getting bad times from at least 2 servers. Note that the other servers seem fine as far as your e-mailed material goes. It looks to me like you need to avoid those 2 severs, substituting some others or some such. If some communication channel(s) involved are corrupting data then simply switching servers might not avoid the issue? I finally got a hold of the rpi3 and updated it to -r325700 from back a -r320123. it has been up 9 hr 40 min and date is still showing the correct time, no evidence of huge offsets or huge jitter. The Pine64+ 2GB is also at -r325700 now and has been up for 2 days. It also is working fine. Again no evidence of huge offsets or huge jitter. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Nov 13 20:45: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 2A740DD53F4 for ; Mon, 13 Nov 2017 20:45:56 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) (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 E957B7D68F for ; Mon, 13 Nov 2017 20:45:55 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-io0-f175.google.com with SMTP id u42so4057440ioi.9 for ; Mon, 13 Nov 2017 12:45:55 -0800 (PST) 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=SZfz4QHR19rdVp8bKHMeUdKuByIjlDuKznqyPMuR9Yw=; b=fiQ16iaRXUCfE4h+70FLajfV+opPLXZXYhjApVjN6ezm3XE9A6p5SzFCgiRfW0ALDs L5QmfcKSl60TNA178looW+G1KKO/labxQJOkzKv3TACweBDETuB2ExSjdL4tPYPMvs7D bneIw46aP0TW5tNQ2f+s/LSGNt0az+irMWWIIUQJ5UThUZvT3RdmptDYpxhhEoCFwg1y yXUICiDuxj8ivu+F+qUc1hANOFEhDLcgyXuZQBpjK+Ivxrar27AQcGo+fKRrNCXtGCah XvSbnulSqtwUBhB6Tmn8Wk57buQl/taDgZtkG93tkdi0RI1qxcgIYfB5mHKUVChMwwjC 3aFw== X-Gm-Message-State: AJaThX4UYDyMtUewFpzbkEovglBbEkxkRNdRNYHpIg2B1A1Ul4cTgnVT 5g8b+Pp58cDiY1zQS3tIBkJ8n+k9 X-Google-Smtp-Source: AGs4zMbdn6QNIQ3/zN6eK82DDXTwn8b9ZpTVLVDAIzXbQCzbZsARNKD1jZufozlQXMOiyEneWju6Qw== X-Received: by 10.107.33.18 with SMTP id h18mr11141801ioh.167.1510605948681; Mon, 13 Nov 2017 12:45:48 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id d1sm3019490ioc.61.2017.11.13.12.45.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 12:45:48 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id 71so6460139ior.7 for ; Mon, 13 Nov 2017 12:45:48 -0800 (PST) X-Received: by 10.107.83.2 with SMTP id h2mr11902269iob.239.1510605948032; Mon, 13 Nov 2017 12:45:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.23.129 with HTTP; Mon, 13 Nov 2017 12:45:27 -0800 (PST) In-Reply-To: <6CFB609E-DE25-492D-96AC-782010FE6EF9@dsl-only.net> References: <8ECC1284-8843-420E-8496-9F33DF979A02@dsl-only.net> <6CFB609E-DE25-492D-96AC-782010FE6EF9@dsl-only.net> From: Kyle Evans Date: Mon, 13 Nov 2017 14:45:27 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: head -r325700: BPI-M3 u-boot vs. FreeBSD kernel/loader and finding sinovoip-bpi-m3.dtb: fails [ -r324743 head worked] To: Mark Millard Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 20:45:56 -0000 On Sun, Nov 12, 2017 at 10:36 AM, Mark Millard wrote: > [ ... snip ... ] > > > > Either way, this alone caused a recent -HEAD to boot. This is what I > currently boot on my bpi-m3: https://github.com/kevans91/ > freebsd/tree/clkng > > I'm not sure that it would for -r325700+ . What broke > may have happened between your test and my test. So, > knowing what you booted with might help narrow the > range if you ended up trying something after -r324743 > --but after the static-images-are-broken issue was > fixed [/sbin/init working again]. > > r325775 should fix it -- /boot/defaults/loader.conf was not the right one, so module_path was not being populated correctly. The correct loader.conf for the time being is HEAD/sys/boot/arm/uboot/loader.conf, for your reference. Thanks, Kyle Evans From owner-freebsd-arm@freebsd.org Mon Nov 13 21:33:53 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 E73ECDD7867 for ; Mon, 13 Nov 2017 21:33:53 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 8AED77F571; Mon, 13 Nov 2017 21:33:53 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4dbc1867.dyn.telefonica.de [77.188.24.103]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vADLXbxN078436; Mon, 13 Nov 2017 22:33:38 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org, ian@freebsd.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Mon, 13 Nov 2017 22:33:37 +0100 (CET) Message-ID: <4afdde9c747.319ba732@mail.schwarzes.net> In-Reply-To: References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Mon, 13 Nov 2017 22:33:38 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 21:33:54 -0000 On 13.11.17, Mark Millard wrote: > On 2017-Nov-13, at 9:01 AM, Henri Hennebert wrote: >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 >> -webhost2.mitht. 193.67.79.202 2 u 948 1024 177 58.815 1.451 0.932 >> +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 357913. >> +ntp.bserved.nl 193.67.79.202 2 u 1111 1024 37 17.664 0.980 0.379 >> -178.32.44.208 ( 193.190.230.65 2 u 81 1024 177 14.930 1.087 135278. >> *stratum2-1.NTP. 129.70.130.71 2 u 1077 1024 77 28.135 1.998 0.570 >> -linode.ibendit. 199.102.46.77 2 u 2048 1024 76 129.945 0.307 0.584 >> #193.104.37.238 193.190.230.66 2 u 799 1024 77 14.977 1.321 0.821 >> >> And after a half hour the clock was 5 minutes in the future. > > Did you notice the huge offset and jitter in your listing: > (last 2 numerals in the line below) > > +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 357913. Yes, this peer causes the problem, the offset jumps between your pollings from ~0 to -350k, all other peers are in range. The jitter was the result of this jump. In your previous emails, other peers had the same problem, so it's probaly not a problem with the peer itself. Maybe a strange network problem, ntp is UDP, do you have a real IP Adress, without NAT/CGN or other packet rewriting? -asc From owner-freebsd-arm@freebsd.org Tue Nov 14 07:06: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 02272D7E49E for ; Tue, 14 Nov 2017 07:06:34 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A941C7296F; Tue, 14 Nov 2017 07:06:32 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver=markmi@dsl-only.net DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3ybdpZ1gb5ztms Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3ybdpZ1gb5ztms; Tue, 14 Nov 2017 08:06:29 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id vAE76RC7008499 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Nov 2017 08:06:27 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time To: Mark Millard Cc: freebsd-arm@FreeBSD.org, freebsd.asc@strcmp.org, ian@freebsd.org References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> From: Henri Hennebert Message-ID: Date: Tue, 14 Nov 2017 08:06:26 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 07:06:34 -0000 On 11/13/2017 21:03, Mark Millard wrote: > > On 2017-Nov-13, at 9:01 AM, Henri Hennebert wrote: > >> On 11/08/2017 22:03, Andreas Schwarz wrote: >>> On 08.11.17, Henri Hennebert wrote: >>>> I upgrade to r324743 and ntpd can't keep time. Maybe of importance, I >>>> was upgrading the ports after this switch to r324743. Moreover the >>>> problem with pf occurs really frequently (see >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126) >>> I'm running a PINE A64 2G without any problems. >>> dump@pinelot:~ $ uname -a >>> FreeBSD pinelot.schwarzes.net 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r325464: Mon Nov 6 17:44:44 CET 2017 root@pinelot.schwarzes.net:/usr/obj/usr/src/arm64.aarch64/sys/PINE64-ASC arm64 >>> dump@pinelot:~ $ ntpq -p >>> remote refid st t when poll reach delay offset jitter >>> ============================================================================== >>> 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.001 >>> +25000-014.cloud 131.188.3.221 2 u 58 64 377 16.366 5.450 6.000 >>> *epsilon.h6g-ser 192.53.103.103 2 u 50 64 377 14.943 5.812 5.511 >>> -y.ns.gin.ntt.ne 249.224.99.213 2 u 55 64 377 11.358 6.847 5.514 >>> +static.132.14.7 131.188.3.221 2 u 54 64 377 16.240 6.074 5.599 >>> 1b.ncomputers.o 129.187.254.32 2 u 58 64 37 19.479 -0.972 0.152 >>> What time sources are you using in you /etc/ntp.conf? When looking to your initial >>> mail, it seems that one of the stratum 2 sources has a problem. >>> Can you add the default freebsd pool (ntpd supporting pools now) for a test? >>> pool 0.freebsd.pool.ntp.org iburst >> >> I upgrade to r324563 and I use this pool and monitor ntpd with 10 minutes interval: >> >> [root@norquay log]# less ntpmonitor.log >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 >> -webhost2.mitht. 193.67.79.202 2 u 287 1024 77 59.013 1.473 1.112 >> +ns2.telecom.lt 212.59.3.3 2 u 737 1024 37 43.029 0.513 0.988 >> -ntp.bserved.nl 193.67.79.202 2 u 440 1024 17 17.392 0.224 1.103 >> *178.32.44.208 ( 193.190.230.65 2 u 839 1024 37 14.399 0.527 0.490 >> +stratum2-1.NTP. 129.70.130.71 2 u 366 1024 37 28.377 1.706 0.361 >> -linode.ibendit. 199.102.46.77 2 u 307 1024 37 129.945 0.307 0.584 >> #ntp.kennisdelen 193.190.230.66 2 u 98 1024 37 15.019 0.942 0.777 >> #193.104.37.238 193.190.230.66 2 u 110 1024 37 14.186 0.730 0.424 >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 >> -webhost2.mitht. 193.67.79.202 2 u 888 1024 77 59.013 1.473 1.112 >> +ns2.telecom.lt 212.59.3.3 2 u 288 1024 77 43.362 1.165 0.669 >> -ntp.bserved.nl 193.67.79.202 2 u 1041 1024 17 17.392 0.224 1.103 >> *178.32.44.208 ( 193.190.230.65 2 u 365 1024 77 14.399 0.527 0.520 >> +stratum2-1.NTP. 129.70.130.71 2 u 966 1024 37 28.377 1.706 0.361 >> -linode.ibendit. 199.102.46.77 2 u 907 1024 37 129.945 0.307 0.584 >> #ntp.kennisdelen 193.190.230.66 2 u 699 1024 37 15.019 0.942 0.777 >> #193.104.37.238 193.190.230.66 2 u 711 1024 37 14.186 0.730 0.424 >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 >> -webhost2.mitht. 193.67.79.202 2 u 498 1024 177 58.815 1.451 0.932 >> +ns2.telecom.lt 212.59.3.3 2 u 979 1024 77 43.362 1.165 0.669 >> +ntp.bserved.nl 193.67.79.202 2 u 661 1024 37 17.664 0.980 0.379 >> -178.32.44.208 ( 193.190.230.65 2 u 1056 1024 77 14.399 0.527 0.520 >> *stratum2-1.NTP. 129.70.130.71 2 u 627 1024 77 28.135 1.998 0.570 >> -linode.ibendit. 199.102.46.77 2 u 1598 1024 76 129.945 0.307 0.584 >> #193.104.37.238 193.190.230.66 2 u 349 1024 77 14.977 1.321 0.821 >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 >> -webhost2.mitht. 193.67.79.202 2 u 948 1024 177 58.815 1.451 0.932 >> +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 357913. >> +ntp.bserved.nl 193.67.79.202 2 u 1111 1024 37 17.664 0.980 0.379 >> -178.32.44.208 ( 193.190.230.65 2 u 81 1024 177 14.930 1.087 135278. >> *stratum2-1.NTP. 129.70.130.71 2 u 1077 1024 77 28.135 1.998 0.570 >> -linode.ibendit. 199.102.46.77 2 u 2048 1024 76 129.945 0.307 0.584 >> #193.104.37.238 193.190.230.66 2 u 799 1024 77 14.977 1.321 0.821 >> >> And after a half hour the clock was 5 minutes in the future. > > Did you notice the huge offset and jitter in your listing: > (last 2 numerals in the line below) > > +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 357913. > > And there is another huge jitter: > (last numeral) > > -178.32.44.208 ( 193.190.230.65 2 u 81 1024 177 14.930 1.087 135278. > > (That last suggests a previous huge offset that still > shows up as history via the jitter being large.) > > man ntpq indicates: > > offset offset of server relative to this host > > Jitter is not described in detail but I expect that > it is based on the history of variations in offset. > What is said is: > > The jitter and wander statistics are exponentially-weighted RMS averages. > The system jitter is defined in the NTPv4 specification; the clock jitter > statistic is computed by the clock discipline module. > > So it looks like you are getting bad times from at > least 2 servers. Note that the other servers seem > fine as far as your e-mailed material goes. I believe that the clock of the Pine64+ is going too fast and that the 2 servers where polled and so show this offset/jitter. In an other occurrence of this problem, if I wait long enough, all servers display huge offset. In a old version of Freebsd12, when dev.cpu.0.freq was accessible, the problem appear when I force the frequency to 1200. In the same network, other computers (amd64) get no problem with this ntpd configuration. > > It looks to me like you need to avoid those 2 severs, > substituting some others or some such. If some > communication channel(s) involved are corrupting data > then simply switching servers might not avoid the > issue? > > I finally got a hold of the rpi3 and updated it to > -r325700 from back a -r320123. it has been up 9 hr > 40 min and date is still showing the correct time, > no evidence of huge offsets or huge jitter. > > The Pine64+ 2GB is also at -r325700 now and has been > up for 2 days. It also is working fine. Again no > evidence of huge offsets or huge jitter. Did you run heavy jobs running on this system? My Pine64+ is managing my connection to internet (mpd5), named, dhcp, my mail (sendmail + cyrus-imap) and dspam with postgres as db. The problem crops up when for example I run a port upgrade. > > === > Mark Millard > markmi at dsl-only.net > > From owner-freebsd-arm@freebsd.org Tue Nov 14 07:10: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 0E02ED7E59D for ; Tue, 14 Nov 2017 07:10:43 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C4C2D72C3B for ; Tue, 14 Nov 2017 07:10:42 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3ybdvP19cJztpt Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3ybdvP19cJztpt for ; Tue, 14 Nov 2017 08:10:40 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id vAE7Adt6008525 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 14 Nov 2017 08:10:40 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time To: freebsd-arm@FreeBSD.org References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4afdde9c747.319ba732@mail.schwarzes.net> From: Henri Hennebert Message-ID: <45c53cf7-14f7-f1ec-038f-48fed7248146@restart.be> Date: Tue, 14 Nov 2017 08:10:39 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4afdde9c747.319ba732@mail.schwarzes.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 07:10:43 -0000 On 11/13/2017 22:33, Andreas Schwarz wrote: > On 13.11.17, Mark Millard wrote: > >> On 2017-Nov-13, at 9:01 AM, Henri Hennebert wrote: > >>> remote refid st t when poll reach delay offset jitter >>> ============================================================================== >>> 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 >>> -webhost2.mitht. 193.67.79.202 2 u 948 1024 177 58.815 1.451 0.932 >>> +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 357913. >>> +ntp.bserved.nl 193.67.79.202 2 u 1111 1024 37 17.664 0.980 0.379 >>> -178.32.44.208 ( 193.190.230.65 2 u 81 1024 177 14.930 1.087 135278. >>> *stratum2-1.NTP. 129.70.130.71 2 u 1077 1024 77 28.135 1.998 0.570 >>> -linode.ibendit. 199.102.46.77 2 u 2048 1024 76 129.945 0.307 0.584 >>> #193.104.37.238 193.190.230.66 2 u 799 1024 77 14.977 1.321 0.821 >>> >>> And after a half hour the clock was 5 minutes in the future. >> >> Did you notice the huge offset and jitter in your listing: >> (last 2 numerals in the line below) >> >> +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 357913. > > Yes, this peer causes the problem, the offset jumps between your pollings from > ~0 to -350k, all other peers are in range. The jitter was the result of this jump. > In your previous emails, other peers had the same problem, so it's probaly not > a problem with the peer itself. Maybe a strange network problem, ntp is UDP, > do you have a real IP Adress, without NAT/CGN or other packet rewriting? > The Pine64+ is directly connected to the internet (mpd5 with a b-box3 in bridge mode). Moreover if I rollback to r320599 all run smoothly for more than 8 days. Henri > -asc > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Tue Nov 14 07:17: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 ADF06D7E786 for ; Tue, 14 Nov 2017 07:17:34 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4935F7314B for ; Tue, 14 Nov 2017 07:17:33 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3ybf3H5qfnztsq Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3ybf3H5qfnztsq for ; Tue, 14 Nov 2017 08:17:31 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id vAE7HUVZ008576 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 14 Nov 2017 08:17:30 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time To: freebsd-arm@freebsd.org References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4afdde9c747.319ba732@mail.schwarzes.net> <45c53cf7-14f7-f1ec-038f-48fed7248146@restart.be> From: Henri Hennebert Message-ID: <4402b802-d3df-0be3-3956-0ee3844d9ce2@restart.be> Date: Tue, 14 Nov 2017 08:17:29 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <45c53cf7-14f7-f1ec-038f-48fed7248146@restart.be> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 07:17:34 -0000 On 11/14/2017 08:10, Henri Hennebert wrote: > On 11/13/2017 22:33, Andreas Schwarz wrote: >> On 13.11.17, Mark Millard wrote: >> >>> On 2017-Nov-13, at 9:01 AM, Henri Hennebert wrote: >> >>>>      remote           refid      st t when poll reach   delay >>>> offset jitter >>>> ============================================================================== >>>> >>>> 0.freebsd.pool. .POOL.          16 p    -   64    0    0.000 >>>> 0.000  0.000 >>>> -webhost2.mitht. 193.67.79.202    2 u  948 1024  177   58.815 >>>> 1.451 0.932 >>>> +ns2.telecom.lt  212.59.3.3       2 u   13 1024  177   43.400 >>>> -357912 357913. >>>> +ntp.bserved.nl  193.67.79.202    2 u 1111 1024   37   17.664 >>>> 0.980 0.379 >>>> -178.32.44.208 ( 193.190.230.65   2 u   81 1024  177   14.930 >>>> 1.087 135278. >>>> *stratum2-1.NTP. 129.70.130.71    2 u 1077 1024   77   28.135 >>>> 1.998 0.570 >>>> -linode.ibendit. 199.102.46.77    2 u 2048 1024   76  129.945 >>>> 0.307 0.584 >>>> #193.104.37.238  193.190.230.66   2 u  799 1024   77   14.977 >>>> 1.321 0.821 >>>> >>>> And after a half hour the clock was 5 minutes in the future. >>> >>> Did you notice the huge offset and jitter in your listing: >>> (last 2 numerals in the line below) >>> >>> +ns2.telecom.lt  212.59.3.3       2 u   13 1024  177   43.400 >>> -357912 357913. >> >> Yes, this peer causes the problem, the offset jumps between your >> pollings from >> ~0 to -350k, all other peers are in range. The jitter was the result >> of this jump. >> In your previous emails, other peers had the same problem, so it's >> probaly not >> a problem with the peer itself. Maybe a strange network problem, ntp >> is UDP, >> do you have a real IP Adress, without NAT/CGN or other packet rewriting? >> > > The Pine64+ is directly connected to the internet (mpd5 with a b-box3 in > bridge mode). Moreover if I rollback to r320599 all run smoothly for > more than 8 days. Maybe of some importance, the root filesystem in on zfs on 2 USB disks through: uhub4: on usbus3 self powered. Henri > >> -asc >> >> _______________________________________________ >> 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 Tue Nov 14 09:45:58 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 CF08ADB970D for ; Tue, 14 Nov 2017 09:45:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-153.reflexion.net [208.70.210.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91E8777624 for ; Tue, 14 Nov 2017 09:45:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5951 invoked from network); 14 Nov 2017 09:39:11 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Nov 2017 09:39:11 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 14 Nov 2017 04:39:11 -0500 (EST) Received: (qmail 12550 invoked from network); 14 Nov 2017 09:39:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Nov 2017 09:39:10 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 12530EC8F04; Tue, 14 Nov 2017 01:39:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Mark Millard In-Reply-To: Date: Tue, 14 Nov 2017 01:39:09 -0800 Cc: freebsd-arm@FreeBSD.org, Andreas Schwarz , ian@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <23D8D3DB-CC10-4A61-924A-D81FF22E0250@dsl-only.net> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> To: Henri Hennebert X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 09:45:58 -0000 On 2017-Nov-13, at 11:06 PM, Henri Hennebert wrote: >> . . . >=20 > I believe that the clock of the Pine64+ is going too fast and that the = 2 servers where polled and so show this offset/jitter. In an other = occurrence of this problem, if I wait long enough, all servers display = huge offset. > In a old version of Freebsd12, when dev.cpu.0.freq was accessible, the = problem appear when I force the frequency to 1200. May be the time is just being damaged on occasion or read-incorrectly sometimes? (Once seen as wrong, the adjustment process will gradually change time towards what it calculates as a supposedly better time.) Good to know that eventually all the servers show a large jitter(?) at the same time. (Jitter reflects more history and so may be a better reference.) > In the same network, other computers (amd64) get no problem with this = ntpd configuration. Good to know. It helps localize the issue. >> It looks to me like you need to avoid those 2 severs, >> substituting some others or some such. If some >> communication channel(s) involved are corrupting data >> then simply switching servers might not avoid the >> issue? >> I finally got a hold of the rpi3 and updated it to >> -r325700 from back a -r320123. it has been up 9 hr >> 40 min and date is still showing the correct time, >> no evidence of huge offsets or huge jitter. >> The Pine64+ 2GB is also at -r325700 now and has been >> up for 2 days. It also is working fine. Again no >> evidence of huge offsets or huge jitter. >=20 > Did you run heavy jobs running on this system? My Pine64+ is managing = my connection to internet (mpd5), named, dhcp, my mail (sendmail + = cyrus-imap) and dspam with postgres as db. The problem crops up when for = example I run a port upgrade. I did a complete, from-scratch -j4 buildworld buildkernel on the Pine64+ 2GB, keeping it busy for a little under 18 hr + 10 min as I remember. top showed that it used some swapspace during this. I included: WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD_BOOTSTRAP=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITH_LLDB=3D WITH_BOOT=3D But it did claim to reuse the system clang instead of building a bootstrap clang compiler. Yet the WITH_LLD_BOOTSTRAP=3D did lead to a bunch of bootstrap activity anyway, so two builds of lld related materials. (The purpose of the build was to see if it would complete or not, extra work made for a better test.) It was on an earlier version than -r325700=20 that I last rebuilt my ports but rebuilding the ports has never caused a time problem either. The ports builds were via poudriere. But I do not use the Pine64+ 2GB for any of those other things that you list as using yours for. I do ssh over ethernet into the Pine64+ to work on it but it is not a service provider at all, just a machine for me to do build experiments with (native and cross builds) and other forms of problem investigations. nfs is present but little/rarely used, and only temporarily in use at that. As a step in potential isolation of what contributes vs. what does not, could you temporarily revert to not using/running the Pine64+ 2GB for the other activities and try the ports builds and/or buildworld buildkernel? Does it still have the problem in something like my simpler context? If time no long jumps, then you could add back an activity and try again until the additions lead to the time problem. That might give a clue what could be interfering with time. Also: I do not know if you have access to a 2nd Pine64 to check for a device-specific problem by switching devices temporarily. Such might also allow keeping your services active while checking the simpler context. If Pine64s had a general time problem, there would be a general problem for everyone else. I think the stage of investigation is still: try to isolate a smaller context sufficient to have the problem but for which an even smaller context is observed to not have the problem. Try to narrow the range of differences between observed-working and observed-failing to gain a clue about what contributes to the problem vs. what does not. FYI: Sitting idle the Pine64+ 2GB here shows in top: sshd: @pts/0 (sshd) sshd: [priv] (sshd) /usr/sbin/sshd /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift sendmail: accepting connections (sendmail) sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) /sbin/devd top -CawPosize login [pam] () su () top -CawPosize /usr/sbin/mountd -r su (sh) -sh (sh) -sh () nfsd: master (nfsd) dhclient: awg0 (dhclient) /usr/sbin/cron -s () dhclient: awg0 [priv] (dhclient) /usr/sbin/syslogd -s /usr/sbin/rpcbind nfsd: server (nfsd) (I do not normally use sendmail for anything. It just sits there while the Pine64+ 2GB is up. nfs is normally idle but is used on occasion.) FYI: The installed ports list (far more is built by poudriere): # pkg info atf-0.21 C, C++ and shell libraries to write = ATF-compliant test programs binutils-2.28,1 GNU binary tools bonnie-2.0.6_1 Performance Test of Filesystem I/O bonnie++-1.97.3 Performance Test of Filesystem I/O ca_root_nss-3.32.1 Root certificate bundle from the Mozilla = Project curl-7.56.1 Command line tool and library for = transferring data with URLs dialog4ports-0.1.6 Console Interface to configure ports dtrace-toolkit-1.0_1 Collection of useful scripts for DTrace dwarfdump-20161124 Tool to display DWARF debugging = information in ELF files expat-2.2.1 XML 1.0 parser written in C freebsd-release-manifests-20171003 FreeBSD release manifests gcc7-7.2.0_2 GNU Compiler Collection 7 gdb-8.0.1_1 GNU GDB of newer version than comes with = the system gettext-runtime-0.19.8.1_1 GNU gettext runtime libraries and = programs git-lite-2.14.3 Distributed source code management tool = (lite package) gmp-6.1.2 Free library for arbitrary precision = arithmetic indexinfo-0.3 Utility to regenerate the GNU info page = index iorate-3.05 General purpose storage I/O benchmarking = tool iozone-3.457 Performance Test of Sequential File I/O kyua-0.13_4,3 Testing framework for infrastructure = software libedit-3.1.20170329_2,1 Command line editor library libidn2-2.0.4 Implementation of IDNA2008 = internationalized domain names libnghttp2-1.27.0 HTTP/2.0 C Library libunistring-0.9.7 Unicode string library lua52-5.2.4 Small, compilable scripting language = providing easy access to C code lutok-0.4_6 Lightweight C++ API for Lua mpc-1.0.3 Library of complex numbers with = arbitrarily high precision mpfr-3.1.6 Library for multiple-precision = floating-point computations patch-2.7.5 GNU patch utility pcre-8.40_1 Perl Compatible Regular Expressions = library perl5-5.24.3 Practical Extraction and Report Language pkg-1.10.1 Package manager portlint-2.17.13 Verifier for FreeBSD port directory portmaster-3.17.10 Manage your ports without external = databases or languages poudriere-devel-3.1.99.20171028 Port build and test system randomio-1.4 Multithreaded disk i/o microbenchmark readline-7.0.3_1 Library for editing command lines as they = are typed rsync-3.1.2_7 Network file distribution/synchronization = utility sqlite3-3.20.1_2 SQL database engine in a C library stress-1.0.4 Tool to impose load on and stress test = Unix-like systems sudo-1.8.21p2 Allow others to run commands as root unzip-6.0_7 List, test, and extract compressed files = from a ZIP archive wget-1.19.2 Retrieve files from the Net via HTTP(S) = and FTP zip-3.0_1 Create/update ZIP files compatible with = PKZIP So it is enough to keep the Pine64+ 2GB busy for a a notable time when rebuilt. In particular, gcc7-7.2.0_2 (and what it requires) takes a fair time to build. The poudriere build of the ports is currently the primary thing the ports are used for: build tests to catch build failures, should they occur. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Nov 14 10:54: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 6F503DBAD40 for ; Tue, 14 Nov 2017 10:54:40 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BCCE579CF2 for ; Tue, 14 Nov 2017 10:54:38 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from localhost ([92.134.207.235]) by mwinf5d26 with ME id ZmuU1w00A55FxF803muUrg; Tue, 14 Nov 2017 11:54:30 +0100 X-ME-Helo: localhost X-ME-Auth: Y2xidWlzc29uQHdhbmFkb28uZnI= X-ME-Date: Tue, 14 Nov 2017 11:54:30 +0100 X-ME-IP: 92.134.207.235 Subject: Re: rpi2: cpufreq(4) support lost ? To: Emmanuel Vadot , Mark Millard Cc: "Herbert J. Skuhra" , Andreas Schwarz , Freebsd-arm References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> <2cedd4c6-1db0-04e7-b131-b0f0fc2f0500@orange.fr> <20171113105430.720cdb0f887138b89c8e271e@bidouilliste.com> <20171113132000.1d680b95d87bd034c3945bb5@bidouilliste.com> From: Claude Buisson Message-ID: <22ced904-6322-4d11-586c-76ca6122f4a8@orange.fr> Date: Tue, 14 Nov 2017 11:54:27 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171113132000.1d680b95d87bd034c3945bb5@bidouilliste.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 10:54:40 -0000 On 11/13/2017 13:20, Emmanuel Vadot wrote: > On Mon, 13 Nov 2017 03:18:06 -0800 > Mark Millard wrote: > >> [sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c does not >> list "brcm,bcm2836": That is what I would have found >> if I had looked at the details before babbling >> incoherently.] > > That seems to be the problem yes. > I'll confirm tonight and commit a fix if nobody does it before me. > >> On 2017-Nov-13, at 1:54 AM, Emmanuel Vadot wrote: >> >>> On Sun, 12 Nov 2017 15:23:39 -0800 >>> Mark Millard wrote: >>> >>>> [This is a Linux *.dt* source issue, not specific to >>>> amrmv6 vs. armv7: FreeBSD has switched to Linux *.dt* >>>> source files, 4.13 most recently if I remember right.] >>> >>> This we do not use the DTS from Linux for RPI1/2 I doubt that. >> >> My apologies to all for the mistake for the rpi* context. >> >>>> On 2017-Nov-12, at 2:30 PM, Claude Buisson wrote: >>>> >>>>> On 11/12/2017 20:03, Herbert J. Skuhra wrote: >>>>> . . . >>>>> >>>>> So, something musst be wrong with the dtb file. I'm using now a file from >>>>> r323309, where cpufreq is available again. >>>> . . . >>> >>> The way to get functionality back is to find the real problem. >> >> Looking around, if I gather right, the only *.dt* >> source change after -r323309 was in -r324184 >> in rpi2.dts : >> >> compatible = "brcm,bcm2709"; >> >> was replaced by: >> >> compatible = "brcm,bcm2836"; >> >> Folks are reporting that the new code works with >> the old .dtb from before this change. This suggests >> that may be the differences between the lines: >> >> FDT_PLATFORM_DEF2(bcm2836, bcm2836_legacy, "bcm2836 (legacy)", 0, "brcm,bcm2709", 100); >> FDT_PLATFORM_DEF2(bcm2836, bcm2836, "bcm2836", 0, "brcm,bcm2836", 100); >> >> in sys/arm/broadcom/bcm2835/bcm2835_machdep.c might >> be involved in some way. In fact: >> >> /usr/src/sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c >> >> has: >> >> static struct ofw_compat_data compat_data[] = { >> { "broadcom,bcm2835-vc", 1 }, >> { "broadcom,bcm2708-vc", 1 }, >> { "brcm,bcm2709", 1 }, >> { NULL, 0 } >> }; >> >> which does not list "brcm,bcm2836" as an alternative >> but does list the "brcm,bcm2709" alternative. >> >> My guess is this explains the cpufreq code working >> for the older *.dtb files but not the newer ones. >> >>>> . . . >>>> >>>> === >>>> Mark Millard >>>> markmi at dsl-only.net >>> >>> All this is mostly wrong and doesn't have anything to do with the >>> cpufreq problem on RPI2. >> >> Again: sorry for the misapplied context. >> >>> Please stay focus. >> >> I clearly did not do appropriate investigation >> and incorrectly presumed what context would apply. >> My mistake for sure. >> >> >> Side note relative to BPI-M3 . . . >> >> FYI: The beginning of: >> >> https://lists.freebsd.org/pipermail/freebsd-arm/2017-November/017039.html >> >> lists what I've done locally to keep the BPI-M3 going as >> of head -r325700 . >> >> === >> Mark Millard >> markmi at dsl-only.net > > Just to confirm that the patch @ r325768 solves the cpufreq problem Claude Buisson From owner-freebsd-arm@freebsd.org Tue Nov 14 10:58:51 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 4E32DDBADC7 for ; Tue, 14 Nov 2017 10:58:51 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B03A079DA5 for ; Tue, 14 Nov 2017 10:58:50 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 02ce5d7a; Tue, 14 Nov 2017 11:58:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=TIle5fM5D7elN1Nv5L8MEqFBi+U=; b=lTj61/Q48G6lpaS6FgHbh6Vu07la mGiHcan1EjNuVhLT7PcNVeQHIxdkrNDcUQQPzCBeCamscmqeczVCySgTnLugVQC6 OG+3KY5ndF8I3z+QMDFylD6ZXf8v0Xi8smXyQV3L9RmXFnLi7gHVwqfvWK4QGETP VLkK/5yHThFbVSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=hQ1bwZLCS2SjnPJSuIcfolrNoW2OaberbGieicaXAuqjEwgsowj2RCpr Ez4lW7XG/7/L3oNa3W0Dq0Exkz7n/z2HOlRcvvTBghApSm99hnNsIS/o6A7WjqIs LnKGJFzNetJZ0S0hrYXDIXQ60poTk0+Rrl2n7lbRYmVDEoy4P8U= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 1153380d TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 14 Nov 2017 11:58:41 +0100 (CET) Date: Tue, 14 Nov 2017 11:58:41 +0100 From: Emmanuel Vadot To: Claude Buisson Cc: Mark Millard , "Herbert J. Skuhra" , Andreas Schwarz , Freebsd-arm Subject: Re: rpi2: cpufreq(4) support lost ? Message-Id: <20171114115841.bb0e9f849e62abc413f0796e@bidouilliste.com> In-Reply-To: <22ced904-6322-4d11-586c-76ca6122f4a8@orange.fr> References: <2bceba56-f6a8-5120-fac5-0d3387a8278d@orange.fr> <87a7zrgvzv.wl-herbert@mailbox.org> <2cedd4c6-1db0-04e7-b131-b0f0fc2f0500@orange.fr> <20171113105430.720cdb0f887138b89c8e271e@bidouilliste.com> <20171113132000.1d680b95d87bd034c3945bb5@bidouilliste.com> <22ced904-6322-4d11-586c-76ca6122f4a8@orange.fr> X-Mailer: Sylpheed 3.6.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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 10:58:51 -0000 On Tue, 14 Nov 2017 11:54:27 +0100 Claude Buisson wrote: > Just to confirm that the patch @ r325768 solves the cpufreq problem > > Claude Buisson Yes, sorry I meant to send a mail but forgot after starting doing other thing. Thanks to everyone who reported the problem. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Nov 14 11:29: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 4E441DBB5DB for ; Tue, 14 Nov 2017 11:29:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-121.reflexion.net [208.70.210.121]) (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 05DE07AAB0 for ; Tue, 14 Nov 2017 11:29:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5415 invoked from network); 14 Nov 2017 10:29:08 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Nov 2017 10:29:08 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 14 Nov 2017 05:29:08 -0500 (EST) Received: (qmail 15897 invoked from network); 14 Nov 2017 10:29:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Nov 2017 10:29:07 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 28F78EC8F04; Tue, 14 Nov 2017 02:29:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Mark Millard In-Reply-To: <23D8D3DB-CC10-4A61-924A-D81FF22E0250@dsl-only.net> Date: Tue, 14 Nov 2017 02:29:06 -0800 Cc: freebsd-arm@FreeBSD.org, Andreas Schwarz , ian@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2B53AA8A-7AA1-45F9-AA3C-144A69A51C0A@dsl-only.net> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <23D8D3DB-CC10-4A61-924A-D81FF22E0250@dsl-only.net> To: Henri Hennebert X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 11:29:10 -0000 [Top post of an FYI and other short notes.] FYI: My Pine64+ 2GB context uses an external USB3 powered hub with a USB3 SSD on one of the Pine64+ 2GB USB2 ports in order to hold the UFS root file system. (I can boot with just the sdcard but rarely do.) (I've only used ZFS in a couple of contexts, all with more than 2 GiBytes of RAM.) The -r320599 'works' point means that a (slow) bisect may be possible in your context to narrow the range of what changes in head might be at issue in your context. What is the smallest -r?????? figure above -r320599 that you have seen the problem with? Could you test some approximate mid-point between the two? (A difficulty with this can be avoiding other known problems in the history.) [End top post] On 2017-Nov-14, at 1:39 AM, Mark Millard wrote: > On 2017-Nov-13, at 11:06 PM, Henri Hennebert = wrote: >=20 >>> . . . >>=20 >> I believe that the clock of the Pine64+ is going too fast and that = the 2 servers where polled and so show this offset/jitter. In an other = occurrence of this problem, if I wait long enough, all servers display = huge offset. >> In a old version of Freebsd12, when dev.cpu.0.freq was accessible, = the problem appear when I force the frequency to 1200. >=20 > May be the time is just being damaged on occasion > or read-incorrectly sometimes? (Once seen as wrong, > the adjustment process will gradually change time > towards what it calculates as a supposedly better > time.) >=20 > Good to know that eventually all the servers show > a large jitter(?) at the same time. (Jitter reflects > more history and so may be a better reference.) >=20 >> In the same network, other computers (amd64) get no problem with this = ntpd configuration. >=20 > Good to know. It helps localize the issue. >=20 >>> It looks to me like you need to avoid those 2 severs, >>> substituting some others or some such. If some >>> communication channel(s) involved are corrupting data >>> then simply switching servers might not avoid the >>> issue? >>> I finally got a hold of the rpi3 and updated it to >>> -r325700 from back a -r320123. it has been up 9 hr >>> 40 min and date is still showing the correct time, >>> no evidence of huge offsets or huge jitter. >>> The Pine64+ 2GB is also at -r325700 now and has been >>> up for 2 days. It also is working fine. Again no >>> evidence of huge offsets or huge jitter. >>=20 >> Did you run heavy jobs running on this system? My Pine64+ is managing = my connection to internet (mpd5), named, dhcp, my mail (sendmail + = cyrus-imap) and dspam with postgres as db. The problem crops up when for = example I run a port upgrade. >=20 > I did a complete, from-scratch -j4 buildworld buildkernel > on the Pine64+ 2GB, keeping it busy for a little under > 18 hr + 10 min as I remember. top showed that it used some > swapspace during this. I included: >=20 > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLD_BOOTSTRAP=3D > WITH_LLD=3D > WITH_LLD_IS_LD=3D > WITH_LLDB=3D > WITH_BOOT=3D >=20 > But it did claim to reuse the system clang instead > of building a bootstrap clang compiler. Yet the > WITH_LLD_BOOTSTRAP=3D did lead to a bunch of > bootstrap activity anyway, so two builds of lld > related materials. (The purpose of the build > was to see if it would complete or not, extra work > made for a better test.) >=20 > It was on an earlier version than -r325700=20 > that I last rebuilt my ports but rebuilding the > ports has never caused a time problem either. > The ports builds were via poudriere. >=20 > But I do not use the Pine64+ 2GB for any of those > other things that you list as using yours for. I > do ssh over ethernet into the Pine64+ to work on > it but it is not a service provider at all, just > a machine for me to do build experiments with > (native and cross builds) and other forms of problem > investigations. nfs is present but little/rarely > used, and only temporarily in use at that. >=20 > As a step in potential isolation of what contributes > vs. what does not, could you temporarily revert to > not using/running the Pine64+ 2GB for the other > activities and try the ports builds and/or buildworld > buildkernel? Does it still have the problem in > something like my simpler context? >=20 > If time no long jumps, then you could add back an > activity and try again until the additions lead to > the time problem. That might give a clue what could > be interfering with time. >=20 > Also: I do not know if you have access to a 2nd > Pine64 to check for a device-specific problem by > switching devices temporarily. Such might also > allow keeping your services active while checking > the simpler context. >=20 > If Pine64s had a general time problem, there would > be a general problem for everyone else. I think the > stage of investigation is still: try to isolate a > smaller context sufficient to have the problem but > for which an even smaller context is observed to > not have the problem. Try to narrow the range of > differences between observed-working and > observed-failing to gain a clue about what > contributes to the problem vs. what does not. >=20 >=20 >=20 > FYI: Sitting idle the Pine64+ 2GB here shows > in top: >=20 > sshd: @pts/0 (sshd) > sshd: [priv] (sshd) > /usr/sbin/sshd > /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift > sendmail: accepting connections (sendmail) > sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) > /sbin/devd > top -CawPosize > login [pam] () > su () > top -CawPosize > /usr/sbin/mountd -r > su (sh) > -sh (sh) > -sh () > nfsd: master (nfsd) > dhclient: awg0 (dhclient) > /usr/sbin/cron -s () > dhclient: awg0 [priv] (dhclient) > /usr/sbin/syslogd -s > /usr/sbin/rpcbind > nfsd: server (nfsd) >=20 > (I do not normally use sendmail for anything. It > just sits there while the Pine64+ 2GB is up. nfs > is normally idle but is used on occasion.) >=20 > FYI: The installed ports list (far more is built > by poudriere): >=20 > # pkg info > atf-0.21 C, C++ and shell libraries to write = ATF-compliant test programs > binutils-2.28,1 GNU binary tools > bonnie-2.0.6_1 Performance Test of Filesystem I/O > bonnie++-1.97.3 Performance Test of Filesystem I/O > ca_root_nss-3.32.1 Root certificate bundle from the = Mozilla Project > curl-7.56.1 Command line tool and library for = transferring data with URLs > dialog4ports-0.1.6 Console Interface to configure ports > dtrace-toolkit-1.0_1 Collection of useful scripts for DTrace > dwarfdump-20161124 Tool to display DWARF debugging = information in ELF files > expat-2.2.1 XML 1.0 parser written in C > freebsd-release-manifests-20171003 FreeBSD release manifests > gcc7-7.2.0_2 GNU Compiler Collection 7 > gdb-8.0.1_1 GNU GDB of newer version than comes = with the system > gettext-runtime-0.19.8.1_1 GNU gettext runtime libraries and = programs > git-lite-2.14.3 Distributed source code management tool = (lite package) > gmp-6.1.2 Free library for arbitrary precision = arithmetic > indexinfo-0.3 Utility to regenerate the GNU info page = index > iorate-3.05 General purpose storage I/O = benchmarking tool > iozone-3.457 Performance Test of Sequential File I/O > kyua-0.13_4,3 Testing framework for infrastructure = software > libedit-3.1.20170329_2,1 Command line editor library > libidn2-2.0.4 Implementation of IDNA2008 = internationalized domain names > libnghttp2-1.27.0 HTTP/2.0 C Library > libunistring-0.9.7 Unicode string library > lua52-5.2.4 Small, compilable scripting language = providing easy access to C code > lutok-0.4_6 Lightweight C++ API for Lua > mpc-1.0.3 Library of complex numbers with = arbitrarily high precision > mpfr-3.1.6 Library for multiple-precision = floating-point computations > patch-2.7.5 GNU patch utility > pcre-8.40_1 Perl Compatible Regular Expressions = library > perl5-5.24.3 Practical Extraction and Report = Language > pkg-1.10.1 Package manager > portlint-2.17.13 Verifier for FreeBSD port directory > portmaster-3.17.10 Manage your ports without external = databases or languages > poudriere-devel-3.1.99.20171028 Port build and test system > randomio-1.4 Multithreaded disk i/o microbenchmark > readline-7.0.3_1 Library for editing command lines as = they are typed > rsync-3.1.2_7 Network file = distribution/synchronization utility > sqlite3-3.20.1_2 SQL database engine in a C library > stress-1.0.4 Tool to impose load on and stress test = Unix-like systems > sudo-1.8.21p2 Allow others to run commands as root > unzip-6.0_7 List, test, and extract compressed = files from a ZIP archive > wget-1.19.2 Retrieve files from the Net via HTTP(S) = and FTP > zip-3.0_1 Create/update ZIP files compatible with = PKZIP >=20 > So it is enough to keep the Pine64+ 2GB busy > for a a notable time when rebuilt. In particular, > gcc7-7.2.0_2 (and what it requires) takes a fair > time to build. >=20 > The poudriere build of the ports is currently the > primary thing the ports are used for: build tests > to catch build failures, should they occur. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Nov 14 22:03: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 37915DDF3F3 for ; Tue, 14 Nov 2017 22:03:57 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 C76CD71873; Tue, 14 Nov 2017 22:03:56 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4e330faa.dyn.telefonica.de [78.51.15.170]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vAEM3oJH085182; Tue, 14 Nov 2017 23:03:50 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org, ian@freebsd.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Tue, 14 Nov 2017 23:03:49 +0100 (CET) Message-ID: <4aff37249b6.70779c93@mail.schwarzes.net> In-Reply-To: References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Tue, 14 Nov 2017 23:03:50 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 22:03:57 -0000 On 14.11.17, Henri Hennebert wrote: > On 11/13/2017 21:03, Mark Millard wrote: >> >> So it looks like you are getting bad times from at >> least 2 servers. Note that the other servers seem >> fine as far as your e-mailed material goes. > > I believe that the clock of the Pine64+ is going too fast and that the 2 > servers where polled and so show this offset/jitter. In an other > occurrence of this problem, if I wait long enough, all servers display > huge offset. But they step not simultaneous to this offset (which is ~300s), why should some servers have such offset and others not?. Can you provide your "ntpq -c rl" output? If you disable the ntpd, what time drift do you measure per day? > In a old version of Freebsd12, when dev.cpu.0.freq was accessible, the > problem appear when I force the frequency to 1200. The dev.cpu.0.freq is already there in head/current. root@pinelot:~ # sysctl dev.cpu.0 dev.cpu.0.freq_levels: 1200/-1 1008/-1 816/-1 648/-1 408/-1 dev.cpu.0.freq: 408 dev.cpu.0.%parent: cpulist0 dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a53 dev.cpu.0.%location: dev.cpu.0.%driver: cpu dev.cpu.0.%desc: Open Firmware CPU root@pinelot:~ # uname -v FreeBSD 12.0-CURRENT #0 r325561: Thu Nov 9 11:24:55 CET 2017 root@pinelot.schwarzes.net:/usr/obj/usr/src/arm64.aarch64/sys/PINE64-ASC -asc From owner-freebsd-arm@freebsd.org Tue Nov 14 22:50: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 C1876DDFDBE for ; Tue, 14 Nov 2017 22:50:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-168.reflexion.net [208.70.210.168]) (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 3EFF472A94 for ; Tue, 14 Nov 2017 22:50:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23983 invoked from network); 14 Nov 2017 22:50:40 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Nov 2017 22:50:40 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 14 Nov 2017 17:50:40 -0500 (EST) Received: (qmail 684 invoked from network); 14 Nov 2017 22:50:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Nov 2017 22:50:40 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A596EEC891A; Tue, 14 Nov 2017 14:50:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Mark Millard In-Reply-To: <4aff37249b6.70779c93@mail.schwarzes.net> Date: Tue, 14 Nov 2017 14:50:38 -0800 Cc: freebsd-arm@FreeBSD.org, ian@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4AB259A5-F00A-408F-968A-26AD8D776708@dsl-only.net> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> To: Andreas Schwarz X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 22:50:48 -0000 [FYI: my sysctl dev.ctl.0 is not like Andreas showed.] On 2017-Nov-14, at 2:03 PM, Andreas Schwarz = wrote: > On 14.11.17, Henri Hennebert wrote: >> On 11/13/2017 21:03, Mark Millard wrote: >>>=20 >>> So it looks like you are getting bad times from at >>> least 2 servers. Note that the other servers seem >>> fine as far as your e-mailed material goes. >>=20 >> I believe that the clock of the Pine64+ is going too fast and that = the 2=20 >> servers where polled and so show this offset/jitter. In an other=20 >> occurrence of this problem, if I wait long enough, all servers = display=20 >> huge offset. >=20 > But they step not simultaneous to this offset (which is ~300s), why = should some=20 > servers have such offset and others not?. >=20 > Can you provide your "ntpq -c rl" output? >=20 > If you disable the ntpd, what time drift do you measure per day? >=20 >> In a old version of Freebsd12, when dev.cpu.0.freq was accessible, = the=20 >> problem appear when I force the frequency to 1200. >=20 >=20 > The dev.cpu.0.freq is already there in head/current. >=20 > root@pinelot:~ # sysctl dev.cpu.0 > dev.cpu.0.freq_levels: 1200/-1 1008/-1 816/-1 648/-1 408/-1 > dev.cpu.0.freq: 408 > dev.cpu.0.%parent: cpulist0 > dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,cortex-a53 > dev.cpu.0.%location: > dev.cpu.0.%driver: cpu > dev.cpu.0.%desc: Open Firmware CPU >=20 > root@pinelot:~ # uname -v > FreeBSD 12.0-CURRENT #0 r325561: Thu Nov 9 11:24:55 CET 2017 = root@pinelot.schwarzes.net:/usr/obj/usr/src/arm64.aarch64/sys/PINE64-ASC I'm not the one with the clock problem but I'll note that the -r325700 Pine64+ 2GB with a production-style kernel (not debug) that I'm using has rather different dev.cpu.0 output from sysctl as far as "freq" goes (no such): # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r325700M arm64 = aarch64 1200053 1200053 # sysctl dev.cpu.0 dev.cpu.0.%parent: cpulist0 dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,cortex-a53 dev.cpu.0.%location:=20 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: Open Firmware CPU Looking, /usr/ports -r447122 moved sysutils/u-boot-pine64 over to be us-boot-master based back on 2017-Aug-2. May be we have differing: u-boot-sunxi-with-spl.bin vintages dd'd to seek=3D8 on the sdcards? Some other difference someplace else? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Nov 15 01:09:13 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 3DA54DBAE9C for ; Wed, 15 Nov 2017 01:09:13 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 B3377776EC; Wed, 15 Nov 2017 01:09:12 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4e330faa.dyn.telefonica.de [78.51.15.170]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vAF197SQ086005; Wed, 15 Nov 2017 02:09:08 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org, ian@freebsd.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Wed, 15 Nov 2017 02:09:06 +0100 (CET) Message-ID: <4aff62bc14e.1f031cb6@mail.schwarzes.net> In-Reply-To: <4AB259A5-F00A-408F-968A-26AD8D776708@dsl-only.net> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <4AB259A5-F00A-408F-968A-26AD8D776708@dsl-only.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Wed, 15 Nov 2017 02:09:08 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 01:09:13 -0000 On 14.11.17, Mark Millard wrote: Hi Mark, > I'm not the one with the clock problem > but I'll note that the -r325700 Pine64+ > 2GB with a production-style kernel (not > debug) that I'm using has rather different > dev.cpu.0 output from sysctl as far as > "freq" goes (no such): My pine is the same, a PINE A64+ 2GB version. Using also a "non-debug" kernel config root@pinelot:~ $ cat /sys/arm64/conf/PINE64-ASC include "GENERIC" ident PINE64-ASC # remove predefined options from "GENERIC" nomakeoptions DEBUG nomakeoptions WITH_CTF nooptions KDB, KDB_TRACE, DDB nooptions INVARIANTS, INVARIANT_SUPPORT nooptions WITNESS, WITNESS_SKIPSPIN nooptions USB_DEBUG nooptions BUF_TRACKING nooptions DEADLKRES nooptions FULL_BUF_TRACKING # add options we want options TMPFS # Efficient memory filesystem > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r325700M arm64 aarch64 1200053 1200053 modified? > # sysctl dev.cpu.0 > dev.cpu.0.%parent: cpulist0 > dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a53 > dev.cpu.0.%location: > dev.cpu.0.%driver: cpu > dev.cpu.0.%desc: Open Firmware CPU > > Looking, /usr/ports -r447122 moved > sysutils/u-boot-pine64 over to be > us-boot-master based back on 2017-Aug-2. > May be we have differing: > > u-boot-sunxi-with-spl.bin > > vintages dd'd to seek=8 on the > sdcards? Some other difference > someplace else? Latest u-boot-sunxi-with-spl.bin was not working for me, I'm using an older one. Maybe a dtb processing problem, mine is up to date (created from the dts). -asc From owner-freebsd-arm@freebsd.org Wed Nov 15 02:54: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 A58FCDBD68E for ; Wed, 15 Nov 2017 02:54:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-135.reflexion.net [208.70.210.135]) (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 67BAD7AC42 for ; Wed, 15 Nov 2017 02:54:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30086 invoked from network); 15 Nov 2017 01:54:32 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 15 Nov 2017 01:54:32 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 14 Nov 2017 20:54:32 -0500 (EST) Received: (qmail 8700 invoked from network); 15 Nov 2017 01:54:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Nov 2017 01:54:31 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4D64EEC9055; Tue, 14 Nov 2017 17:54:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Mark Millard In-Reply-To: <4aff62bc14e.1f031cb6@mail.schwarzes.net> Date: Tue, 14 Nov 2017 17:54:30 -0800 Cc: freebsd-arm@FreeBSD.org, ian@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <4AB259A5-F00A-408F-968A-26AD8D776708@dsl-only.net> <4aff62bc14e.1f031cb6@mail.schwarzes.net> To: Andreas Schwarz X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:54:39 -0000 On 2017-Nov-14, at 5:09 PM, Andreas Schwarz = wrote: > On 14.11.17, Mark Millard wrote: >=20 > Hi Mark, >=20 >> I'm not the one with the clock problem >> but I'll note that the -r325700 Pine64+ >> 2GB with a production-style kernel (not >> debug) that I'm using has rather different >> dev.cpu.0 output from sysctl as far as >> "freq" goes (no such): >=20 > My pine is the same, a PINE A64+ 2GB version. >=20 > Using also a "non-debug" kernel config >=20 > root@pinelot:~ $ cat /sys/arm64/conf/PINE64-ASC >=20 > include "GENERIC" >=20 > ident PINE64-ASC >=20 > # remove predefined options from "GENERIC" > nomakeoptions DEBUG > nomakeoptions WITH_CTF > nooptions KDB, KDB_TRACE, DDB > nooptions INVARIANTS, INVARIANT_SUPPORT > nooptions WITNESS, WITNESS_SKIPSPIN > nooptions USB_DEBUG > nooptions BUF_TRACKING > nooptions DEADLKRES > nooptions FULL_BUF_TRACKING >=20 > # add options we want > options TMPFS # Efficient memory filesystem Showing my control of options: # more /usr/src/sys/arm64/conf/GENERIC-NODBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING >> # uname -apKU >> FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r325700M arm64 = aarch64 1200053 1200053 >=20 > modified? I normally run based on the same sources on all my builds, most of the modifications are tied to powerpc64 and powerpc. Some are tied to the BPI-M3 (that is currently unsupported in various respects). One is tied to my not having updated past -r325700 yet so I have fixes for things found in -r325700 that were checked in later (bcm2835_cpufreq.c). # svnlite status | sort ? sys/amd64/conf/GENERIC-DBG ? sys/amd64/conf/GENERIC-NODBG ? sys/arm/conf/GENERIC-DBG ? sys/arm/conf/GENERIC-NODBG ? sys/arm64/conf/GENERIC-DBG ? sys/arm64/conf/GENERIC-NODBG ? sys/powerpc/conf/GENERIC64vtsc-DBG ? sys/powerpc/conf/GENERIC64vtsc-NODBG ? sys/powerpc/conf/GENERICvtsc-DBG ? sys/powerpc/conf/GENERICvtsc-NODBG M contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M crypto/openssl/crypto/armcap.c M lib/libkvm/kvm_powerpc.c M lib/libkvm/kvm_private.c M sys/arm/allwinner/aw_usbphy.c M sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c M sys/arm64/arm64/identcpu.c M sys/boot/defs.mk M sys/boot/fdt/dts/arm/a83t.dtsi M sys/boot/powerpc/boot1.chrp/Makefile M sys/boot/powerpc/kboot/Makefile M sys/conf/kmod.mk M sys/conf/ldscript.powerpc M sys/kern/subr_pcpu.c M sys/modules/dtb/allwinner/Makefile M sys/powerpc/aim/mmu_oea64.c M sys/powerpc/ofw/ofw_machdep.c M sys/powerpc/powerpc/interrupt.c M sys/powerpc/powerpc/mp_machdep.c M sys/powerpc/powerpc/trap.c >> # sysctl dev.cpu.0 >> dev.cpu.0.%parent: cpulist0 >> dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,cortex-a53 >> dev.cpu.0.%location:=20 >> dev.cpu.0.%driver: cpu >> dev.cpu.0.%desc: Open Firmware CPU >>=20 >> Looking, /usr/ports -r447122 moved >> sysutils/u-boot-pine64 over to be >> us-boot-master based back on 2017-Aug-2. >> May be we have differing: >>=20 >> u-boot-sunxi-with-spl.bin >>=20 >> vintages dd'd to seek=3D8 on the >> sdcards? Some other difference >> someplace else? >=20 > Latest u-boot-sunxi-with-spl.bin was not working for me, I'm using an = older=20 > one. Maybe a dtb processing problem, mine is up to date (created from = the=20 > dts). For my context the DTB is from: EFI at 0x48000000 More fully: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 4 block devices......+ done ZFS found no pools UFS found 1 partition Consoles: EFI console =20 Command line arguments: loader.efi Image base: 0xb6dbb008 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=3D0x7fd808 data=3D0xb21e0+0x39b39c = syms=3D[0x8+0x10cfc8+0x8+0x103122] /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 0x48000000. . . . I expect that the above is why we have a difference. It may be an example of updated materials from elsewhere no longer supporting everything that older FreeBSD materials did. (This might might wait for upstream materials to update and be picked up by FreeBSD before the functionality returns.) One nice thing about our different contexts is that both have time working for what the Pine64+ 2GB's are being used for. (Not necessarily strongly overlapping usage patterns.) This suggests that DTB issues are not a likely cause of time breakage. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Nov 15 08:47: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 35492DD55B8 for ; Wed, 15 Nov 2017 08:47:44 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EAA433D9; Wed, 15 Nov 2017 08:47:43 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 0a73f55a; Wed, 15 Nov 2017 09:47:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=weyYexj7Nkr4Z4eO1WMXaqtORa0=; b=PzNokPsjyYFqXHz5cZSkb7paP0wH 6xFpOr65IEnHRFZjtLeDyoQzbnbtUlBkHctiOiak+VbAuWM8SxBsldbPwxcCOtcp EHVlgFAOD/tLEui0hPGhWvxqZmjycq1jHN5aKrDgf1In5ikKUMV9LZNzWB5o8Is1 iME02c4wIypoPYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=gGoVjz/lrogKGb9L6m1/7ppdvrzokKQ43M1Om8T33MpOOYx10tAON1OP rJrOH3Kc+IwGJA4JHYHUOqxe5ddtxSicVa4MVtFNFYvuUVqwt9imCJXSc0dEqEVn UzshQhP1+DFlV2god6bea+gLB/fLBoi9qVFSM35ntDl9P2TV5Ls= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 6016165d TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 15 Nov 2017 09:47:40 +0100 (CET) Date: Wed, 15 Nov 2017 09:47:39 +0100 From: Emmanuel Vadot To: Andreas Schwarz Cc: freebsd-arm@FreeBSD.org, ian@freebsd.org Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time Message-Id: <20171115094739.2dbd2a345738be42e56ff772@bidouilliste.com> In-Reply-To: <4aff62bc14e.1f031cb6@mail.schwarzes.net> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <4AB259A5-F00A-408F-968A-26AD8D776708@dsl-only.net> <4aff62bc14e.1f031cb6@mail.schwarzes.net> X-Mailer: Sylpheed 3.6.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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 08:47:44 -0000 On Wed, 15 Nov 2017 02:09:06 +0100 (CET) Andreas Schwarz wrote: > On 14.11.17, Mark Millard wrote: > > Hi Mark, > > > I'm not the one with the clock problem > > but I'll note that the -r325700 Pine64+ > > 2GB with a production-style kernel (not > > debug) that I'm using has rather different > > dev.cpu.0 output from sysctl as far as > > "freq" goes (no such): > > My pine is the same, a PINE A64+ 2GB version. > > Using also a "non-debug" kernel config > > root@pinelot:~ $ cat /sys/arm64/conf/PINE64-ASC > > include "GENERIC" > > ident PINE64-ASC > > # remove predefined options from "GENERIC" > nomakeoptions DEBUG > nomakeoptions WITH_CTF > nooptions KDB, KDB_TRACE, DDB > nooptions INVARIANTS, INVARIANT_SUPPORT > nooptions WITNESS, WITNESS_SKIPSPIN > nooptions USB_DEBUG > nooptions BUF_TRACKING > nooptions DEADLKRES > nooptions FULL_BUF_TRACKING > > # add options we want > options TMPFS # Efficient memory filesystem > > > > > # uname -apKU > > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r325700M arm64 aarch64 1200053 1200053 > > modified? > > > # sysctl dev.cpu.0 > > dev.cpu.0.%parent: cpulist0 > > dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a53 > > dev.cpu.0.%location: > > dev.cpu.0.%driver: cpu > > dev.cpu.0.%desc: Open Firmware CPU > > > > Looking, /usr/ports -r447122 moved > > sysutils/u-boot-pine64 over to be > > us-boot-master based back on 2017-Aug-2. > > May be we have differing: > > > > u-boot-sunxi-with-spl.bin > > > > vintages dd'd to seek=8 on the > > sdcards? Some other difference > > someplace else? > > Latest u-boot-sunxi-with-spl.bin was not working for me, I'm using an older > one. Maybe a dtb processing problem, mine is up to date (created from the > dts). > > -asc What was the problem with the ports ? Up to date with what ? sys/dts/arm64/ (sys/boot/fdt/dts/arm64) ? The current u-boot ports provide the DTS (it came from upstream Linux) and doesn't have the PMU (Power Management Unit) or the cpu-supply property for the cpu node while the one from sys/dts/arm64 does. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Nov 15 15:57: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 44694DE0D65 for ; Wed, 15 Nov 2017 15:57:32 +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 2275470411 for ; Wed, 15 Nov 2017 15:57:31 +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 vAFFvbPc036196 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Nov 2017 07:57:38 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vAFFvbMP036195; Wed, 15 Nov 2017 07:57:37 -0800 (PST) (envelope-from fbsd) Date: Wed, 15 Nov 2017 07:57:36 -0800 From: bob prohaska To: meloun.michal@gmail.com Cc: Svatopluk Kraus , "freebsd-arm@freebsd.org" Subject: Re: pmap fault during buildworld on rpi2 Message-ID: <20171115155736.GA36170@www.zefox.net> References: <20171006155854.GA40189@www.zefox.net> <20171007024638.GA41063@www.zefox.net> <20171104172704.GA77550@www.zefox.net> <895ccf89-961c-0dfa-f2cb-1309ef444f96@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <895ccf89-961c-0dfa-f2cb-1309ef444f96@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 15:57:32 -0000 On Sun, Nov 05, 2017 at 02:24:11PM +0100, Michal Meloun wrote: > > > Bob, > have you seen same panic (with pmap_fault -> abort_handler -> pmap_fault > sequence) with r325321 kernel (or newer)? Hi Michal, Not yet 8-) The system is up to r325750 bob > From owner-freebsd-arm@freebsd.org Wed Nov 15 21:18: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 692BDDE789C for ; Wed, 15 Nov 2017 21:18:38 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 0611F7C4CD for ; Wed, 15 Nov 2017 21:18:37 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4dbc05fd.dyn.telefonica.de [77.188.5.253]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vAFLIV4E093162 for ; Wed, 15 Nov 2017 22:18:31 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Wed, 15 Nov 2017 22:18:31 +0100 (CET) Message-ID: <4b007e1861e.7facb1c6@mail.schwarzes.net> In-Reply-To: <20171115094739.2dbd2a345738be42e56ff772@bidouilliste.com> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <4AB259A5-F00A-408F-968A-26AD8D776708@dsl-only.net> <4aff62bc14e.1f031cb6@mail.schwarzes.net> <20171115094739.2dbd2a345738be42e56ff772@bidouilliste.com> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Wed, 15 Nov 2017 22:18:32 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 21:18:38 -0000 On 15.11.17, Emmanuel Vadot wrote: > On Wed, 15 Nov 2017 02:09:06 +0100 (CET) > Andreas Schwarz wrote: > >> Latest u-boot-sunxi-with-spl.bin was not working for me, I'm using an older >> one. Maybe a dtb processing problem, mine is up to date (created from the >> dts). >> >> -asc > > What was the problem with the ports ? > Up to date with what ? sys/dts/arm64/ (sys/boot/fdt/dts/arm64) ? > > The current u-boot ports provide the DTS (it came from upstream Linux) > and doesn't have the PMU (Power Management Unit) or the cpu-supply > property for the cpu node while the one from sys/dts/arm64 does. This makes the difference, the u-boot port which I have in use, is loading the dtb from the fat partition. It's probably the u-boot port, which was provided with the pine64 image from the raspbsd.org page. This was my "starting point", in the meantime I've tried to replace the related blocks with differnt u-boot images, but not successful. -asc From owner-freebsd-arm@freebsd.org Wed Nov 15 23:05:35 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 BECBEDEA20D for ; Wed, 15 Nov 2017 23:05:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD1B28078C for ; Wed, 15 Nov 2017 23:05:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vAFN5Z7V032916 for ; Wed, 15 Nov 2017 23:05:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223693] arm/armv6 buildworld failure in zstd Date: Wed, 15 Nov 2017 23:05:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rpokala@panasas.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 23:05:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223693 Bug ID: 223693 Summary: arm/armv6 buildworld failure in zstd Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: rpokala@panasas.com Created attachment 188033 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D188033&action= =3Dedit Preprocessed sources While running `make tinderbox JFLAG=3D-j16' on base/head@r325858: --- all_subdir_lib/libzstd --- cc: error: unable to execute command: Abort trap (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) Target: armv6--freebsd12.0-gnueabihf Thread model: posix InstalledDir: /usr/bin cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preproces= sed source, and associated run script. ... --- all_subdir_lib/libzstd --- cc: note: diagnostic msg:=20 ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: cc: note: diagnostic msg: /tmp/zstd_compress-54318d.c cc: note: diagnostic msg: /tmp/zstd_compress-54318d.sh cc: note: diagnostic msg:=20 ******************** *** [zstd_compress.o] Error code 254 make[7]: stopped in /usr/home/rpokala/freebsd/clean/base/head/lib/libzstd --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Nov 15 23:10:53 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 C1984DEA41B for ; Wed, 15 Nov 2017 23:10:53 +0000 (UTC) (envelope-from hhwang@sent.com) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 96749808DC for ; Wed, 15 Nov 2017 23:10:53 +0000 (UTC) (envelope-from hhwang@sent.com) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D40CC20C0A for ; Wed, 15 Nov 2017 18:10:51 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute3.internal (MEProxy); Wed, 15 Nov 2017 18:10:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sent.com; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=z/dCkPkrU85YxWSWWuN4qn7JAslnNVn9N1dspXWflHE=; b=S9wWVduy 7epblJKiJVZQvIWGb/MncDFMMYphlVsXt4ze4QHI5jpxuNuyvAXKgC1H1Nr5b+ai DNiH6Zej53b+HXsFEPAYNvy5A6KjFDeTp/tuTOUQ23lCSrZ207gfZBRw5VS4HAI/ 5NofUzLg0HwwRlC1o901gem+ub2fzArXLoO1wDs4p4GUSNj5MsziOdQf+yi04FGf UcLlhwTscByZyIgMlHHO/iAYaAUVV+M3PNijPJPhwKTc86Y5RTfni0s6CIUSwN6+ clnvy/Y3fpUX8eL5kOPIR3wqhpKkSTDXbqlxvQwOR6R2X/IwyN8ML2diQEmeK5nZ 3SWH9gftqK1P1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=z/dCkPkrU85YxWSWWuN4qn7JAslnN Vn9N1dspXWflHE=; b=PWtYEz9oFIwgTBajVUj5twpzmqG/+c3464D5ietPhjHai t/47/gM2oHvkC5QRoltG84k9YmRWd5oBc4S7LYjbSThefno3X2EDwLozqVe4OmCR /IwebN6Af4IlynkhNK6TexehAbv0yNATVSytVKC2owzVLvqkZrbH39ir+zurtZUD p3B4PdCUwCzIOnNYlW4f1WCnvXom/R7qV4j+Fn2/TliHzAbLDy3MSMr0Vb50hNWS YK0qhgtid72yy3W3pz8VYtfNuAQxLiE4sXDc/fgbc/QZr3w1UdRO2MSBzzdxTGbd PhyZTfS6NuGVQBpzj8BX6VpQW+A1bWxEIn24fcgFg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B873E957AC; Wed, 15 Nov 2017 18:10:51 -0500 (EST) Message-Id: <1510787451.4128802.1173973544.3E3E0813@webmail.messagingengine.com> From: Hyun Hwang To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f89283c9 Subject: Raspberry Pi 2 - I2C related kpanic @ r324169 Date: Wed, 15 Nov 2017 18:10:51 -0500 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 23:10:53 -0000 Hello, I was trying to get readings from my accelerometer (MMA8451, requires I2C repeated start) via I2C, and suddenly kernel panicked. This is what appeared on the console: ``` Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xd775bcf0 FSR=00000005, FAR=00000000, spsr=40000013 r0 =c07ce200, r1 =ff704000, r2 =00000000, r3 =00000000 r4 =c39eb680, r5 =00000000, r6 =0000ffff, r7 =c06e569c r8 =c07d79e8, r9 =c07d79e8, r10=c3986b00, r11=d775bd90 r12=c090b288, ssp=d775bd80, slr=c0653334, pc =c0653488 [ thread pid 11 tid 100032 ] Stopped at bcm_bsc_fill_tx_fifo+0x74: db> ``` My Raspberry Pi 2 (v1.1) is currently running r325595 (armv7) with no WITNESS option given. I am currently rebuilding the kernel with WITNESS option given, to see if I can get more detailed messages. Judging by the function name, it looks like the I2C repeated start fix applied on r324169 had some problem? -- Hyun Hwang From owner-freebsd-arm@freebsd.org Thu Nov 16 04:52:26 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 E1CB0DBCA39 for ; Thu, 16 Nov 2017 04:52:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C81A86C374 for ; Thu, 16 Nov 2017 04:52:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vAG4qQ1R029347 for ; Thu, 16 Nov 2017 04:52:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223693] arm/armv6 buildworld failure in zstd Date: Thu, 16 Nov 2017 04:52:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: mmel@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 04:52:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223693 Michal Meloun changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |mmel@FreeBSD.org Resolution|--- |DUPLICATE --- Comment #2 from Michal Meloun --- *** This bug has been marked as a duplicate of bug 223072 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Thu Nov 16 08:49: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 944F7DD4E0F for ; Thu, 16 Nov 2017 08:49:06 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1816372666 for ; Thu, 16 Nov 2017 08:49:05 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id abf5855d; Thu, 16 Nov 2017 09:49:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=f8m2PHnpP77vjyWkFNGH/U3xeVw=; b=mwZEvR4yIUr2/zL9KrGdQr6QzeyM 4GVr+9zWZ3jTLDR8uIvEU40Vg+sFQM66nZQhD/iSNM5KLoZ6EfAiuZmztQiXIC67 OmsEEoyghgMzNYZnBQ4IGDkSaDRcZaLTlX2pZEbiFkSqy++gQNFrze76RUmY0dVq kTiFYr+tHUr7Xp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=gExAsQuBByDAsCwKeVCmBEmzvZSbt5JQnZ5bzXClV5dfa6uB7WlAOuDm 4NxEXundOkCfPDzCXI7ab6UWGwPAoL+vXMeaVTtdinA3FWVz+WheFOVd5CrGPuWJ s4ce2//OsOTi3XWMNt5nFiEdYsHU3wAGNrLageivzNcpANdDjSc= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id b694e8cc TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 16 Nov 2017 09:49:02 +0100 (CET) Date: Thu, 16 Nov 2017 09:49:01 +0100 From: Emmanuel Vadot To: Andreas Schwarz Cc: freebsd-arm@FreeBSD.org Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time Message-Id: <20171116094901.752e8b0f4ca15eb1349ef1fd@bidouilliste.com> In-Reply-To: <4b007e1861e.7facb1c6@mail.schwarzes.net> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <4AB259A5-F00A-408F-968A-26AD8D776708@dsl-only.net> <4aff62bc14e.1f031cb6@mail.schwarzes.net> <20171115094739.2dbd2a345738be42e56ff772@bidouilliste.com> <4b007e1861e.7facb1c6@mail.schwarzes.net> X-Mailer: Sylpheed 3.6.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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 08:49:06 -0000 On Wed, 15 Nov 2017 22:18:31 +0100 (CET) Andreas Schwarz wrote: > On 15.11.17, Emmanuel Vadot wrote: > > > On Wed, 15 Nov 2017 02:09:06 +0100 (CET) > > Andreas Schwarz wrote: > > > >> Latest u-boot-sunxi-with-spl.bin was not working for me, I'm using an older > >> one. Maybe a dtb processing problem, mine is up to date (created from the > >> dts). > >> > >> -asc > > > > What was the problem with the ports ? > > Up to date with what ? sys/dts/arm64/ (sys/boot/fdt/dts/arm64) ? > > > > The current u-boot ports provide the DTS (it came from upstream Linux) > > and doesn't have the PMU (Power Management Unit) or the cpu-supply > > property for the cpu node while the one from sys/dts/arm64 does. > > This makes the difference, the u-boot port which I have in use, is loading > the dtb from the fat partition. It's probably the u-boot port, which was > provided with the pine64 image from the raspbsd.org page. This was my > "starting point", in the meantime I've tried to replace the related blocks > with differnt u-boot images, but not successful. > > -asc Could you try the same setup that you have now but removing 1200000 1300000 from the operating_point table in sys/dts/arm64/a64.dtsi please ? I'm not sure that the pine64 is stable enough at this frequency. Thanks, -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Nov 16 09:46:55 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 A1B22DD78AF for ; Thu, 16 Nov 2017 09:46:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-151.reflexion.net [208.70.210.151]) (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 471B37421F for ; Thu, 16 Nov 2017 09:46:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21773 invoked from network); 16 Nov 2017 09:40:08 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 16 Nov 2017 09:40:08 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 16 Nov 2017 04:40:08 -0500 (EST) Received: (qmail 2008 invoked from network); 16 Nov 2017 09:40:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Nov 2017 09:40:08 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C7255EC7B4E; Thu, 16 Nov 2017 01:40:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Mark Millard In-Reply-To: <20171116094901.752e8b0f4ca15eb1349ef1fd@bidouilliste.com> Date: Thu, 16 Nov 2017 01:40:07 -0800 Cc: Andreas Schwarz , freebsd-arm@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <4C01F5D2-BBEA-4E2A-8414-0F503BDD7917@dsl-only.net> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <4AB259A5-F00A-408F-968A-26AD8D776708@dsl-only.net> <4aff62bc14e.1f031cb6@mail.schwarzes.net> <20171115094739.2dbd2a345738be42e56ff772@bidouilliste.com> <4b007e1861e.7facb1c6@mail.schwarzes.net> <20171116094901.752e8b0f4ca15eb1349ef1fd@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 09:46:55 -0000 On 2017-Nov-16, at 12:49 AM, Emmanuel Vadot = wrote: > On Wed, 15 Nov 2017 22:18:31 +0100 (CET) > Andreas Schwarz wrote: >=20 >> On 15.11.17, Emmanuel Vadot wrote: >>=20 >>> On Wed, 15 Nov 2017 02:09:06 +0100 (CET) >>> Andreas Schwarz wrote: >>>=20 >>>> Latest u-boot-sunxi-with-spl.bin was not working for me, I'm using = an older=20 >>>> one. Maybe a dtb processing problem, mine is up to date (created = from the=20 >>>> dts). >>>>=20 >>>> -asc >>>=20 >>> What was the problem with the ports ? >>> Up to date with what ? sys/dts/arm64/ (sys/boot/fdt/dts/arm64) ? >>>=20 >>> The current u-boot ports provide the DTS (it came from upstream = Linux) >>> and doesn't have the PMU (Power Management Unit) or the cpu-supply >>> property for the cpu node while the one from sys/dts/arm64 does. >>=20 >> This makes the difference, the u-boot port which I have in use, is = loading=20 >> the dtb from the fat partition. It's probably the u-boot port, which = was=20 >> provided with the pine64 image from the raspbsd.org page. This was my >> "starting point", in the meantime I've tried to replace the related = blocks=20 >> with differnt u-boot images, but not successful. >>=20 >> -asc >=20 > Could you try the same setup that you have now but removing 1200000 > 1300000 from the operating_point table in sys/dts/arm64/a64.dtsi > please ? > I'm not sure that the pine64 is stable enough at this frequency. Just FYI: whatever frequency ends up being used based on the u-boot-master based u-boot has worked fine for me on the Pine64+ 2GB. -j4 buidlworld, buildkernel. (clang full and extras, lldb, lld bootstrapped and normal all being included.) Also poudriere building ports allowing the job to use all 4 cores. I build gcc7 and what it depends on, for example. But I have a case with a fan for cooling and heatsinks. The power supply is one for an official rpi3 one as well. (So, it has a slightly higher voltage than normal: 5.1V.) The fan gets power from the Pine64+ 2GB. But the USB SSD is via a powered hub. The hub is the only USB device plugged in. Ethernet present and sometimes used. FYI: my last from-scratch buildworld buildkernel on the Pine64+ 2GB took a little under 18 hr + 10 min and was of -r325700 (built by -r325700 that was from a cross-build). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Nov 16 09:49: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 6AD2ADD79BB for ; Thu, 16 Nov 2017 09:49:48 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 05A24742EB for ; Thu, 16 Nov 2017 09:49:47 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3ycxKv1LGCzrtY Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3ycxKv1LGCzrtY for ; Thu, 16 Nov 2017 10:49:38 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id vAG9nbTx091956 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 16 Nov 2017 10:49:38 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time To: freebsd-arm@FreeBSD.org References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> From: Henri Hennebert Message-ID: <3e6a8ce3-1b12-1557-ad0c-7b2259ced263@restart.be> Date: Thu, 16 Nov 2017 10:49:37 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4aff37249b6.70779c93@mail.schwarzes.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 09:49:48 -0000 On 11/14/2017 23:03, Andreas Schwarz wrote: > On 14.11.17, Henri Hennebert wrote: >> On 11/13/2017 21:03, Mark Millard wrote: >>> >>> So it looks like you are getting bad times from at >>> least 2 servers. Note that the other servers seem >>> fine as far as your e-mailed material goes. >> >> I believe that the clock of the Pine64+ is going too fast and that the 2 >> servers where polled and so show this offset/jitter. In an other >> occurrence of this problem, if I wait long enough, all servers display >> huge offset. > > But they step not simultaneous to this offset (which is ~300s), why should some > servers have such offset and others not?. > > Can you provide your "ntpq -c rl" output? [root@norquay norquay]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 94.143.184.140 .GPS. 1 u 51 128 17 16.202 -1.216 95656.2 178.32.44.208 ( 162.23.41.10 2 u 128 128 17 15.085 -178951 178957. ssh2.ulyssis.st 193.79.237.14 2 u 124 128 17 14.255 1.174 67639.2 ntp.kennisdelen 193.190.230.66 2 u 3 128 37 14.844 1.526 95655.9 hades.boxed-it. 193.67.79.202 2 u 60 128 17 12.179 1.281 146117. s01.be.it2go.eu 193.190.230.66 2 u 54 128 17 27.489 2.413 113181. 213.189.188.3.i 193.190.230.65 2 u 54 128 17 15.965 -178956 163366. ntp.katho.be 193.190.230.66 2 u 7 128 17 16.901 -2.730 95653.6 ntp.gillam-fei. 172.16.200.253 2 u 65 128 17 21.549 -178955 178957. *ntp.cybertu.be 193.190.230.65 2 u 10 128 3 15.199 -178955 0.134 [root@norquay norquay]# ntpq -c rl associd=0 status=0613 leap_none, sync_ntp, 1 event, spike_detect, version="ntpd 4.2.8p10-a (1)", processor="arm64", system="FreeBSD/12.0-CURRENT", leap=00, stratum=3, precision=-21, rootdelay=19.914, rootdisp=179188.957, refid=51.255.138.215, reftime=ddb7da3d.1efde957 Thu, Nov 16 2017 10:34:53.121, clock=ddb7da85.9f27db8d Thu, Nov 16 2017 10:36:05.621, peer=30993, tc=7, mintc=3, offset=1.497713, frequency=28.955, sys_jitter=0.000000, clk_jitter=1.380, clk_wander=0.097, tai=37, leapsec=201701010000, expire=201712280000 > > If you disable the ntpd, what time drift do you measure per day? > With nrpd disabled, while running svn update on /usr/ports, after 1/2 hour the clock was 6 minutes in the future. >> In a old version of Freebsd12, when dev.cpu.0.freq was accessible, the >> problem appear when I force the frequency to 1200. > > > The dev.cpu.0.freq is already there in head/current. > > root@pinelot:~ # sysctl dev.cpu.0 > dev.cpu.0.freq_levels: 1200/-1 1008/-1 816/-1 648/-1 408/-1 > dev.cpu.0.freq: 408 > dev.cpu.0.%parent: cpulist0 > dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a53 > dev.cpu.0.%location: > dev.cpu.0.%driver: cpu > dev.cpu.0.%desc: Open Firmware CPU > > root@pinelot:~ # uname -v > FreeBSD 12.0-CURRENT #0 r325561: Thu Nov 9 11:24:55 CET 2017 root@pinelot.schwarzes.net:/usr/obj/usr/src/arm64.aarch64/sys/PINE64-ASC > > > -asc > > _______________________________________________ > 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 Nov 16 16:58:42 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 1B62FDE2ED4 for ; Thu, 16 Nov 2017 16:58:42 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56BD41B25 for ; Thu, 16 Nov 2017 16:58:40 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 62b3be82-caef-11e7-b805-f37e907b5733 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 62b3be82-caef-11e7-b805-f37e907b5733; Thu, 16 Nov 2017 16:58:37 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vAGGwYRM001327; Thu, 16 Nov 2017 09:58:34 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1510851514.99235.378.camel@freebsd.org> Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Ian Lepore To: Andreas Schwarz , freebsd-arm@FreeBSD.org Date: Thu, 16 Nov 2017 09:58:34 -0700 In-Reply-To: <4aff37249b6.70779c93@mail.schwarzes.net> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 16:58:42 -0000 On Tue, 2017-11-14 at 23:03 +0100, Andreas Schwarz wrote: > On 14.11.17, Henri Hennebert wrote: > > > > On 11/13/2017 21:03, Mark Millard wrote: > > > > > > > > > So it looks like you are getting bad times from at > > > least 2 servers. Note that the other servers seem > > > fine as far as your e-mailed material goes. > > I believe that the clock of the Pine64+ is going too fast and that the 2  > > servers where polled and so show this offset/jitter. In an other  > > occurrence of this problem, if I wait long enough, all servers display  > > huge offset. > But they step not simultaneous to this offset (which is ~300s), why should some  > servers have such offset and others not?. > Because not all peers are being polled at the same time, and the offset and jitter are updated only after a polling cycle.  In the last ntpq: >>      remote           refid      st t when poll reach   delay   offset jitter >> ============================================================================== >> 0.freebsd.pool. .POOL.          16 p    -   64    0    0.000    0.000  0.000 >> -webhost2.mitht. 193.67.79.202    2 u  948 1024  177   58.815    1.451 0.932 >> +ns2.telecom.lt  212.59.3.3       2 u   13 1024  177   43.400  -357912 357913. >> +ntp.bserved.nl  193.67.79.202    2 u 1111 1024   37   17.664    0.980 0.379 >> -178.32.44.208 ( 193.190.230.65   2 u   81 1024  177   14.930    1.087 135278. >> *stratum2-1.NTP. 129.70.130.71    2 u 1077 1024   77   28.135    1.998 0.570 >> -linode.ibendit. 199.102.46.77    2 u 2048 1024   76  129.945    0.307 0.584 >> #193.104.37.238  193.190.230.66   2 u  799 1024   77   14.977    1.321 0.821 Notice that the two anomalous servers are the ones with a small "when" value, indicating they were polled within the last couple minutes. Also, the fact that some of the "when" values are larger than the polling interval is unusual... that would tend to indicate network trouble... some of the servers are only beeing reached intermitantly (which can be seen by the incomplete "reach" masks). The idea that two public stratum-2 servers are providing consistant bad time is not a viable theory. Also, the time is good and stable for several of the ten-minute intervals, and it was good for long enough that the polling interval ramped up from 64 to 1024 seconds (assuming there is no "minpoll" override forcing it to 1024 in ntp.conf).  That argues against any kind of constant clock-drift problem.  Either the clock is stepping due to a problem in the driver such as not handling rollover of a 32-bit register, or the clock goes wildly off-frequency, but only intermittantly.  The latter might happen if the cpu clock is being used as a timecounter and the cpu falls back to a low-power mode that cuts the clock frequency in half or something. -- Ian From owner-freebsd-arm@freebsd.org Thu Nov 16 17:17:22 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 5295ADE3BB3 for ; Thu, 16 Nov 2017 17:17:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E74682DB9 for ; Thu, 16 Nov 2017 17:17:21 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: fbf0e750-caf1-11e7-b805-f37e907b5733 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id fbf0e750-caf1-11e7-b805-f37e907b5733; Thu, 16 Nov 2017 17:17:13 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vAGHHASe001383; Thu, 16 Nov 2017 10:17:10 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1510852630.99235.381.camel@freebsd.org> Subject: Re: Raspberry Pi 2 - I2C related kpanic @ r324169 From: Ian Lepore To: Hyun Hwang , freebsd-arm@freebsd.org Date: Thu, 16 Nov 2017 10:17:10 -0700 In-Reply-To: <1510787451.4128802.1173973544.3E3E0813@webmail.messagingengine.com> References: <1510787451.4128802.1173973544.3E3E0813@webmail.messagingengine.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 17:17:22 -0000 On Wed, 2017-11-15 at 18:10 -0500, Hyun Hwang wrote: > Hello, > > I was trying to get readings from my accelerometer (MMA8451, requires > I2C repeated start) via I2C, and suddenly kernel panicked. > This is what appeared on the console: > ``` > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xd775bcf0 > FSR=00000005, FAR=00000000, spsr=40000013 > r0 =c07ce200, r1 =ff704000, r2 =00000000, r3 =00000000 > r4 =c39eb680, r5 =00000000, r6 =0000ffff, r7 =c06e569c > r8 =c07d79e8, r9 =c07d79e8, r10=c3986b00, r11=d775bd90 > r12=c090b288, ssp=d775bd80, slr=c0653334, pc =c0653488 > > [ thread pid 11 tid 100032 ] > Stopped at      bcm_bsc_fill_tx_fifo+0x74: > db> > ``` > My Raspberry Pi 2 (v1.1) is currently running r325595 (armv7) with no > WITNESS option given. I am currently rebuilding the kernel with > WITNESS option given, to see if I can get more detailed messages. > > Judging by the function name, it looks like the I2C repeated start > fix applied on r324169 had some problem? That was my first suspicion: I broke something. :) Is it easily reproducible?  I don't expect witness to add anything; given the FAR value, it looks like a NULL pointer problem.  If you can make it happen easily, could you do a "bt" at the db> propmt and paste that output, please? -- Ian From owner-freebsd-arm@freebsd.org Thu Nov 16 21:45: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 B1D0EDEA677 for ; Thu, 16 Nov 2017 21:45:45 +0000 (UTC) (envelope-from hhwang@sent.com) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 833B96C0B7; Thu, 16 Nov 2017 21:45:45 +0000 (UTC) (envelope-from hhwang@sent.com) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id AF52220DD9; Thu, 16 Nov 2017 16:45:43 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute3.internal (MEProxy); Thu, 16 Nov 2017 16:45:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sent.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=2x7Omx8BDxzcxtDsVggV3QDQyKAux z3lpgDvMcOVP2o=; b=kt2RhGjUg11/rQRF8w2O4UJR7I1ThW0bbCveZ96TNBniY no0qRs/Uqsba1SHsD4QQvCpucDrn/iJlJx5NqPwk8uorFmYaVLHJ0RIGh4dcxrPZ R9mZAnLezeuR1Jvx/U7q/3VsFG91XY7c13tF9ATF5PEmtoMPdXp1ce4hIBingJZq AgWg+pUMtAMZBPU6pY5CBYRPpBldML5/GwFRRroMHUPy05R2TdZKyvxPECGAiP9H 1br/g7kHQtfokaQsJwhrUJ2PYp97WdAEb0faEdJ09jlC32ReQeXpvcdrxSgQGMnX evEJlePTnZauQIg6TS07sqDgLP266/Nbo1PQMPwfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=2x7Omx 8BDxzcxtDsVggV3QDQyKAuxz3lpgDvMcOVP2o=; b=LH63DNwng3dNs6S1qZX6rO GnUViPSfXxB8pk1BxBtseOQs9RyPXImp8x+EwJ9L4mOcRY22SK1x4ottPKjNErya MyYiRMttE1t3vF8FHHX3DJa53YY+ZDtvzK+kxlDOMteZ9lq7jk4mXmx6jDzq5jZf ziOuygWQJJsh4suAk6xNks7GxU9Ep4jDHsy/0A1sHd7/66HRzEEPpJJ0e1LRTgea Lw2RQlP8N9HO8KHiG1IktcoZ+uvcS9BTnsU4NF8CrsI8+W4NC5Zag8Az6neQSB0F zTnL0A9HeolVY0qbJ1b9+WFGp8lS1jV9mYdVPzswqRRDDlurJnBSML9/Pa3OLZ3w == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 82CDCBAB63; Thu, 16 Nov 2017 16:45:43 -0500 (EST) Message-Id: <1510868743.702301.1175172960.770CBAE8@webmail.messagingengine.com> From: Hyun Hwang To: Ian Lepore Cc: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4ef04c51 In-Reply-To: <1510852630.99235.381.camel@freebsd.org> Subject: Re: Raspberry Pi 2 - I2C related kpanic @ r324169 Date: Thu, 16 Nov 2017 16:45:43 -0500 References: <1510787451.4128802.1173973544.3E3E0813@webmail.messagingengine.com> <1510852630.99235.381.camel@freebsd.org> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 21:45:45 -0000 On Thu, Nov 16, 2017, at 12:17, Ian Lepore wrote: > I broke something. :) Please do not take my message was to blame you; I greatly appreciate what you did to support the repeated start condition on RPi. > Is it easily reproducible? This happens quite randomly, but I managed to reproduce it several times more, especially within gdb(1)-ing my application. > I don't expect witness to add anything; given the FAR value, it looks like a NULL pointer problem. With WITNESS (using standard sys/arm/conf/RPI2 kernel configuration), at least the panic gave me the exact instruction as well as additional messages: ``` Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex bcm_bsc (bcm_bsc) r = 0 (0xc3d2f688) locked @ /usr/src/sys/arm/broadcom/bcm2835/bcm2835_bsc.c:480 stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L2)' on read ... snip (very similar to the one in the previous message) ... Stopped at bcm_bsc_fill_tx_fifo+0x74: ldrb r3, [r2] db> ``` Hope this helps a bit more. > could you do a "bt" at the db> propmt and paste that output, please? Unfortunately, when the kernel panics, the USB keyboard stops working so I cannot type anything... I will try to find other means that can give input to the debugger. (maybe UART serial?) Thank you. -- Hyun Hwang From owner-freebsd-arm@freebsd.org Fri Nov 17 01:39: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 4ABA3DF0118 for ; Fri, 17 Nov 2017 01:39:04 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 DF3A774204 for ; Fri, 17 Nov 2017 01:39:03 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4dbb050c.dyn.telefonica.de [77.187.5.12]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vAH1cvrw099098 for ; Fri, 17 Nov 2017 02:38:57 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Fri, 17 Nov 2017 02:38:56 +0100 (CET) Message-ID: <4b020c88b12.5031eb6c@mail.schwarzes.net> In-Reply-To: <20171116094901.752e8b0f4ca15eb1349ef1fd@bidouilliste.com> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <4AB259A5-F00A-408F-968A-26AD8D776708@dsl-only.net> <4aff62bc14e.1f031cb6@mail.schwarzes.net> <20171115094739.2dbd2a345738be42e56ff772@bidouilliste.com> <4b007e1861e.7facb1c6@mail.schwarzes.net> <20171116094901.752e8b0f4ca15eb1349ef1fd@bidouilliste.com> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Fri, 17 Nov 2017 02:38:57 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 01:39:04 -0000 On 16.11.17, Emmanuel Vadot wrote: > Andreas Schwarz wrote: >> This makes the difference, the u-boot port which I have in use, is loading >> the dtb from the fat partition. It's probably the u-boot port, which was >> provided with the pine64 image from the raspbsd.org page. This was my >> "starting point", in the meantime I've tried to replace the related blocks >> with differnt u-boot images, but not successful. > > Could you try the same setup that you have now but removing 1200000 > 1300000 from the operating_point table in sys/dts/arm64/a64.dtsi > please ? > I'm not sure that the pine64 is stable enough at this frequency. I'm not the OP with the ntp problem, my pine runs @1200 without any problems for days (when compiling toolset and world using 4 cores). -asc From owner-freebsd-arm@freebsd.org Fri Nov 17 02:00:13 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 C31A9DF06E9 for ; Fri, 17 Nov 2017 02:00:13 +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 A4765748FD for ; Fri, 17 Nov 2017 02:00:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vAH20Jf5041706 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Nov 2017 18:00:20 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vAH20JE5041705; Thu, 16 Nov 2017 18:00:19 -0800 (PST) (envelope-from fbsd) Date: Thu, 16 Nov 2017 18:00:19 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: panic: dead bo 0xc47cf854 on rpi2 Message-ID: <20171117020019.GA41643@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 02:00:13 -0000 While running make clean in /usr/ports an rpi2 running FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #8 r325884: Thu Nov 16 01:28:57 PST 2017 bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/RPI2 arm reported panic: dead bo 0xc47cf854 Console, backtrace and logfile are at http://www.zefox.net/~fbsd/rpi2/crashes/crash_11_16_17/ I've never before seen a panic during make clean, in ports or src, so it was a considerable surprise. One other oddity was that an ssh session running a top window started to exit and close the ssh session without errors repeatedly after the make clean started, so it's unlikely the top window shown has much to do with what was running at the time of the panic. Thanks for reading, and any suggestions. bob prohaska From owner-freebsd-arm@freebsd.org Fri Nov 17 02:39:54 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 BC8B1DF19AE for ; Fri, 17 Nov 2017 02:39:54 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 5C82076133 for ; Fri, 17 Nov 2017 02:39:54 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4dbb050c.dyn.telefonica.de [77.187.5.12]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vAH2dgow099608 for ; Fri, 17 Nov 2017 03:39:42 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Fri, 17 Nov 2017 03:39:41 +0100 (CET) Message-ID: <4b021ad4813.3aa2749e@mail.schwarzes.net> In-Reply-To: <3e6a8ce3-1b12-1557-ad0c-7b2259ced263@restart.be> References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <3e6a8ce3-1b12-1557-ad0c-7b2259ced263@restart.be> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Fri, 17 Nov 2017 03:39:42 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 02:39:54 -0000 On 16.11.17, Henri Hennebert wrote: > On 11/14/2017 23:03, Andreas Schwarz wrote: >> >> If you disable the ntpd, what time drift do you measure per day? >> > With nrpd disabled, while running svn update on /usr/ports, after 1/2 > hour the clock was 6 minutes in the future. I've made the test with my Pine64, I've disabled the ntpd and set the pine under heavy load at all cores for a hour. There was no time drift. You wrote in your previous email, that the problem appear when you set the freq to 1200. With higher freq the system consumes more power (not much, but more), do you have checked your power adapter, is the 5V stable under high load? -asc From owner-freebsd-arm@freebsd.org Fri Nov 17 07:43: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 A6592DBD21F for ; Fri, 17 Nov 2017 07:43:31 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 67D117E0C1 for ; Fri, 17 Nov 2017 07:43:31 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3ydVTs0dfGzsKP Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3ydVTs0dfGzsKP for ; Fri, 17 Nov 2017 08:43:28 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id vAH7hR7n014126 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 17 Nov 2017 08:43:27 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time To: freebsd-arm@FreeBSD.org References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <3e6a8ce3-1b12-1557-ad0c-7b2259ced263@restart.be> <4b021ad4813.3aa2749e@mail.schwarzes.net> From: Henri Hennebert Message-ID: <8e125980-d985-9d05-2da2-8d68220b19e9@restart.be> Date: Fri, 17 Nov 2017 08:43:27 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4b021ad4813.3aa2749e@mail.schwarzes.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 07:43:31 -0000 On 11/17/2017 03:39, Andreas Schwarz wrote: > On 16.11.17, Henri Hennebert wrote: >> On 11/14/2017 23:03, Andreas Schwarz wrote: >>> >>> If you disable the ntpd, what time drift do you measure per day? >>> >> With nrpd disabled, while running svn update on /usr/ports, after 1/2 >> hour the clock was 6 minutes in the future. > > I've made the test with my Pine64, I've disabled the ntpd and set the pine > under heavy load at all cores for a hour. There was no time drift. > > You wrote in your previous email, that the problem appear when you set the > freq to 1200. With higher freq the system consumes more power (not much, but > more), do you have checked your power adapter, is the 5V stable under high > load? At revision r324563 with the new u-boot I have no more access to dev.cpu.0.freq. I'm only saying that I observe the same problem when I was using the FreeBSD-aarch64-12.0-GENERIC-312006M.img.gz from RaspBSD and setting the freq to 1200. At r320599 (without access to dev.cpu.0.freq) all is running smoothly. I think that the DTS may be the problem. > > -asc > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Nov 17 10:57:42 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 D5898DC11F8 for ; Fri, 17 Nov 2017 10:57:42 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C5CF3778 for ; Fri, 17 Nov 2017 10:57:42 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3ydZnn5PCYztYq Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3ydZnn5PCYztYq for ; Fri, 17 Nov 2017 11:57:33 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id vAHAvVUK048605 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 17 Nov 2017 11:57:32 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time To: freebsd-arm@FreeBSD.org References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <3e6a8ce3-1b12-1557-ad0c-7b2259ced263@restart.be> <4b021ad4813.3aa2749e@mail.schwarzes.net> From: Henri Hennebert Message-ID: <32fb3c08-9fc8-a8b2-000b-b9932a69cebf@restart.be> Date: Fri, 17 Nov 2017 11:57:31 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4b021ad4813.3aa2749e@mail.schwarzes.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 10:57:42 -0000 On 11/17/2017 03:39, Andreas Schwarz wrote: > On 16.11.17, Henri Hennebert wrote: >> On 11/14/2017 23:03, Andreas Schwarz wrote: >>> >>> If you disable the ntpd, what time drift do you measure per day? >>> >> With nrpd disabled, while running svn update on /usr/ports, after 1/2 >> hour the clock was 6 minutes in the future. > > I've made the test with my Pine64, I've disabled the ntpd and set the pine > under heavy load at all cores for a hour. There was no time drift. > > You wrote in your previous email, that the problem appear when you set the > freq to 1200. With higher freq the system consumes more power (not much, but > more), do you have checked your power adapter, is the 5V stable under high > load? > > -asc FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320599M: Mon Oct 2 10:06:00 CEST 2017 root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 without ntpd, keeps time correctly after 3 hours and with make buildworld running. > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Nov 17 11:35: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 160C4DC1CC6 for ; Fri, 17 Nov 2017 11:35:48 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CB0C7638A7 for ; Fri, 17 Nov 2017 11:35:47 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3ydbds5kCNztnH Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3ydbds5kCNztnH for ; Fri, 17 Nov 2017 12:35:45 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id vAHBchLO052511 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 17 Nov 2017 12:38:43 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Henri Hennebert To: freebsd-arm@FreeBSD.org References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <3e6a8ce3-1b12-1557-ad0c-7b2259ced263@restart.be> <4b021ad4813.3aa2749e@mail.schwarzes.net> <32fb3c08-9fc8-a8b2-000b-b9932a69cebf@restart.be> Message-ID: <0706441c-eee7-9f6e-3e3b-44a362bc7317@restart.be> Date: Fri, 17 Nov 2017 12:35:44 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <32fb3c08-9fc8-a8b2-000b-b9932a69cebf@restart.be> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 11:35:48 -0000 On 11/17/2017 11:57, Henri Hennebert wrote: > On 11/17/2017 03:39, Andreas Schwarz wrote: >> On 16.11.17, Henri Hennebert wrote: >>> On 11/14/2017 23:03, Andreas Schwarz wrote: >>>> >>>> If you disable the ntpd, what time drift do you measure per day? >>>> >>> With nrpd disabled, while running svn update on /usr/ports, after 1/2 >>> hour the clock was 6 minutes in the future. >> >> I've made the test with my Pine64, I've disabled the ntpd and set the >> pine >> under heavy load at all cores for a hour. There was no time drift. >> >> You wrote in your previous email, that the problem appear when you set >> the >> freq to 1200. With higher freq the system consumes more power (not >> much, but >> more), do you have checked your power adapter, is the 5V stable under >> high >> load? >> >> -asc > > FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 > r320599M: Mon Oct  2 10:06:00 CEST 2017 > root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY  arm64 > > without ntpd, keeps time correctly after 3 hours and with make > buildworld running. But after 2 more hours, it was 3 minutes too fast :-( > > >> >> _______________________________________________ >> 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 Fri Nov 17 17:49:52 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 B9D6DDDF9A8; Fri, 17 Nov 2017 17:49:52 +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 8EF456F03D; Fri, 17 Nov 2017 17:49:52 +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 vAHHo4w5044243 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Nov 2017 09:50:05 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vAHHo49i044242; Fri, 17 Nov 2017 09:50:04 -0800 (PST) (envelope-from fbsd) Date: Fri, 17 Nov 2017 09:50:04 -0800 From: bob prohaska To: ports@freebsd.org, freebsd-arm@freebsd.org Subject: Make clean trying to unmount /dev on RPI2 in /usr/ports Message-ID: <20171117175004.GA44217@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 17:49:52 -0000 Lateley attempts to run make in /usr/ports has been generating errors along the lines of umount: unmount of /dev failed: No such file or directory umount: retrying using path instead of file system ID The first time it appeared was while running make index, but it happened again running make -j4 clean. It's hard to believe this is intentional behavior, am I mistaken? Svnlite info reports Path: . Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 454376 Node Kind: directory Schedule: normal Last Changed Author: wen Last Changed Rev: 454376 Last Changed Date: 2017-11-17 07:11:59 -0800 (Fri, 17 Nov 2017) Thanks for reading and any guidance, bob prohaska From owner-freebsd-arm@freebsd.org Sat Nov 18 16:56: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 3EA9DDBF79E for ; Sat, 18 Nov 2017 16:56:32 +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 0E1D075E82 for ; Sat, 18 Nov 2017 16:56:31 +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 vAIGudfc048001 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Nov 2017 08:56:39 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vAIGuc6Z048000; Sat, 18 Nov 2017 08:56:38 -0800 (PST) (envelope-from fbsd) Date: Sat, 18 Nov 2017 08:56:38 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: ssh sessions close spontaneously on rpi2 Message-ID: <20171118165638.GA47956@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 16:56:32 -0000 It appears that something(s) are profoundly amiss on r325916 when running on rpi2. With make -j4 clean running in /usr/ports, new ssh connections fail promptly after login. For example ===========begin copy/paste=========== bob@raspberrypi:~ $ ssh com Password for bob@www.zefox.com: Last login: Sat Nov 18 08:38:45 2017 from 192.168.1.20 FreeBSD 12.0-CURRENT (RPI2) #9 r325916: Fri Nov 17 01:03:51 PST 2017 To change an environment variable in /bin/sh use: $ VARIABLE="value" $ export VARIABLE bob@www:~ % Connection to com closed. bob@raspberrypi:~ $ bob@raspberrypi:~ $ ssh com Password for bob@www.zefox.com: Last login: Sat Nov 18 08:41:33 2017 from 192.168.1.20 FreeBSD 12.0-CURRENT (RPI2) #9 r325916: Fri Nov 17 01:03:51 PST 2017 You can use aliases to decrease the amount of typing you need to do to get commands you commonly use. Examples of fairly popular aliases include (in Bourne shell style, as in /bin/sh, bash, ksh, and zsh): alias lf="ls -FA" alias ll="ls -lA" alias su="su -m" In csh or tcsh, these would be alias lf ls -FA alias ll ls -lA alias su su -m To remove an alias, you can usually use 'unalias aliasname'. To list all aliases, you can usually type just 'alias'. bob@www:~ % Connection to com closed. =============end copy/paste============ Stopping the make clean session restores normal behavior. Long-established ssh connections seem to keep functioning normally, three have stayed up overnight, though two restarts of the make clean session. At the same time, the reports of attempted umounts of /dev seem to have stopped, although the make clean sessions still stop, with only a cryptic "2 errors" on the controlling ssh session. There's nothing on the console or in the message log. Altogether this is rather disturbing and I'd be grateful for any insights. bob prohaska From owner-freebsd-arm@freebsd.org Sat Nov 18 20:45:53 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 AB270DDBE40 for ; Sat, 18 Nov 2017 20:45:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-148.reflexion.net [208.70.210.148]) (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 5CDD37C9B1 for ; Sat, 18 Nov 2017 20:45:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24431 invoked from network); 18 Nov 2017 20:45:46 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 18 Nov 2017 20:45:46 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 18 Nov 2017 15:45:46 -0500 (EST) Received: (qmail 15071 invoked from network); 18 Nov 2017 20:45:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Nov 2017 20:45:46 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A64CAEC7B4E; Sat, 18 Nov 2017 12:45:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ssh sessions close spontaneously on rpi2 From: Mark Millard In-Reply-To: <20171118165638.GA47956@www.zefox.net> Date: Sat, 18 Nov 2017 12:45:45 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <1A09ACF9-1A85-480D-90BD-9886FC54D116@dsl-only.net> References: <20171118165638.GA47956@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 20:45:53 -0000 On 2017-Nov-18, at 8:56 AM, bob prohaska wrote: > It appears that something(s) are profoundly amiss on r325916 when running > on rpi2. > > With make -j4 clean running in /usr/ports, new ssh connections fail > promptly after login. For example > > ===========begin copy/paste=========== > bob@raspberrypi:~ $ ssh com > Password for bob@www.zefox.com: > Last login: Sat Nov 18 08:38:45 2017 from 192.168.1.20 > FreeBSD 12.0-CURRENT (RPI2) #9 r325916: Fri Nov 17 01:03:51 PST 2017 > To change an environment variable in /bin/sh use: > > $ VARIABLE="value" > $ export VARIABLE > bob@www:~ % Connection to com closed. > bob@raspberrypi:~ $ > bob@raspberrypi:~ $ ssh com > Password for bob@www.zefox.com: > Last login: Sat Nov 18 08:41:33 2017 from 192.168.1.20 > FreeBSD 12.0-CURRENT (RPI2) #9 r325916: Fri Nov 17 01:03:51 PST 2017 > You can use aliases to decrease the amount of typing you need to do to get > commands you commonly use. Examples of fairly popular aliases include (in > Bourne shell style, as in /bin/sh, bash, ksh, and zsh): > > alias lf="ls -FA" > alias ll="ls -lA" > alias su="su -m" > > In csh or tcsh, these would be > > alias lf ls -FA > alias ll ls -lA > alias su su -m > > To remove an alias, you can usually use 'unalias aliasname'. To list all > aliases, you can usually type just 'alias'. > bob@www:~ % Connection to com closed. > =============end copy/paste============ > > Stopping the make clean session restores normal behavior. Long-established > ssh connections seem to keep functioning normally, three have stayed up > overnight, though two restarts of the make clean session. > > At the same time, the reports of attempted umounts of /dev seem to have > stopped, although the make clean sessions still stop, with only a cryptic > "2 errors" on the controlling ssh session. There's nothing on the console > or in the message log. > > Altogether this is rather disturbing and I'd be grateful for any insights. [Be warned that the BPI-M3 context here is experimental currently: official build support has been disabled for now, pending the switch to Linux based DTB content. (There is a committer waiting for that *.dt* source to be in FreeBSD.) I've temporarily patched a few things to keep my BPI-M3 builds going during the "not supported" time.] It may not be rpi2 specific but an example of a more general armv7(/6?) issue: Using -r325700 (on both the BPI-M3 and amd64) and a debug kernel (but with DIAGNOSTICs disabled) I've discovered that when I nfs mount the BPI-M3 from the amd64 and try a recursive diff: # mount -o noatime,hard,intr :/ /mnt # diff -r /usr/src/sys/ /mnt/src/sys/ the Ethernet connection on the BPI-M3 stops working: existing connections time out and ping in and out both fail. (The serial console still works fine.) Via the serial console I can sometimes restart the networking via: # ifconfig awg0 down # ifconfig awg0 up but if the "diff -r" is still going when I do that the BPI-M3 networking will quickly fail again. No console messages, no core files. So far this type of test sequence always fails in a fairly short time. [DIAGNOSTICS was disabled because with it enabled the USB did not find USB devices and I normally use a USB SSD for the root file system.] === Mark Millard markmi at dsl-only.net