From owner-freebsd-arm@freebsd.org Sun Mar 12 08: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 70A5DD098D8 for ; Sun, 12 Mar 2017 08:17:34 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 010271222 for ; Sun, 12 Mar 2017 08:17:34 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wr0-x241.google.com with SMTP id u48so16452394wrc.1 for ; Sun, 12 Mar 2017 00:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:references:to:cc:reply-to:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=zg+mLZAScbvuHUkohdtCcnrkGiAa2ak09iIwXFKb338=; b=WGadorADMD9Bc1mpfvSHHF4PF1+NQLm2UR8yFpkGwNYhAUugKYAYfI7alYY50ow/IC rfN+ZZMx4cN72sfJItue+9yGDTXwS3nv6R3Sdo96jvmpGQZcPnuV6o8n9zwvSqZMd8ET Na5OUKL4yvHa2AHkrpwxEzYel2u9YkBtW017njo5A6/GuLVvHKKAoc8VQbrMQ3FDFtot ip0a7kLAcohp0YspzSzDekN+5m5UlygWS4UQFEGuoedsGz+KhmGRjlgMP94VlFU3ydON Gkuc98+zOVndHUSR6MCJ7ocN+mZSmdnM1HJO+I7rGo4ctyo8U6ifJ0fn+u1BwuwzeS5+ cfvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:cc:reply-to :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=zg+mLZAScbvuHUkohdtCcnrkGiAa2ak09iIwXFKb338=; b=M1xF6pU30xcZ7sTpFWhx4ujIM6pzUGnwuVMGunvBu4OZdcuVgrkpsTqlrEevY5cGJN vXbOlJVLyde1gDjHB1LvquIgCDoESga8jMbWQkT0mC5gDyY6xbkPv8ZwROZe2nknG5IY 2J7ThuXaBbDDzt9FuP1OvVN6F7SR6udK3gFkQ0U3us+ERFF4QMClHXxB2qLuMDvyJ4xc AQXrUi3rs0ZO7EVAEFYbrhD++JLwBdo+o+46e+jBDl7gbfC7C0tzBQTqmyuzY8Vmh+eN 5Vm+faMwt0+gjzZc7E1bLZO0AMvzv2HWQBh1ElsiNimeibtRbiS4JyPwoJRoxH0ih/yf Qxsg== X-Gm-Message-State: AMke39ltO98RR7OBDLr01SEfYByUNjto2cnhlxRwUIxNmPBV545Lan8VLiz+gduB8ybjTQ== X-Received: by 10.223.163.7 with SMTP id c7mr22561215wrb.17.1489306652525; Sun, 12 Mar 2017 00:17:32 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id y1sm6506338wme.15.2017.03.12.00.17.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Mar 2017 00:17:31 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <20170310174444.GN16105@kib.kiev.ua> To: Konstantin Belousov , Andrew Gierth Cc: "freebsd-arm@freebsd.org" Reply-To: mmel@freebsd.org Message-ID: Date: Sun, 12 Mar 2017 09:17:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170310174444.GN16105@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 08:17:34 -0000 On 10.03.2017 18:44, Konstantin Belousov wrote: > On Fri, Mar 10, 2017 at 04:10:49PM +0000, Andrew Gierth wrote: >>>>>>> "Warner" == Warner Losh writes: >> >> Warner> I've not had good luck getting it to work. (cortex-a7 is the >> Warner> proper type name, btw). It kinda works, but ports are kinda >> Warner> wonky. >> >> >> Well, I can now report that with a local fix for #217611 in place >> >> and everything recompiled for cortex-a7, I'm not seeing any >> >> wonkiness at all even with a lot of ports in use. >> >> Warner> Awesome. What's the local fix? Is it in FreeBSD yet? >> >> No, it's not in FreeBSD yet; I attached it as a patch to the bugzilla >> report: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 >> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180669&action=diff >> >> My fix requires breaking the ABI, since the definition of mcontext_t >> simply does not have enough space to store all the registers, so I'm >> assuming it won't go into stable/11 (though that really needs _some_ >> kind of fix, since the bug can be demonstrated with ordinary >> floating-point code and no compile options). >> >> It needs attention from someone with more kernel/arm experience than I >> have to see whether I've missed something obvious (or subtle). >> >> (Maybe I should have filed it under "kern" rather than "arm"?) > > When x86 AVX support was added, the very same problem existed: the x86 > mcontext_t has no space to store AVX registers, and worse, architecture > explicitely allowed for future coprocessors to extend the register file > further. In other words, even if breaking ABI and adding the storage > to mcontext_t for AVX once was decided, the solution would be not > sustainable. > > Also note that extending mcontext_t is very painful, because it is > embedded into ucontext_t in the middle, so the change means that whole > signal-delivery ABI is broken. In other words, a lot of compat shims > is needed, each time. > > The x86 solution was to put new coprocessor state outside > of the mcontext_t and pointing to it. This allowed the grow > to happens transparently, mostly controlled by kernel. The > getcontextx(3) function was added to not change expectation of (rare) > getcontext(3) consumers that ucontext_t is self-contained. One of > the important getcontextx(3) users is libthr, and there the internal > __getcontextx_size()/__fillcontextx2() interface was added. > > I am not sure which tier the ARMv6 architecture is. It would seems to > migrate to tier1 almost, but the ABI was broken recently with switch > to hardfp. If indeed tier1, then ABI breakage is considered imadmissible, > and getcontextx() route is probably good enough. The issue I see is that > there is no reserved unused fields in mcontext_t on ARM, so probably some > trick with not using fpu save area at all for fpu registers might be > needed. > > If applying your patch because the ABI breakage is permitted for ARM, > note that besides requiring recompilation, we also loose ability to > run older binaries, including jails. ARM is still tier2, but I significantly prefer getcontextx() (or any other, backward compatible) way. Unfortunately, on armv6, the VFP part of kernel <-> userland interaction is broken from day 1. The struct fpreg is also wrong and I'm not sure if or how we can to fix this in compatible way. Michal From owner-freebsd-arm@freebsd.org Sun Mar 12 08:52: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 859F6D07225 for ; Sun, 12 Mar 2017 08:52:43 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50FD31333 for ; Sun, 12 Mar 2017 08:52:42 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cmzF1-0004Wp-4e for freebsd-arm@freebsd.org; Sun, 12 Mar 2017 09:52:39 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Date: Sun, 12 Mar 2017 09:52:38 +0100 Subject: ubldr.bin on sheevaplug (11-STABLE) MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: b5e1a7a6a0a97f953de832680fded840 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 08:52:43 -0000 Hello, I just build a new 11-STABLE for my Sheevaplug. (BTW, it feels a lot mor= e = stable the last two or three months. I can still create UFS corruption o= n = my usb-stick, but it does not crash that often anymore.) Back to the subject. I just tried ubldr.bin again. Previous attempts gav= e = no output and just hang. But now I get an error. This is what I did: ----------------------------------------------------------- START # 09:40:06 root@sheeva2 [/boot] nandtool erase dev=3D/dev/gnand0s.fbsd-boot # 09:40:15 root@sheeva2 [/boot] dd if=3Dubldr.bin of=3D/dev/gnand0s.fbsd-boot bs=3D2k conv=3Dsync 120+1 records in 121+0 records out 247808 bytes transferred in 0.251712 secs (984489 bytes/sec) # 09:40:43 root@sheeva2 [/boot] shutdown -r now <... snip ...> Rebooting... =C3=BE __ __ _ _ | \/ | __ _ _ ____ _____| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |____/ \___/ \___/ \__| ** MARVELL BOARD: SHEEVA PLUG LE U-Boot 1.1.4 (Jul 19 2009 - 16:03:28) Marvell version: 3.4.19 U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CFB00 Soc: 88F6281 A0 (DDR2) CPU running @ 1200Mhz L2 running @ 400Mhz SysClock =3D 400Mhz , TClock =3D 200Mhz DRAM CAS Latency =3D 5 tRP =3D 5 tRAS =3D 18 tRCD=3D6 DRAM CS[0] base 0x00000000 size 256MB DRAM CS[1] base 0x10000000 size 256MB DRAM Total size 512MB 16bit width Addresses 8M - 0M are saved for the U-Boot usage. Mem malloc Initialization (8M - 7M): Done NAND:512 MB Flash: 0 kB CPU : Marvell Feroceon (Rev 1) Streaming disabled Write allocate disabled USB 0: host mode PEX 0: interface detected no Link. Net: egiga0 [PRIME], egiga1 Hit any key to stop autoboot: 0 NAND read: device 0 offset 0x200000, size 0x600000 6291456 bytes read: OK ## Starting application at 0x00900000 ... data abort pc : [<0092a0c0>] lr : [<00919fe4>] sp : 005fe43c ip : 0093a950 fp : 005fe454 r10: 00000000 r9 : 0093de48 r8 : 00938ce8 r7 : 01badab1 r6 : 00938ceb r5 : 00938ce8 r4 : 00000000 r3 : 00000000 r2 : 00938ce8 r1 : 00000001 r0 : 0093bfb8 Flags: Nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ... ----------------------------------------------------------- END The commands are the same as when I install kernel.bin. I only substitut= ed = the if=3D value of dd with ubldr.bin. Any ideas? Can I provide more information? Regards, Ronald. From owner-freebsd-arm@freebsd.org Sun Mar 12 13:57: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 B6FE0D093E8 for ; Sun, 12 Mar 2017 13:57:18 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54E431FB9 for ; Sun, 12 Mar 2017 13:57:17 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489327034; l=541; s=domk; d=obsigna.com; h=Mime-Version:To:Date:Subject:Content-Transfer-Encoding:Content-Type: From; bh=6XwWevKDn1OR2lTA9cXK+v66DJeWhp4MLsk0ajqgous=; b=wpcjuf4T3O6Al3Vq7n5VZHWE3crhcAZXlf621OIwOXh3L/f6LnadU1XHjFRN5ccjAC M1scf4Z0INn9dIyaKkK6xm5cNRCF/h2tfdIW1qtyEqD9utI4A5myzK8VNyohuXFb7wJO HuKB4Syb4enPvIenGkNrtaDDGh6RWm/CmmJFk= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0i99HgKKA= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b584.virtua.com.br [187.2.181.132]) by smtp.strato.de (RZmta 40.1 DYNA|AUTH) with ESMTPSA id w0350bt2CDvDKTg (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sun, 12 Mar 2017 14:57:13 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id A6B907506DAD for ; Sun, 12 Mar 2017 10:57:10 -0300 (BRT) From: "Dr. Rolf Jansen" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Enabling ADC on a Beaglebone Black running FreeBSD 12.0-CURRENT (BEAGLEBONE) Message-Id: <0C4DCBB9-2642-4B0F-B15B-4139D5D8B249@obsigna.com> Date: Sun, 12 Mar 2017 10:57:09 -0300 To: freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 13:57:18 -0000 I experience problems to enable the ADC line of my BBB. Apparently, in FreeBSD 10, the ADC lines would have been enabled by a = sysctl call: sysctl dev.ti_adc.0.ain.0.enable=3D1 On FreeBSD 12, this gives: sysctl: unknown oid 'dev.ti_adc.0.ain.0.enable' I thought, perhaps the driver has not been loaded into the kernel, but: kldload ti_adc =20 >>>> kldload: can't load ti_adc: module already loaded or in kernel Question: What do I need to get the ADC working with FreeBSD 12? Best regards Rolf= From owner-freebsd-arm@freebsd.org Sun Mar 12 14:54:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2234BD094FB for ; Sun, 12 Mar 2017 14:54:29 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 085731D5B for ; Sun, 12 Mar 2017 14:54:28 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: de11a213-0733-11e7-ba57-8bc134ee460a 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.ore.mailhop.org (Halon) with ESMTPSA id de11a213-0733-11e7-ba57-8bc134ee460a; Sun, 12 Mar 2017 14:55:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2CEsQ5Z001285; Sun, 12 Mar 2017 08:54:26 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1489330466.40576.79.camel@freebsd.org> Subject: Re: ubldr.bin on sheevaplug (11-STABLE) From: Ian Lepore To: Ronald Klop , freebsd-arm@freebsd.org Date: Sun, 12 Mar 2017 08:54:26 -0600 In-Reply-To: References: 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 14:54:29 -0000 On Sun, 2017-03-12 at 09:52 +0100, Ronald Klop wrote: > Hello, > > I just build a new 11-STABLE for my Sheevaplug. (BTW, it feels a lot > more   > stable the last two or three months. I can still create UFS > corruption on   > my usb-stick, but it does not crash that often anymore.) > > Back to the subject. I just tried ubldr.bin again. Previous attempts > gave   > no output and just hang. But now I get an error. > > This  is what I did: > ----------------------------------------------------------- START > # 09:40:06 root@sheeva2 [/boot] > nandtool erase dev=/dev/gnand0s.fbsd-boot > > # 09:40:15 root@sheeva2 [/boot] > dd if=ubldr.bin of=/dev/gnand0s.fbsd-boot bs=2k conv=sync > 120+1 records in > 121+0 records out > 247808 bytes transferred in 0.251712 secs (984489 bytes/sec) > > # 09:40:43 root@sheeva2 [/boot] > shutdown -r now > <... snip ...> > Rebooting... > þ >           __  __                      _ _ >          |  \/  | __ _ _ ____   _____| | | >          | |\/| |/ _` | '__\ \ / / _ \ | | >          | |  | | (_| | |   \ V /  __/ | | >          |_|  |_|\__,_|_|    \_/ \___|_|_| >   _   _     ____              _ > > > > > > > > > > > > > > > > > > >   | __ )  ___   ___ | |_ > > > > > ___|  _ \ / _ \ / _ \| __| > > > _| |___| |_) | (_) | (_) | |_ >   \___/    |____/ \___/ \___/ \__| >   ** MARVELL BOARD: SHEEVA PLUG LE > > U-Boot 1.1.4 (Jul 19 2009 - 16:03:28) Marvell version: 3.4.19 > > U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFB00 > > Soc: 88F6281 A0 (DDR2) > CPU running @ 1200Mhz L2 running @ 400Mhz > SysClock = 400Mhz , TClock = 200Mhz > > DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 > DRAM CS[0] base 0x00000000   size 256MB > DRAM CS[1] base 0x10000000   size 256MB > DRAM Total size 512MB  16bit width > Addresses 8M - 0M are saved for the U-Boot usage. > Mem malloc Initialization (8M - 7M): Done > NAND:512 MB > Flash:  0 kB > > CPU : Marvell Feroceon (Rev 1) > > Streaming disabled > Write allocate disabled > > > USB 0: host mode > PEX 0: interface detected no Link. > Net:   egiga0 [PRIME], egiga1 > Hit any key to stop autoboot:  0 > > NAND read: device 0 offset 0x200000, size 0x600000 >   6291456 bytes read: OK > ## Starting application at 0x00900000 ... > data abort > pc : [<0092a0c0>]    lr : [<00919fe4>] > sp : 005fe43c  ip : 0093a950  fp : 005fe454 > r10: 00000000  r9 : 0093de48  r8 : 00938ce8 > r7 : 01badab1  r6 : 00938ceb  r5 : 00938ce8  r4 : 00000000 The clue to why this doesn't work is in the above line:  01badab1... read that as "01 bad abi", ubldr failed on the first check of whether u-boot provided the interface needed to do console and disk IO. The only way to fix this is to use a custom-built u-boot that has the CONFIG_API option set.  I've never tried that on an armv4/5 system, but it should work. -- Ian > r3 : 00000000  r2 : 00938ce8  r1 : 00000001  r0 : 0093bfb8 > Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32 > Resetting CPU ... > > ----------------------------------------------------------- END > > The commands are the same as when I install kernel.bin. I only > substituted   > the if= value of dd with ubldr.bin. > > Any ideas? > Can I provide more information? > > Regards, > Ronald. From owner-freebsd-arm@freebsd.org Sun Mar 12 16: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 BE9E6D096DC for ; Sun, 12 Mar 2017 16:49:06 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 570AB1301 for ; Sun, 12 Mar 2017 16:49:05 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sun, 12 Mar 2017 17:43:53 +0100 id 00F4BE72.58C57AC9.0000D505 Date: Sun, 12 Mar 2017 17:43:53 +0100 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Re: FreeBSD on Pine64 experience Message-ID: <20170312174353.13e1110d@zeta.dino.sk> In-Reply-To: <20170224182831.76c15809@zeta.dino.sk> References: <20170220124619.7f04ad6a@zeta.dino.sk> <20170224182831.76c15809@zeta.dino.sk> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; i386-portbld-freebsd10.3) 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 16:49:06 -0000 [ snip ] > > Originally it was 12.0-CURRENT # - does anybody > > know where this revision number is being lost? Could it be somehow > > caused by fact my src tree was 'svn checkout'ed on another machine > > (i386)? > > > > Well, I can not verify my theory - I am not able to do svn checkout > into nfs mounted directory from arm64 and armv6 systems (nfsd runs on > i386 system). Maybe it just could not work this way... > This problem is solved, discussion was on hackers mailing list, basically mount option nolockd was the clue. However, on Pine64, I am getting now occasional errors pid 12421 (sh), uid 0, was killed: text file modification preventing me to rebuild some port or source if tree is mounted over nfs. I remember mentioning on some mailing list it could be related to nfs, today I decide to use HDD attached via USB for ports tree and no error occured. So this definitely means there is something in nfs code, probably arm64 specific as I did not see something like this on arm system, which causes this error. I will try to do another full rebuild with /usr/src and /usr/obj located on local USB attached HDD to see if there is any difference. My svn revision is r314342 currently, there is some discrepancy now however, as I have kernel slightly newer than world. Another note - I upgraded misc/mc port today, and I see something strange. See: # pkg check -d -a Checking all packages: 100% mc is missing a required shared library: libglib-2.0.so.0 mc is missing a required shared library: libssh2.so.1 mc is missing a required shared library: libintl.so.8 # ldd /usr/local/bin/mc /usr/local/bin/mc: libncursesw.so.8 => /lib/libncursesw.so.8 (0x4011c000) libssh2.so.1 => /usr/local/lib/libssh2.so.1 (0x4017c000) libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x401b1000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x402b1000) libc.so.7 => /lib/libc.so.7 (0x402ca000) libz.so.6 => /lib/libz.so.6 (0x40452000) libssl.so.8 => /usr/lib/libssl.so.8 (0x40477000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x404ea000) libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x406ba000) libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x407c2000) libthr.so.3 => /lib/libthr.so.3 (0x4084e000) # ll /usr/local/lib/libglib-2.0.so.0 lrwxr-xr-x 1 root wheel 23 Feb 17 20:13 /usr/local/lib/libglib-2.0.so.0@ -> libglib-2.0.so.0.4600.2 # ll /usr/local/lib/libintl.so.8 lrwxr-xr-x 1 root wheel 16 Feb 17 00:00 /usr/local/lib/libintl.so.8@ -> libintl.so.8.1.5 # ll /usr/local/lib/libssh2.so.1 lrwxr-xr-x 1 root wheel 16 Feb 17 20:28 /usr/local/lib/libssh2.so.1@ -> libssh2.so.1.0.1 And mc seems to be just working... rebuilding misc/mc does not change the situation. Regards, Milan From owner-freebsd-arm@freebsd.org Sun Mar 12 17:05: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 18E82D09E8D for ; Sun, 12 Mar 2017 17:05:57 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB8CD1E97 for ; Sun, 12 Mar 2017 17:05:56 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22a.google.com with SMTP id v125so204343369qkh.2 for ; Sun, 12 Mar 2017 10:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=OqmfSZtP9CC0WsyDlDyz3ya3NAf5Wd8/LoIuAkFbXak=; b=cBs55nGudc5Cc9fSDg+mN+SKDLhbb4ChEncmRK5QW2dd73i0PDmdL+X1XZo9IyELKL RtdHHaioPmYuz85N7QKw45f4C2oweJ3NoJVhECQMKvSnQ/aS2+le/y+8kNdvKnI8ZWLB I5CyZrD7Kue5k9UbGFRMI4DiRxUtbFLVOUFNY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OqmfSZtP9CC0WsyDlDyz3ya3NAf5Wd8/LoIuAkFbXak=; b=dPM4+2UUXtTDT/ypq3lUVMMZ14ZAKCpKV+OM4WbRtyHpUlJTqFY1VeYXwLN+LOqepj i49YwA5QDUU03y/7vnrTKVirtaHRkJdVh49UHYTAM7FBfFC9jLivTRA6hJIrp/Cz5n0+ 2g8gI4Usp8eU6DTPObcC/aQc+y4+Kf+7zpF35u9AQqFuh+jeBMQFThWlffzPXDYx6HEc CUlID3Z+4JfBhchfZ9hTgz6LkTnOxybd37giZ3pM3kUDJfodDYks9NHQagiK4Xh92ZIc fj/6jSINnBf83WF+kOC/8xAuqZNPEypzH3u/Ezvw5xyABBqpuUDahapp3koXdG0eJJNe qsag== X-Gm-Message-State: AMke39lUkOJTUmiCzQm3PkWFnZNS67jqQQWHldKMbXq3MSmISd2K4aS5zZ8y50KE0wStoA== X-Received: by 10.55.114.194 with SMTP id n185mr30529680qkc.257.1489338355124; Sun, 12 Mar 2017 10:05:55 -0700 (PDT) Received: from [10.8.3.83] ([177.20.130.8]) by smtp.googlemail.com with ESMTPSA id q15sm10572375qtc.1.2017.03.12.10.05.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Mar 2017 10:05:54 -0700 (PDT) Subject: Re: FreeBSD on Pine64 experience To: freebsd-arm@freebsd.org References: <20170220124619.7f04ad6a@zeta.dino.sk> <20170224182831.76c15809@zeta.dino.sk> <20170312174353.13e1110d@zeta.dino.sk> From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: Date: Sun, 12 Mar 2017 14:05:41 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170312174353.13e1110d@zeta.dino.sk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 17:05:57 -0000 Em 12/03/2017 13:43, Milan Obuch escreveu: > [ snip ] > >>> Originally it was 12.0-CURRENT # - does anybody >>> know where this revision number is being lost? Could it be somehow >>> caused by fact my src tree was 'svn checkout'ed on another machine >>> (i386)? >>> >> Well, I can not verify my theory - I am not able to do svn checkout >> into nfs mounted directory from arm64 and armv6 systems (nfsd runs on >> i386 system). Maybe it just could not work this way... >> > This problem is solved, discussion was on hackers mailing list, > basically mount option nolockd was the clue. However, on Pine64, I am > getting now occasional errors > > pid 12421 (sh), uid 0, was killed: text file modification > > preventing me to rebuild some port or source if tree is mounted over > nfs. I remember mentioning on some mailing list it could be related to > nfs, today I decide to use HDD attached via USB for ports tree and no > error occured. So this definitely means there is something in nfs code, > probably arm64 specific as I did not see something like this on arm > system, which causes this error. > > I will try to do another full rebuild with /usr/src and /usr/obj > located on local USB attached HDD to see if there is any difference. My > svn revision is r314342 currently, there is some discrepancy now > however, as I have kernel slightly newer than world. > > Another note - I upgraded misc/mc port today, and I see something > strange. See: > > # pkg check -d -a > Checking all packages: 100% > mc is missing a required shared library: libglib-2.0.so.0 > mc is missing a required shared library: libssh2.so.1 > mc is missing a required shared library: libintl.so.8 > # ldd /usr/local/bin/mc > /usr/local/bin/mc: > libncursesw.so.8 => /lib/libncursesw.so.8 (0x4011c000) > libssh2.so.1 => /usr/local/lib/libssh2.so.1 (0x4017c000) > libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x401b1000) > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x402b1000) > libc.so.7 => /lib/libc.so.7 (0x402ca000) > libz.so.6 => /lib/libz.so.6 (0x40452000) > libssl.so.8 => /usr/lib/libssl.so.8 (0x40477000) > libcrypto.so.8 => /lib/libcrypto.so.8 (0x404ea000) > libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x406ba000) > libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x407c2000) > libthr.so.3 => /lib/libthr.so.3 (0x4084e000) > # ll /usr/local/lib/libglib-2.0.so.0 > lrwxr-xr-x 1 root wheel 23 Feb 17 20:13 /usr/local/lib/libglib-2.0.so.0@ -> libglib-2.0.so.0.4600.2 > # ll /usr/local/lib/libintl.so.8 > lrwxr-xr-x 1 root wheel 16 Feb 17 00:00 /usr/local/lib/libintl.so.8@ -> libintl.so.8.1.5 > # ll /usr/local/lib/libssh2.so.1 > lrwxr-xr-x 1 root wheel 16 Feb 17 20:28 /usr/local/lib/libssh2.so.1@ -> libssh2.so.1.0.1 > > And mc seems to be just working... rebuilding misc/mc does not change > the situation. > > Regards, > Milan > _______________________________________________ > 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" I faced this same problem about "text file modification" on a RPI3 take a look: https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015789.html []'s -Otacilio From owner-freebsd-arm@freebsd.org Sun Mar 12 17:49: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 D6FD7D09EB1 for ; Sun, 12 Mar 2017 17:49:02 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB58E1308 for ; Sun, 12 Mar 2017 17:49:02 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 1431c8c2-074c-11e7-b3c2-c9f38144898e 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 outbound2.ore.mailhop.org (Halon) with ESMTPSA id 1431c8c2-074c-11e7-b3c2-c9f38144898e; Sun, 12 Mar 2017 17:48:20 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2CHn0Zw001586; Sun, 12 Mar 2017 11:49:00 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1489340940.40576.84.camel@freebsd.org> Subject: Re: FreeBSD on Pine64 experience From: Ian Lepore To: =?ISO-8859-1?Q?Otac=EDlio?= , freebsd-arm@freebsd.org Date: Sun, 12 Mar 2017 11:49:00 -0600 In-Reply-To: References: <20170220124619.7f04ad6a@zeta.dino.sk> <20170224182831.76c15809@zeta.dino.sk> <20170312174353.13e1110d@zeta.dino.sk> 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 17:49:02 -0000 On Sun, 2017-03-12 at 14:05 -0300, Otacílio wrote: > Em 12/03/2017 13:43, Milan Obuch escreveu: > > > > [ snip ] > > > > > > > > > > > > > Originally it was 12.0-CURRENT # - does > > > > anybody > > > > know where this revision number is being lost? Could it be > > > > somehow > > > > caused by fact my src tree was 'svn checkout'ed on another > > > > machine > > > > (i386)? > > > >     > > > Well, I can not verify my theory - I am not able to do svn > > > checkout > > > into nfs mounted directory from arm64 and armv6 systems (nfsd > > > runs on > > > i386 system). Maybe it just could not work this way... > > > > > This problem is solved, discussion was on hackers mailing list, > > basically mount option nolockd was the clue. However, on Pine64, I > > am > > getting now occasional errors > > > > pid 12421 (sh), uid 0, was killed: text file modification > > > > preventing me to rebuild some port or source if tree is mounted > > over > > nfs. I remember mentioning on some mailing list it could be related > > to > > nfs, today I decide to use HDD attached via USB for ports tree and > > no > > error occured. So this definitely means there is something in nfs > > code, > > probably arm64 specific as I did not see something like this on arm > > system, which causes this error. > > > > I will try to do another full rebuild with /usr/src and /usr/obj > > located on local USB attached HDD to see if there is any > > difference. My > > svn revision is r314342 currently, there is some discrepancy now > > however, as I have kernel slightly newer than world. > > > > Another note - I upgraded misc/mc port today, and I see something > > strange. See: > > > > # pkg check -d -a > > Checking all packages: 100% > > mc is missing a required shared library: libglib-2.0.so.0 > > mc is missing a required shared library: libssh2.so.1 > > mc is missing a required shared library: libintl.so.8 > > # ldd /usr/local/bin/mc > > /usr/local/bin/mc: > >          libncursesw.so.8 => /lib/libncursesw.so.8 (0x4011c000) > >          libssh2.so.1 => /usr/local/lib/libssh2.so.1 (0x4017c000) > >          libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 > > (0x401b1000) > >          libintl.so.8 => /usr/local/lib/libintl.so.8 (0x402b1000) > >          libc.so.7 => /lib/libc.so.7 (0x402ca000) > >          libz.so.6 => /lib/libz.so.6 (0x40452000) > >          libssl.so.8 => /usr/lib/libssl.so.8 (0x40477000) > >          libcrypto.so.8 => /lib/libcrypto.so.8 (0x404ea000) > >          libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x406ba000) > >          libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x407c2000) > >          libthr.so.3 => /lib/libthr.so.3 (0x4084e000) > > # ll /usr/local/lib/libglib-2.0.so.0 > > lrwxr-xr-x  1 root  wheel  23 Feb 17 20:13 /usr/local/lib/libglib- > > 2.0.so.0@ -> libglib-2.0.so.0.4600.2 > > # ll /usr/local/lib/libintl.so.8 > > lrwxr-xr-x  1 root  wheel  16 Feb 17 00:00 > > /usr/local/lib/libintl.so.8@ -> libintl.so.8.1.5 > > # ll /usr/local/lib/libssh2.so.1 > > lrwxr-xr-x  1 root  wheel  16 Feb 17 20:28 > > /usr/local/lib/libssh2.so.1@ -> libssh2.so.1.0.1 > > > > And mc seems to be just working... rebuilding misc/mc does not > > change > > the situation. > > > > Regards, > > Milan > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.o > > rg" > I faced this same problem about "text file modification" on a RPI3 > take  > a look: > > https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015789.htm > l > > []'s > > -Otacilio > Another thread related to the same problem: https://lists.freebsd.org/pipermail/freebsd-current/2017-March/065131.html As I mentioned there just now, it may be possible to work around this with sysctl vfs.timestamp_precision, but I'm not sure exactly how. -- Ian From owner-freebsd-arm@freebsd.org Sun Mar 12 17:49: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 45EBCD09EFC for ; Sun, 12 Mar 2017 17:49:56 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03F5C1370 for ; Sun, 12 Mar 2017 17:49:56 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: by mail-vk0-x22d.google.com with SMTP id r136so26385868vke.1 for ; Sun, 12 Mar 2017 10:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=51VsSqiIAlXURzSW7oAAVAn/Haie/sj2jqp4di3qrtk=; b=Ks9d3Up4SbywlX2sh+wBhUtVxoGysBVq0UEiMBnJh8ZbnXOuTDiGv5NdDpu8ZjVf0m K41dnd7rdlOYw2Z/YL22xrpAU314wNSUTCPpmFr2CzTqVFWRQb+BcZm5/84heQBYtys6 FJ/nqZD0xuqb2GIgv35ToePAUMLNQ6Y1aiz4DKQ9OTPBOstp8JPGmTGmUE+9s3aY1L8K ck+cJlIYeXbLZTo+U8Y7Qfmnapp7I/0AXnPTTe1tN3nBclW47zkG26+YQ+KGmC68aiU3 fqzoUT9D9KZfV6k8pgtCW69Y18GMO4YZFuragQghd0M7b4zq0dM98xHvzdMNfV2yIRBL uM1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=51VsSqiIAlXURzSW7oAAVAn/Haie/sj2jqp4di3qrtk=; b=p5zrT0m9hHUYSd8kVBH2iO72EItephoroLlNyqnO5yvGouAD28pqAw3kqIsT0kRQHp y4y9m+8P5o6DvR7X4gWoDLEW8mCUW2UnHf4lYbM+scMQRgltoyQmBPfsE2P5WWn6Pr/X Z22dB9A54PMBsHWkB+hfQ8rrMMph4LLQOGShg+rWCVrFmkuwRLTnc5A9bDJ8n3Dy//M8 oHZO4IcsBG6emLof+0he94IfXRVcqOJWTzoS4AP2gUQe/YxDgPiCqVXUn+TjHElE4ZEt p47iCqfNEmCbokWpyhKSLKiUiLloBNxIyWJWjum8MC2CjTNBBp8mh9wv9lVFNVB05FF6 GKyw== X-Gm-Message-State: AMke39kzvMU/WXybi2oTdCoYjFwpHxMiscPPqY2V8DH1Qtu42tENQw8E/ktICR7IsV3hNhy+i8FyvI7jzyh0BA== X-Received: by 10.31.82.135 with SMTP id g129mr14394553vkb.88.1489340994937; Sun, 12 Mar 2017 10:49:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.123.87 with HTTP; Sun, 12 Mar 2017 10:49:14 -0700 (PDT) From: Outback Dingo Date: Sun, 12 Mar 2017 13:49:14 -0400 Message-ID: Subject: Debugging ESR - Any Ideas? To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 17:49:56 -0000 Okay list, any further ideas to debug this? U-Boot 2016.09.01-00012-g1c00e8f-dirty (Mar 01 2017 - 13:40:10 -0500) SoC: LS1043AE (0x87920010) Clock Configuration: CPU0(A53):1400 MHz CPU1(A53):1400 MHz CPU2(A53):1400 MHz CPU3(A53):1400 MHz Bus: 400 MHz DDR: 1600 MT/s FMAN: 466.667 MHz Reset Configuration Word (RCW): 00000000: 0810000e 0c000000 00000000 00000000 00000010: 45550002 00004002 e0025000 61002000 00000020: 00000000 00000000 00000000 00020f78 >> 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 MMC: block number 0x72c001 exceeds max(0x72c000) efipart_readwrite: rw=1, status=9223372036854775815 MMC: block number 0x72c001 exceeds max(0x72c000) efipart_readwrite: rw=1, status=9223372036854775815 Command line arguments: loader.efi Image base: 0xfcc58000 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Tue Feb 28 09:17:19 EST 2017 root@FISORLBSD01) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x826f08+0x43b040 syms=[0x8+0x105a20+0x8+0xbed65] / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by EFI at 0x88000000. "Synchronous Abort" handler, esr 0x86000004 ELR: ffff000000001030 LR: f4c01028 00000000f4c05000: f4c04003 00000000f4c05fd0: f4c08003 00000000f4c05fd8: f4c09003 00000000f4c05fe0: f4c0a003 00000000f4c05fe8: f4c0b003 x0 : ffff000000e2a000 x1 : 0000000004c5d91d x2 : 000000000405d11d x3 : 00000000030802e2 x4 : 00000000fffbc240 x5 : 00000000f4c01024 x6 : 00000000f4c07000 x7 : 0000000000000001 x8 : 00000000f4c06000 x9 : 00000000000f4c07 x10: 0000000000000000 x11: 0000000000000001 x12: 0000000000000003 x13: 00000000f4c06003 x14: 0000000000000398 x15: ffff000000001030 x16: 0000000000000000 x17: 0000000000000000 x18: 0000000000000000 x19: 00000000f4c00000 x20: 00000000f4c01000 x21: 0000000000000000 x22: 000000000000000d x23: 000000000000000e x24: 00000000f4c05000 x25: 00000000fcc3e29b x26: 00000000f4c04000 x27: 00000000f4c07000 x28: 00000000f4c00000 x29: 00010000f4c00000 Resetting CPU ... resetting ... U-Boot 2016.09.01-00012-g1c00e8f-dirty (Mar 01 2017 - 13:40:10 -0500) SoC: LS1043AE (0x87920010) Clock Configuration: CPU0(A53):1400 MHz CPU1(A53):1400 MHz CPU2(A53):1400 MHz CPU3(A53):1400 MHz Bus: 400 MHz DDR: 1600 MT/s FMAN: 466.667 MHz Reset Configuration Word (RCW): 00000000: 0810000e 0c000000 00000000 00000000 00000010: 45550002 00004002 e0025000 61002000 00000020: 00000000 00000000 00000000 00020f78 00000030: 00000000 04003102 00000096 00000001 Model: LS1043A FRD Board Board: LS1043AFRD, boot from NOR SERDES Reference Clocks: SD1_CLK1 = 100.00MHZ, SD1_CLK2 = 100.00MHZ I2C: ready DRAM: 8 GiB (DDR4, 32-bit, CL=11, ECC off) DDR Chip-Select Interleaving Mode: CS0+CS1 SEC0: RNG instantiated Waking secondary cores to start from fff15000 All (4) cores are up. Using SERDES1 Protocol: 17749 (0x4555) Flash: 128 MiB NAND: 0 MiB MMC: FSL_SDHC: 0 PCIe1: Root Complex x1 gen1, regs @ 0x3400000 PCI: 01:00.0 - 126f:0750 - Display controller PCIe1: Bus 00 - 01 PCIe2: Root Complex no link, regs @ 0x3500000 PCIe3: Root Complex x1 gen1, regs @ 0x3600000 PCI: 03:00.0 - 168c:003c - Network controller PCIe3: Bus 02 - 03 In: serial Out: serial Err: serial Net: Fman1: Uploading microcode version 108.4.5 FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3 [PRIME], FM1@DTSEC5, FM1@DTSEC6 Hit any key to stop autoboot: 0 From owner-freebsd-arm@freebsd.org Sun Mar 12 20:32: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 94CD2D09381 for ; Sun, 12 Mar 2017 20:32:34 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26A32185B; Sun, 12 Mar 2017 20:32:33 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sun, 12 Mar 2017 21:32:30 +0100 id 00F4BFE5.58C5B05E.0000F50C Date: Sun, 12 Mar 2017 21:32:29 +0100 From: Milan Obuch To: Ian Lepore Cc: =?ISO-8859-1?Q?Otac=EDlio?= , freebsd-arm@freebsd.org Subject: Re: FreeBSD on Pine64 experience Message-ID: <20170312213229.25ed338e@zeta.dino.sk> In-Reply-To: <1489340940.40576.84.camel@freebsd.org> References: <20170220124619.7f04ad6a@zeta.dino.sk> <20170224182831.76c15809@zeta.dino.sk> <20170312174353.13e1110d@zeta.dino.sk> <1489340940.40576.84.camel@freebsd.org> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; i386-portbld-freebsd10.3) 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 20:32:34 -0000 On Sun, 12 Mar 2017 11:49:00 -0600 Ian Lepore wrote: > On Sun, 2017-03-12 at 14:05 -0300, Otac=EDlio wrote: > > Em 12/03/2017 13:43, Milan Obuch escreveu: =20 [ snip ] > > > This problem is solved, discussion was on hackers mailing list, > > > basically mount option nolockd was the clue. However, on Pine64, I > > > am > > > getting now occasional errors > > >=20 > > > pid 12421 (sh), uid 0, was killed: text file modification > > >=20 > > > preventing me to rebuild some port or source if tree is mounted > > > over > > > nfs. I remember mentioning on some mailing list it could be > > > related to > > > nfs, today I decide to use HDD attached via USB for ports tree and > > > no > > > error occured. So this definitely means there is something in nfs > > > code, > > > probably arm64 specific as I did not see something like this on > > > arm system, which causes this error. [ snip ] > > I faced this same problem about "text file modification" on a RPI3 > > take=A0 > > a look: > >=20 > > https://lists.freebsd.org/pipermail/freebsd-arm/2017-March/015789.htm > > l > >=20 > > []'s > >=20 > > -Otacilio > > =20 >=20 > Another thread related to the same problem: >=20 > https://lists.freebsd.org/pipermail/freebsd-current/2017-March/065131.html >=20 > As I mentioned there just now, it may be possible to work around this > with sysctl vfs.timestamp_precision, but I'm not sure exactly how. >=20 > -- Ian >=20 Thanks, setting 'sysctl vfs.timestamp_precision=3D0' seems to solve this issue for me. At least I was able to rebuild misc/mc port with no error messages, just pkg still says # pkg check -d -a Checking all packages: 100% mc is missing a required shared library: libglib-2.0.so.0 mc is missing a required shared library: libssh2.so.1 mc is missing a required shared library: libintl.so.8 I am going to try world rebuild with this setup. regards, Milan From owner-freebsd-arm@freebsd.org Sun Mar 12 21:39:00 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 195DCD099AF for ; Sun, 12 Mar 2017 21:39:00 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A65441AE3 for ; Sun, 12 Mar 2017 21:38:59 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489354737; l=3222; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=BtJ3s1m9BCpS/fh5+ttmQjhhl1AWEiqwXEU5dKQWfy4=; b=ytQAlbIAI/v/vcutdmWtMi0OdJA8s4eSEfHfnqjp//BfaSoBszPgE1RP5lhOHgDTPz rdBD0RX5gMlPiw0yLsXwTmcWGaCV5dwFn6e0plB/w5K9qWpTwJ0JDOTOxfj56xrt3PFz wUtcWoLJEbtAlnWsO0m+7RZkPF/XqXIDQmcD4= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0i99HgKKA= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b584.virtua.com.br [187.2.181.132]) by smtp.strato.de (RZmta 40.1 DYNA|AUTH) with ESMTPSA id 601fc8t2CLctMQs (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sun, 12 Mar 2017 22:38:55 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id C412B7506DAD for ; Sun, 12 Mar 2017 18:38:52 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Enabling ADC on a Beaglebone Black running FreeBSD 12.0-CURRENT (BEAGLEBONE) From: "Dr. Rolf Jansen" In-Reply-To: <0C4DCBB9-2642-4B0F-B15B-4139D5D8B249@obsigna.com> Date: Sun, 12 Mar 2017 18:38:51 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <271AFD8F-BD2C-445C-AB95-D7D07593E487@obsigna.com> References: <0C4DCBB9-2642-4B0F-B15B-4139D5D8B249@obsigna.com> To: freebsd-arm@FreeBSD.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 21:39:00 -0000 Am 12.03.2017 um 10:57 schrieb Dr. Rolf Jansen : > I experience problems to enable the ADC line of my BBB. >=20 > Apparently, in FreeBSD 10, the ADC lines would have been enabled by a = sysctl call: >=20 > sysctl dev.ti_adc.0.ain.0.enable=3D1 >=20 >=20 > On FreeBSD 12, this gives: >=20 > sysctl: unknown oid 'dev.ti_adc.0.ain.0.enable' >=20 >=20 > I thought, perhaps the driver has not been loaded into the kernel, = but: >=20 > kldload ti_adc > .... > kldload: can't load ti_adc: module already loaded or in kernel >=20 >=20 > Question: >=20 > What do I need to get the ADC working with FreeBSD 12? I am answering my own question. The ADC is disabled in the respective device tree file = am335x-boneblack.dtb. In order to enable the it, I did: 1. decompile the device tree blob (.dtb) into a device tree source file = (.dts): cd /boot/dtb dtc -I dtb -O dts am335x-boneblack.dtb > am335x-boneblack.dts 2. edit the .dts file, and change the entry for tscadc to the following: tscadc@44e0d000 { compatible =3D "ti,am3359-tscadc"; reg =3D <0x44e0d000 0x1000>; interrupt-parent =3D <0x1>; interrupts =3D <0x10>; ti,hwmods =3D "adc_tsc"; status =3D "okay"; dmas =3D <0x29 0x35 0x0 0x29 0x39 0x0>; dma-names =3D "fifo0", "fifo1"; tsc { compatible =3D "ti,am3359-tsc"; }; adc { #io-channel-cells =3D <0x1>; compatible =3D "ti,am3359-adc"; ti,adc-channels =3D <0 1 2 3 4 5 6>; }; }; ActualLy I changed the status from "disabled" to "okay" and I added the = ti,adc-channels descriptor to the adc section. 3. save the original DTB and compile the DTS: mv am335x-boneblack.dtb am335x-boneblack.dtb.orig dtc -O dtb -o am335x-boneblack.dtb -b 0 am335x-boneblack.dts 4. restart 5. check it: sysctl dev.ti_adc .... dev.ti_adc.0.ain.6.input: 0 dev.ti_adc.0.ain.6.samples_avg: 0 dev.ti_adc.0.ain.6.open_delay: 0 dev.ti_adc.0.ain.6.enable: 0 dev.ti_adc.0.ain.5.input: 0 dev.ti_adc.0.ain.5.samples_avg: 0 dev.ti_adc.0.ain.5.open_delay: 0 dev.ti_adc.0.ain.5.enable: 0 dev.ti_adc.0.ain.4.input: 0 dev.ti_adc.0.ain.4.samples_avg: 0 dev.ti_adc.0.ain.4.open_delay: 0 dev.ti_adc.0.ain.4.enable: 0 dev.ti_adc.0.ain.3.input: 0 dev.ti_adc.0.ain.3.samples_avg: 0 dev.ti_adc.0.ain.3.open_delay: 0 dev.ti_adc.0.ain.3.enable: 0 dev.ti_adc.0.ain.2.input: 0 dev.ti_adc.0.ain.2.samples_avg: 0 dev.ti_adc.0.ain.2.open_delay: 0 dev.ti_adc.0.ain.2.enable: 0 dev.ti_adc.0.ain.1.input: 0 dev.ti_adc.0.ain.1.samples_avg: 0 dev.ti_adc.0.ain.1.open_delay: 0 dev.ti_adc.0.ain.1.enable: 0 dev.ti_adc.0.ain.0.input: 3071 dev.ti_adc.0.ain.0.samples_avg: 0 dev.ti_adc.0.ain.0.open_delay: 0 dev.ti_adc.0.ain.0.enable: 1 dev.ti_adc.0.clockdiv: 2400 dev.ti_adc.0.%parent: simplebus0 dev.ti_adc.0.%pnpinfo: name=3Dtscadc@44e0d000 compat=3Dti,am3359-tscadc= dev.ti_adc.0.%location:=20 dev.ti_adc.0.%driver: ti_adc dev.ti_adc.0.%desc: TI ADC controller dev.ti_adc.%parent:=20 I can enable the ADC channels, and when connecting a 1002 mV DC source = to AIN0 the reading was 2279, which is perfectly in line with = 1002*4095/1800 =3D 2279.55. Best regards Rolf= From owner-freebsd-arm@freebsd.org Sun Mar 12 23:18: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 7AA78D0AE00 for ; Sun, 12 Mar 2017 23:18:10 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 505BA1004 for ; Sun, 12 Mar 2017 23:18:09 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cnCMh-0004tv-JV; Sun, 12 Mar 2017 15:53:28 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v2CMrRkJ018842; Sun, 12 Mar 2017 15:53:27 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sun, 12 Mar 2017 15:53:26 -0700 From: Oleksandr Tymoshenko To: Outback Dingo Cc: freebsd-arm@freebsd.org Subject: Re: Debugging ESR - Any Ideas? Message-ID: <20170312225326.GA18784@bluezbox.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Outback Dingo (outbackdingo@gmail.com) wrote: > Okay list, any further ideas to debug this? > > U-Boot 2016.09.01-00012-g1c00e8f-dirty (Mar 01 2017 - 13:40:10 -0500) > > SoC: LS1043AE (0x87920010) > Clock Configuration: > CPU0(A53):1400 MHz CPU1(A53):1400 MHz CPU2(A53):1400 MHz > CPU3(A53):1400 MHz > Bus: 400 MHz DDR: 1600 MT/s FMAN: 466.667 MHz > Reset Configuration Word (RCW): > 00000000: 0810000e 0c000000 00000000 00000000 > 00000010: 45550002 00004002 e0025000 61002000 > 00000020: 00000000 00000000 00000000 00020f78 > > >> 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 > MMC: block number 0x72c001 exceeds max(0x72c000) > efipart_readwrite: rw=1, status=9223372036854775815 > MMC: block number 0x72c001 exceeds max(0x72c000) > efipart_readwrite: rw=1, status=9223372036854775815 > Command line arguments: loader.efi > Image base: 0xfcc58000 > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) > > FreeBSD/arm64 EFI loader, Revision 1.1 > (Tue Feb 28 09:17:19 EST 2017 root@FISORLBSD01) > EFI boot environment > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x826f08+0x43b040 syms=[0x8+0x105a20+0x8+0xbed65] > / > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by EFI at 0x88000000. > "Synchronous Abort" handler, esr 0x86000004 > ELR: ffff000000001030 > LR: f4c01028 > 00000000f4c05000: f4c04003 > 00000000f4c05fd0: f4c08003 > 00000000f4c05fd8: f4c09003 > 00000000f4c05fe0: f4c0a003 > 00000000f4c05fe8: f4c0b003 > x0 : ffff000000e2a000 x1 : 0000000004c5d91d > x2 : 000000000405d11d x3 : 00000000030802e2 > x4 : 00000000fffbc240 x5 : 00000000f4c01024 > x6 : 00000000f4c07000 x7 : 0000000000000001 > x8 : 00000000f4c06000 x9 : 00000000000f4c07 > x10: 0000000000000000 x11: 0000000000000001 > x12: 0000000000000003 x13: 00000000f4c06003 > x14: 0000000000000398 x15: ffff000000001030 > x16: [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 23:18:10 -0000 Outback Dingo (outbackdingo@gmail.com) wrote: > Okay list, any further ideas to debug this? > > U-Boot 2016.09.01-00012-g1c00e8f-dirty (Mar 01 2017 - 13:40:10 -0500) > > SoC: LS1043AE (0x87920010) > Clock Configuration: > CPU0(A53):1400 MHz CPU1(A53):1400 MHz CPU2(A53):1400 MHz > CPU3(A53):1400 MHz > Bus: 400 MHz DDR: 1600 MT/s FMAN: 466.667 MHz > Reset Configuration Word (RCW): > 00000000: 0810000e 0c000000 00000000 00000000 > 00000010: 45550002 00004002 e0025000 61002000 > 00000020: 00000000 00000000 00000000 00020f78 > > >> 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 > MMC: block number 0x72c001 exceeds max(0x72c000) > efipart_readwrite: rw=1, status=9223372036854775815 > MMC: block number 0x72c001 exceeds max(0x72c000) > efipart_readwrite: rw=1, status=9223372036854775815 > Command line arguments: loader.efi > Image base: 0xfcc58000 > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) > > FreeBSD/arm64 EFI loader, Revision 1.1 > (Tue Feb 28 09:17:19 EST 2017 root@FISORLBSD01) > EFI boot environment > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x826f08+0x43b040 syms=[0x8+0x105a20+0x8+0xbed65] > / > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by EFI at 0x88000000. > "Synchronous Abort" handler, esr 0x86000004 > ELR: ffff000000001030 > LR: f4c01028 > 00000000f4c05000: f4c04003 > 00000000f4c05fd0: f4c08003 > 00000000f4c05fd8: f4c09003 > 00000000f4c05fe0: f4c0a003 > 00000000f4c05fe8: f4c0b003 > x0 : ffff000000e2a000 x1 : 0000000004c5d91d > x2 : 000000000405d11d x3 : 00000000030802e2 > x4 : 00000000fffbc240 x5 : 00000000f4c01024 > x6 : 00000000f4c07000 x7 : 0000000000000001 > x8 : 00000000f4c06000 x9 : 00000000000f4c07 > x10: 0000000000000000 x11: 0000000000000001 > x12: 0000000000000003 x13: 00000000f4c06003 > x14: 0000000000000398 x15: ffff000000001030 > x16: 0000000000000000 x17: 0000000000000000 > x18: 0000000000000000 x19: 00000000f4c00000 > x20: 00000000f4c01000 x21: 0000000000000000 > x22: 000000000000000d x23: 000000000000000e > x24: 00000000f4c05000 x25: 00000000fcc3e29b > x26: 00000000f4c04000 x27: 00000000f4c07000 > x28: 00000000f4c00000 x29: 00010000f4c00000 > > Resetting CPU ... > > resetting ... Some additional info/analysis: ELR value is virtdone. So what happens must be as follows: loader.efi works fine, it enumerates devices, loads kernel and passes control to the kernel. No problem there. Kernel also runs fine until it enables MMU and switches to virtual addresses. Once it jumps to VA, exception is raised. Which means MMU was not initialized properly. U-Boot has D-cache ON, I tried disabling dcache using "dcache off" but after this loader.efi fails with following message: Probing 4 block devices...."Synchronous Abort" handler, esr 0x96000021 ELR: fedc062c LR: fedc35d8 00000000fccd9000: deadbeefdeadbeef ... 00000000fccd9ff8: deadbeefdeadbeef etc.. Kernel is loaded at physical address 0xf4c00000 so alignment is correct. U-Boot version is 2016.11 with vendor patches. -- gonzo From owner-freebsd-arm@freebsd.org Mon Mar 13 13:17: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 1DDEAD080A7 for ; Mon, 13 Mar 2017 13:17:27 +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 E78371C91 for ; Mon, 13 Mar 2017 13:17: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 v2DDHQPr094893 for ; Mon, 13 Mar 2017 13:17:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 217753] lld [llvm 4.0.0] Linker won't link on aarch64 (Error: Failed to open a.out) Date: Mon, 13 Mar 2017 13:17:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: wolfgang.meyer@hob.de 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 cc 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 13:17:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217753 Bug ID: 217753 Summary: lld [llvm 4.0.0] Linker won't link on aarch64 (Error: Failed to open a.out) Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: wolfgang.meyer@hob.de CC: freebsd-toolchain@FreeBSD.org Created attachment 180774 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D180774&action= =3Dedit Output for verbose compilation/linking (cc -v -Wl,--verbose conftest.c) When trying to compile C sources on 12-CURRENT (aarch64) with the newly integrated LLVM 4.0 toolchain the compilation fails with ld giving an error= on failing to open the executable file to be produced by the compilation. An e= mpty file with the executable name and a .tmpXXXXXXX suffix is produced by the linking process. This has been observed using poudriere jails with a FreeBSD 12-CURRENT for aarch64 after integration of the llvm 4.0 toolchain (tested with base r3145= 64 and base r315016) running on an amd64 host using qemu-user-static for arm64 execution. How to reproduce: Build poudriere jail for HEAD and aarch64 architecture. Enter jail and try to compile typical configure test source (referred to as conftest.c): int main() { ; return 0; } Compilation: >cc conftest.c Output: /usr/bin/ld: error: failed to open a.out: Unknown error -1 cc: error: linker command failed with exit code 1 (use -v to see invocation) An empty a.out.tmpXXXXXXX is produced. This happens with qemu-aarch64-static 2.6.90.g20160728_1 ( ports r424575 ). With qemu-aarch64-static 2.8.50.g20170307 ( ports r435636 ) I get a qemu er= ror: /usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-c0989c8/tcg/tcg.c:= 2017: tcg fatal error cc: error: unable to execute command: Abort trap (core dumped) cc: error: linker command failed due to signal (use -v to see invocation) Using lld 3.9.0 on aarch64 poudriere jails works fine with either qemu-emul= ated execution. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Mar 13 20:49: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 351E5D0A92C for ; Mon, 13 Mar 2017 20:49:53 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 1935C1E9F for ; Mon, 13 Mar 2017 20:49:52 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cnWud-0007JG-Ud for freebsd-arm@freebsd.org; Mon, 13 Mar 2017 13:49:52 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v2DKnpC2028101 for freebsd-arm@freebsd.org; Mon, 13 Mar 2017 13:49:51 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Mon, 13 Mar 2017 13:49:51 -0700 From: Oleksandr Tymoshenko To: freebsd-arm@freebsd.org Subject: Re: Debugging ESR - Any Ideas? Message-ID: <20170313204951.GA28076@bluezbox.com> References: <20170312225326.GA18784@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170312225326.GA18784@bluezbox.com> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Oleksandr Tymoshenko (gonzo@bluezbox.com) wrote: > Outback Dingo (outbackdingo@gmail.com) wrote: > > Okay list, any further ideas to debug this? .. skipped .. > Kernel is loaded at physical address 0xf4c00000 so alignment is correct. > U-Boot version is 2016.11 with vendor patches. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: denx.de] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:49:53 -0000 Oleksandr Tymoshenko (gonzo@bluezbox.com) wrote: > Outback Dingo (outbackdingo@gmail.com) wrote: > > Okay list, any further ideas to debug this? .. skipped .. > Kernel is loaded at physical address 0xf4c00000 so alignment is correct. > U-Boot version is 2016.11 with vendor patches. Applying this patch to U-Boot 2016.11 fixed the crash: http://git.denx.de/?p=u-boot.git;a=blobdiff;f=cmd/bootefi.c;h=ca411702baed83b49c31186926d57bb963f8b2bc;hp=ae1b713197cbc91a06d6b072660a30941937614f;hb=69bd459d343fe1e5a68a6f187d8c99c78c6fc6ce;hpb=58ad86288fd32f1f969ac654f2074c090f0abe32 -- gonzo From owner-freebsd-arm@freebsd.org Mon Mar 13 21:01:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7ADCAD0AD26 for ; Mon, 13 Mar 2017 21:01:01 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-vk0-x242.google.com (mail-vk0-x242.google.com [IPv6:2607:f8b0:400c:c05::242]) (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 36023193F for ; Mon, 13 Mar 2017 21:01:01 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: by mail-vk0-x242.google.com with SMTP id t8so5913920vke.0 for ; Mon, 13 Mar 2017 14:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tzRxZHJDJSdRbeMRB3Ra7y7rR2QHEcsYch6FJ+WfQsE=; b=PYOTUmG6eTk1hEBnndzzYozijhDPHAhZOG7qLr4lRgUjYnA5ytPzLkmqhG/6J+B/3u TZflUmmC6F6LqPsJ+fPfCk4rNRtqdCCinJ4nLZVx1Cwk2F6QdJDs6rBx5WhZDP4kLFII PTrWwyPLev8Cm4BeFC+RyonNCYM6lfzX9y6OArj6a4FvCOX5cPjPpCdJMKgIgKSY9YnJ SPtTt3RD3G6jcZ8iIzt6pTD9jk41kK/jglePnelu2n6vmpfB+wSlSOkkP6e2lYyTjx/i 5LgmzXt9J4CFCTJKOgCUOyLaBg1bqsj9FIOi0nNeQpmaxN+OYYoxN/Dp+34Lip0pNi4q RRKw== 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=tzRxZHJDJSdRbeMRB3Ra7y7rR2QHEcsYch6FJ+WfQsE=; b=FNJqOjptfhpqCmoWZzAjpPZToCAEoul6fAvNz5X+Nm+C1eI3vaOEpUXO35HHsNW5lm BLvpBTeZqWjC6V8gmCskrYRMefB4CaC9f81zjvDvQjTLSvbP9BTyS1EHjmGdeAzuja8f sZ4hUBPl2751glnfQEiShTaJLJoA8RSA5fQnZ9B95HfxShiCTDsX3e4mRgL1xly9o8Sr yHFiyscawGdptitexpgTSXXP6MdJILrKmZBMHqW+C6Q2vCcUXLE61JF5cc8jcAVPO0Bp BzBOKASKxoF0fbk6YauQ32jqemO3giY2dopc3WaOr2uzV5m7wsEuq9yeHq6aNc7I3Mfi +Hjw== X-Gm-Message-State: AMke39lUyvXF3l/TijGk8BoIBf1zCUZR0r0AgeCM8I/xZLe7dBebwNVB2LzJ0hwbuE9PRMe2TBVno7rFTjaljg== X-Received: by 10.31.125.12 with SMTP id y12mr15935600vkc.161.1489438860270; Mon, 13 Mar 2017 14:01:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.123.87 with HTTP; Mon, 13 Mar 2017 14:00:19 -0700 (PDT) In-Reply-To: <20170313204951.GA28076@bluezbox.com> References: <20170312225326.GA18784@bluezbox.com> <20170313204951.GA28076@bluezbox.com> From: Outback Dingo Date: Mon, 13 Mar 2017 17:00:19 -0400 Message-ID: Subject: Re: Debugging ESR - Any Ideas? To: Oleksandr Tymoshenko Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:01:01 -0000 On Mon, Mar 13, 2017 at 4:49 PM, Oleksandr Tymoshenko wrote: > Oleksandr Tymoshenko (gonzo@bluezbox.com) wrote: >> Outback Dingo (outbackdingo@gmail.com) wrote: >> > Okay list, any further ideas to debug this? > .. skipped .. >> Kernel is loaded at physical address 0xf4c00000 so alignment is correct. >> U-Boot version is 2016.11 with vendor patches. > > Applying this patch to U-Boot 2016.11 fixed the crash: > http://git.denx.de/?p=u-boot.git;a=blobdiff;f=cmd/bootefi.c;h=ca411702baed83b49c31186926d57bb963f8b2bc;hp=ae1b713197cbc91a06d6b072660a30941937614f;hb=69bd459d343fe1e5a68a6f187d8c99c78c6fc6ce;hpb=58ad86288fd32f1f969ac654f2074c090f0abe32 > > -- > gonzo Terrific find... simple u-boot patch and its booting, at least to where it wants to mount a filesystem down to devices, and drivers > _______________________________________________ > 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 Mar 14 06:52: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 E3DFED0BE10 for ; Tue, 14 Mar 2017 06:52:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-183.reflexion.net [208.70.211.183]) (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 A4E841D6B for ; Tue, 14 Mar 2017 06:52:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18313 invoked from network); 14 Mar 2017 06:52:43 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Mar 2017 06:52:43 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 02:52:43 -0400 (EDT) Received: (qmail 18463 invoked from network); 14 Mar 2017 06:52:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Mar 2017 06:52:43 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 80BBBEC8662; Mon, 13 Mar 2017 23:52:42 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: amd64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) Message-Id: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> Date: Mon, 13 Mar 2017 23:52:41 -0700 To: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 06:52:51 -0000 I'm still at a loss about how to figure out what stages are messed up. (Memory coherency? Some memory not swapped out? Bad data swapped out? Wrong data swapped in?) But at least I've found a much smaller/simpler example to demonstrate some problem with in my Pine64+_ 2GB context. The Pine64+ 2GB is the only amd64 context that I have access to. The following program fails its check for data having its expected byte pattern in dynamically allocated memory after a fork/swap-out/swap-in sequence. I'll note that the program sleeps for 60s after forking to give time to do something else to cause the parent and child processes to swap out (RES=3D0 as seen in top). Note the source code line: // test_check(); // Adding this line prevents failure. It seem that accessing the region contents before forking and swapping avoids the problem. But there is a problem if the region was only written-to before the fork/swap. Another point is the size of the region matters: <=3D 14K Bytes fails and > 14K Bytes works for as much has I have tested. # more swap_testing.c // swap_testing.c // Built via (c++ was clang++ 4.0 in my case): // // cc -g -std=3Dc11 -Wpedantic swap_testing.c // -O0 and -O2 also gets the problem. #include // for fork(), sleep(.) #include // for pid_t #include // for wait(.) extern void test_setup(void); // Sets up the memory byte pattern. extern void test_check(void); // Tests the memory byte pattern. int main(void) { test_setup(); // test_check(); // Adding this line prevents failure. pid_t pid =3D fork(); int wait_status =3D 0;; if (0 // for bool, true, false #include // for size_t, NULL #include // for malloc(.), free(.) #include // for raise(.), SIGABRT #define region_size (14u*1024u) // Bad dyn_region pattern, parent and child // processes: // 256u, 4u*1024u, 8u*1024u, 9u*1024u, // 12u*1024u, 14u*1024u // Works: // 14u*1024u+1u, 15u*1024u, 16u*1024u, // 32u*1024u, 256u*1024u*1024u typedef volatile unsigned char value_type; struct region_struct { value_type array[region_size]; }; typedef struct region_struct region; static region gbl_region; static region * volatile dyn_region =3D NULL; static value_type value(size_t v) { return (value_type)v; } void test_setup(void) { dyn_region =3D malloc(sizeof(region)); if (!dyn_region) raise(SIGABRT); for(size_t i=3D0u; i 103 if (dyn_failed) raise(SIGABRT); // lldb reports this line = for the __raise call. 104 // when it fails (both = parent and child processes). 105 } (lldb) print dyn_pos (size_t) $0 =3D 2 (That is one after the failure position.) (lldb) print dyn_region (region *volatile) $3 =3D 0x0000000040616000 (lldb) print *dyn_region (region) $1 =3D { array =3D { [0] =3D '\0' [1] =3D '\0' [2] =3D '\0' . . . (all '\0' bytes) . . . [251] =3D '\0' [252] =3D '\0' [253] =3D '\0' [254] =3D '\0' [255] =3D '\0' ... } } (lldb) print gbl_region (region) $2 =3D { array =3D { [0] =3D '\0' [1] =3D '\x01' [2] =3D '\x02' . . . [251] =3D '\xfb' [252] =3D '\xfc' [253] =3D '\xfd' [254] =3D '\xfe' [255] =3D '\xff' ... } } (lldb) disass -n main a.out`main: 0x2022c <+0>: sub sp, sp, #0x30 ; =3D0x30=20 0x20230 <+4>: stp x29, x30, [sp, #0x20] 0x20234 <+8>: add x29, sp, #0x20 ; =3D0x20=20 0x20238 <+12>: stur wzr, [x29, #-0x4] 0x2023c <+16>: bl 0x202b0 ; test_setup at = swap_testing.c:74 0x20240 <+20>: bl 0x20580 ; symbol stub for: = fork 0x20244 <+24>: mov w8, wzr 0x20248 <+28>: stur w0, [x29, #-0x8] 0x2024c <+32>: stur wzr, [x29, #-0xc] 0x20250 <+36>: ldur w0, [x29, #-0x8] 0x20254 <+40>: cmp w8, w0 0x20258 <+44>: b.ge 0x20268 ; <+60> at = swap_testing.c 0x2025c <+48>: sub x0, x29, #0xc ; =3D0xc=20 0x20260 <+52>: bl 0x20590 ; symbol stub for: = wait 0x20264 <+56>: str w0, [sp, #0x10] 0x20268 <+60>: mov w8, #-0x1 0x2026c <+64>: ldur w9, [x29, #-0xc] 0x20270 <+68>: cmp w8, w9 0x20274 <+72>: b.eq 0x202a0 ; <+116> at = swap_testing.c:44 0x20278 <+76>: mov w8, wzr 0x2027c <+80>: ldur w9, [x29, #-0x8] 0x20280 <+84>: cmp w8, w9 0x20284 <+88>: b.gt 0x202a0 ; <+116> at = swap_testing.c:44 0x20288 <+92>: ldur w8, [x29, #-0x8] 0x2028c <+96>: cbnz w8, 0x2029c ; <+112> at = swap_testing.c:42 0x20290 <+100>: orr w0, wzr, #0x3c 0x20294 <+104>: bl 0x205a0 ; symbol stub for: = sleep 0x20298 <+108>: str w0, [sp, #0xc] 0x2029c <+112>: bl 0x20348 ; test_check at = swap_testing.c:89 0x202a0 <+116>: ldur w0, [x29, #-0x4] 0x202a4 <+120>: ldp x29, x30, [sp, #0x20] 0x202a8 <+124>: add sp, sp, #0x30 ; =3D0x30=20 0x202ac <+128>: ret =20 (lldb) disass -n value a.out`value: 0x204cc <+0>: sub sp, sp, #0x10 ; =3D0x10=20 0x204d0 <+4>: str x0, [sp, #0x8] 0x204d4 <+8>: ldrb w8, [sp, #0x8] 0x204d8 <+12>: mov w1, w8 0x204dc <+16>: mov w0, w8 0x204e0 <+20>: str w1, [sp, #0x4] 0x204e4 <+24>: add sp, sp, #0x10 ; =3D0x10=20 0x204e8 <+28>: ret =20 (lldb) disass -n test_setup a.out`test_setup: 0x202b0 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 0x202b4 <+4>: stp x29, x30, [sp, #0x10] 0x202b8 <+8>: add x29, sp, #0x10 ; =3D0x10=20 0x202bc <+12>: orr x0, xzr, #0x3800 0x202c0 <+16>: bl 0x205b0 ; symbol stub for: = malloc 0x202c4 <+20>: adrp x30, 48 0x202c8 <+24>: add x30, x30, #0x0 ; =3D0x0=20 0x202cc <+28>: str x0, [x30] 0x202d0 <+32>: ldr x0, [x30] 0x202d4 <+36>: cbnz x0, 0x202e4 ; <+52> at = swap_testing.c:78 0x202d8 <+40>: orr w0, wzr, #0x6 0x202dc <+44>: bl 0x205c0 ; symbol stub for: = raise 0x202e0 <+48>: str w0, [sp, #0x4] 0x202e4 <+52>: str xzr, [sp, #0x8] 0x202e8 <+56>: orr x8, xzr, #0x3800 0x202ec <+60>: ldr x9, [sp, #0x8] 0x202f0 <+64>: cmp x9, x8 0x202f4 <+68>: b.hs 0x2033c ; <+140> at = swap_testing.c:81 0x202f8 <+72>: ldr x0, [sp, #0x8] 0x202fc <+76>: bl 0x204cc ; value at = swap_testing.c:72 0x20300 <+80>: adrp x30, 48 0x20304 <+84>: add x30, x30, #0x0 ; =3D0x0=20 0x20308 <+88>: adrp x8, 48 0x2030c <+92>: add x8, x8, #0x8 ; =3D0x8=20 0x20310 <+96>: ldr x9, [sp, #0x8] 0x20314 <+100>: add x8, x8, x9 0x20318 <+104>: strb w0, [x8] 0x2031c <+108>: ldr x8, [x30] 0x20320 <+112>: ldr x9, [sp, #0x8] 0x20324 <+116>: add x8, x8, x9 0x20328 <+120>: strb w0, [x8] 0x2032c <+124>: ldr x8, [sp, #0x8] 0x20330 <+128>: add x8, x8, #0x1 ; =3D0x1=20 0x20334 <+132>: str x8, [sp, #0x8] 0x20338 <+136>: b 0x202e8 ; <+56> at = swap_testing.c 0x2033c <+140>: ldp x29, x30, [sp, #0x10] 0x20340 <+144>: add sp, sp, #0x20 ; =3D0x20=20 0x20344 <+148>: ret =20 (lldb) disass -n test_check a.out`test_check: 0x20348 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 0x2034c <+4>: stp x29, x30, [sp, #0x10] 0x20350 <+8>: add x29, sp, #0x10 ; =3D0x10=20 0x20354 <+12>: b 0x20358 ; <+16> at = swap_testing.c 0x20358 <+16>: mov w8, wzr 0x2035c <+20>: adrp x9, 51 0x20360 <+24>: add x9, x9, #0x808 ; =3D0x808=20 0x20364 <+28>: ldrb w10, [x9] 0x20368 <+32>: stur w8, [x29, #-0x4] 0x2036c <+36>: tbnz w10, #0x0, 0x2038c ; <+68> at = swap_testing.c 0x20370 <+40>: orr x8, xzr, #0x3800 0x20374 <+44>: adrp x9, 51 0x20378 <+48>: add x9, x9, #0x810 ; =3D0x810=20 0x2037c <+52>: ldr x9, [x9] 0x20380 <+56>: cmp x9, x8 0x20384 <+60>: cset w10, lo 0x20388 <+64>: stur w10, [x29, #-0x4] 0x2038c <+68>: ldur w8, [x29, #-0x4] 0x20390 <+72>: tbz w8, #0x0, 0x203ec ; <+164> at = swap_testing.c:95 0x20394 <+76>: adrp x8, 51 0x20398 <+80>: add x8, x8, #0x810 ; =3D0x810=20 0x2039c <+84>: ldr x0, [x8] 0x203a0 <+88>: bl 0x204cc ; value at = swap_testing.c:72 0x203a4 <+92>: adrp x8, 51 0x203a8 <+96>: add x8, x8, #0x810 ; =3D0x810=20 0x203ac <+100>: adrp x30, 51 0x203b0 <+104>: add x30, x30, #0x808 ; =3D0x808=20 0x203b4 <+108>: adrp x9, 48 0x203b8 <+112>: add x9, x9, #0x8 ; =3D0x8=20 0x203bc <+116>: uxtb w0, w0 0x203c0 <+120>: ldr x10, [x8] 0x203c4 <+124>: add x9, x9, x10 0x203c8 <+128>: ldrb w11, [x9] 0x203cc <+132>: cmp w0, w11 0x203d0 <+136>: cset w11, ne 0x203d4 <+140>: and w11, w11, #0x1 0x203d8 <+144>: strb w11, [x30] 0x203dc <+148>: ldr x9, [x8] 0x203e0 <+152>: add x9, x9, #0x1 ; =3D0x1=20 0x203e4 <+156>: str x9, [x8] 0x203e8 <+160>: b 0x20358 ; <+16> at = swap_testing.c 0x203ec <+164>: b 0x203f0 ; <+168> at = swap_testing.c 0x203f0 <+168>: mov w8, wzr 0x203f4 <+172>: adrp x9, 51 0x203f8 <+176>: add x9, x9, #0x818 ; =3D0x818=20 0x203fc <+180>: ldrb w10, [x9] 0x20400 <+184>: str w8, [sp, #0x8] 0x20404 <+188>: tbnz w10, #0x0, 0x20424 ; <+220> at = swap_testing.c 0x20408 <+192>: orr x8, xzr, #0x3800 0x2040c <+196>: adrp x9, 51 0x20410 <+200>: add x9, x9, #0x820 ; =3D0x820=20 0x20414 <+204>: ldr x9, [x9] 0x20418 <+208>: cmp x9, x8 0x2041c <+212>: cset w10, lo 0x20420 <+216>: str w10, [sp, #0x8] 0x20424 <+220>: ldr w8, [sp, #0x8] 0x20428 <+224>: tbz w8, #0x0, 0x20488 ; <+320> at = swap_testing.c 0x2042c <+228>: adrp x8, 51 0x20430 <+232>: add x8, x8, #0x820 ; =3D0x820=20 0x20434 <+236>: ldr x0, [x8] 0x20438 <+240>: bl 0x204cc ; value at = swap_testing.c:72 0x2043c <+244>: adrp x8, 51 0x20440 <+248>: add x8, x8, #0x820 ; =3D0x820=20 0x20444 <+252>: adrp x30, 51 0x20448 <+256>: add x30, x30, #0x818 ; =3D0x818=20 0x2044c <+260>: adrp x9, 48 0x20450 <+264>: add x9, x9, #0x0 ; =3D0x0=20 0x20454 <+268>: uxtb w0, w0 0x20458 <+272>: ldr x9, [x9] 0x2045c <+276>: ldr x10, [x8] 0x20460 <+280>: add x9, x9, x10 0x20464 <+284>: ldrb w11, [x9] 0x20468 <+288>: cmp w0, w11 0x2046c <+292>: cset w11, ne 0x20470 <+296>: and w11, w11, #0x1 0x20474 <+300>: strb w11, [x30] 0x20478 <+304>: ldr x9, [x8] 0x2047c <+308>: add x9, x9, #0x1 ; =3D0x1=20 0x20480 <+312>: str x9, [x8] 0x20484 <+316>: b 0x203f0 ; <+168> at = swap_testing.c 0x20488 <+320>: adrp x8, 51 0x2048c <+324>: add x8, x8, #0x808 ; =3D0x808=20 0x20490 <+328>: ldrb w9, [x8] 0x20494 <+332>: tbz w9, #0x0, 0x204a4 ; <+348> at = swap_testing.c 0x20498 <+336>: orr w0, wzr, #0x6 0x2049c <+340>: bl 0x205c0 ; symbol stub for: = raise 0x204a0 <+344>: str w0, [sp, #0x4] 0x204a4 <+348>: adrp x8, 51 0x204a8 <+352>: add x8, x8, #0x818 ; =3D0x818=20 0x204ac <+356>: ldrb w9, [x8] 0x204b0 <+360>: tbz w9, #0x0, 0x204c0 ; <+376> at = swap_testing.c:105 0x204b4 <+364>: orr w0, wzr, #0x6 0x204b8 <+368>: bl 0x205c0 ; symbol stub for: = raise -> 0x204bc <+372>: str w0, [sp] 0x204c0 <+376>: ldp x29, x30, [sp, #0x10] 0x204c4 <+380>: add sp, sp, #0x20 ; =3D0x20=20 0x204c8 <+384>: ret =20 # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r314638M arm64 = aarch64 1200023 1200023 buildworld buildlkernel did not have MALLOC_PRODUCTION=3D defined. The = kernel is a non-debug kernel. (Previous to these experiments my other corruption = examples were not caught by a debug kernel. I'm not hopeful that this simpler = context would either.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Mar 14 07:02: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 39A95D0B385 for ; Tue, 14 Mar 2017 07:02:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-176.reflexion.net [208.70.211.176]) (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 EDB1C18E4 for ; Tue, 14 Mar 2017 07:02:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12041 invoked from network); 14 Mar 2017 07:05:02 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Mar 2017 07:05:02 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 03:02:34 -0400 (EDT) Received: (qmail 31434 invoked from network); 14 Mar 2017 07:02:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Mar 2017 07:02:34 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B63C0EC892D; Tue, 14 Mar 2017 00:02:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: amd64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) From: Mark Millard In-Reply-To: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> Date: Tue, 14 Mar 2017 00:02:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> To: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 07:02:42 -0000 On 2017-Mar-13, at 11:52 PM, Mark Millard wrote: > I'm still at a loss about how to figure out what stages are messed > up. (Memory coherency? Some memory not swapped out? Bad data swapped > out? Wrong data swapped in?) >=20 > But at least I've found a much smaller/simpler example to demonstrate > some problem with in my Pine64+_ 2GB context. >=20 > The Pine64+ 2GB is the only amd64 context that I have access to. Someday I'll learn to type arm64 the first time instead of amd64. > The following program fails its check for data > having its expected byte pattern in dynamically > allocated memory after a fork/swap-out/swap-in > sequence. >=20 > I'll note that the program sleeps for 60s after > forking to give time to do something else to > cause the parent and child processes to swap > out (RES=3D0 as seen in top). >=20 > Note the source code line: >=20 > // test_check(); // Adding this line prevents failure. >=20 > It seem that accessing the region contents before forking > and swapping avoids the problem. But there is a problem > if the region was only written-to before the fork/swap. >=20 > Another point is the size of the region matters: <=3D 14K Bytes > fails and > 14K Bytes works for as much has I have tested. >=20 >=20 > # more swap_testing.c > // swap_testing.c >=20 > // Built via (c++ was clang++ 4.0 in my case): > // > // cc -g -std=3Dc11 -Wpedantic swap_testing.c > // -O0 and -O2 also gets the problem. >=20 > #include // for fork(), sleep(.) > #include // for pid_t > #include // for wait(.) >=20 > extern void test_setup(void); // Sets up the memory byte pattern. > extern void test_check(void); // Tests the memory byte pattern. >=20 > int main(void) > { > test_setup(); > // test_check(); // Adding this line prevents failure. >=20 > pid_t pid =3D fork(); > int wait_status =3D 0;; >=20 > if (0=20 > if (-1!=3Dwait_status && 0<=3Dpid) > { > if (0=3D=3Dpid) > { > sleep(60); >=20 > // During this manually force this process to > // swap out. I use something like: >=20 > // stress -m 1 --vm-bytes 1800M >=20 > // in another shell and ^C'ing it after top > // shows the swapped status desired. 1800M > // just happened to work on the Pine64+ 2GB > // that I was using. > } >=20 > test_check(); > } > } >=20 > // The memory and test code follows. >=20 > #include // for bool, true, false > #include // for size_t, NULL > #include // for malloc(.), free(.) >=20 > #include // for raise(.), SIGABRT >=20 > #define region_size (14u*1024u) > // Bad dyn_region pattern, parent and child > // processes: > // 256u, 4u*1024u, 8u*1024u, 9u*1024u, > // 12u*1024u, 14u*1024u >=20 > // Works: > // 14u*1024u+1u, 15u*1024u, 16u*1024u, > // 32u*1024u, 256u*1024u*1024u >=20 > typedef volatile unsigned char value_type; >=20 > struct region_struct { value_type array[region_size]; }; > typedef struct region_struct region; >=20 > static region gbl_region; > static region * volatile dyn_region =3D NULL; >=20 > static value_type value(size_t v) { return (value_type)v; } >=20 > void test_setup(void) { > dyn_region =3D malloc(sizeof(region)); > if (!dyn_region) raise(SIGABRT); >=20 > for(size_t i=3D0u; i (*dyn_region).array[i] =3D gbl_region.array[i] =3D value(i); > } > } >=20 > static volatile bool gbl_failed =3D false; // Until potentially = disproved > static volatile size_t gbl_pos =3D 0u; >=20 > static volatile bool dyn_failed =3D false; // Until potentially = disproved > static volatile size_t dyn_pos =3D 0u; >=20 > void test_check(void) { > while (!gbl_failed && gbl_pos gbl_failed =3D (value(gbl_pos) !=3D gbl_region.array[gbl_pos]); > gbl_pos++; > } >=20 > while (!dyn_failed && dyn_pos dyn_failed =3D (value(dyn_pos) !=3D = (*dyn_region).array[dyn_pos]); > // Note: When the memory pattern fails this case is that > // records the failure. > dyn_pos++; > } >=20 > if (gbl_failed) raise(SIGABRT); > if (dyn_failed) raise(SIGABRT); // lldb reports this line for the = __raise call. > // when it fails (both parent and = child processes). > } >=20 >=20 > Other details from lldb (not using -O2 so things are > simpler, not presented in the order examined): >=20 > # lldb a.out -c /var/crash/a.out.11575.core > (lldb) target create "a.out" --core "/var/crash/a.out.11575.core" > Core file '/var/crash/a.out.11575.core' (aarch64) was loaded. > (lldb) bt > * thread #1, name =3D 'a.out', stop reason =3D signal SIGABRT > * frame #0: 0x0000000040113d38 libc.so.7`_thr_kill + 8 > frame #1: libc.so.7`__raise(s=3D6) at raise.c:52 > frame #2: a.out`test_check at swap_testing.c:103 > frame #3: a.out`main at swap_testing.c:42 > frame #4: 0x0000000000020184 a.out`__start + 364 > frame #5: ld-elf.so.1`.rtld_start at rtld_start.S:41 >=20 > (lldb) up 2 > frame #2: a.out`test_check at swap_testing.c:103 > 100 } > 101 =09 > 102 if (gbl_failed) raise(SIGABRT); > -> 103 if (dyn_failed) raise(SIGABRT); // lldb reports this = line for the __raise call. > 104 // when it fails = (both parent and child processes). > 105 } >=20 > (lldb) print dyn_pos > (size_t) $0 =3D 2 >=20 > (That is one after the failure position.) >=20 >=20 > (lldb) print dyn_region > (region *volatile) $3 =3D 0x0000000040616000 >=20 > (lldb) print *dyn_region > (region) $1 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\0' > [2] =3D '\0' > . . . (all '\0' bytes) . . . > [251] =3D '\0' > [252] =3D '\0' > [253] =3D '\0' > [254] =3D '\0' > [255] =3D '\0' > ... > } > } >=20 > (lldb) print gbl_region > (region) $2 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\x01' > [2] =3D '\x02' > . . . > [251] =3D '\xfb' > [252] =3D '\xfc' > [253] =3D '\xfd' > [254] =3D '\xfe' > [255] =3D '\xff' > ... > } > } >=20 > (lldb) disass -n main > a.out`main: > 0x2022c <+0>: sub sp, sp, #0x30 ; =3D0x30=20 > 0x20230 <+4>: stp x29, x30, [sp, #0x20] > 0x20234 <+8>: add x29, sp, #0x20 ; =3D0x20=20 > 0x20238 <+12>: stur wzr, [x29, #-0x4] > 0x2023c <+16>: bl 0x202b0 ; test_setup at = swap_testing.c:74 > 0x20240 <+20>: bl 0x20580 ; symbol stub for: = fork > 0x20244 <+24>: mov w8, wzr > 0x20248 <+28>: stur w0, [x29, #-0x8] > 0x2024c <+32>: stur wzr, [x29, #-0xc] > 0x20250 <+36>: ldur w0, [x29, #-0x8] > 0x20254 <+40>: cmp w8, w0 > 0x20258 <+44>: b.ge 0x20268 ; <+60> at = swap_testing.c > 0x2025c <+48>: sub x0, x29, #0xc ; =3D0xc=20 > 0x20260 <+52>: bl 0x20590 ; symbol stub for: = wait > 0x20264 <+56>: str w0, [sp, #0x10] > 0x20268 <+60>: mov w8, #-0x1 > 0x2026c <+64>: ldur w9, [x29, #-0xc] > 0x20270 <+68>: cmp w8, w9 > 0x20274 <+72>: b.eq 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20278 <+76>: mov w8, wzr > 0x2027c <+80>: ldur w9, [x29, #-0x8] > 0x20280 <+84>: cmp w8, w9 > 0x20284 <+88>: b.gt 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20288 <+92>: ldur w8, [x29, #-0x8] > 0x2028c <+96>: cbnz w8, 0x2029c ; <+112> at = swap_testing.c:42 > 0x20290 <+100>: orr w0, wzr, #0x3c > 0x20294 <+104>: bl 0x205a0 ; symbol stub for: = sleep > 0x20298 <+108>: str w0, [sp, #0xc] > 0x2029c <+112>: bl 0x20348 ; test_check at = swap_testing.c:89 > 0x202a0 <+116>: ldur w0, [x29, #-0x4] > 0x202a4 <+120>: ldp x29, x30, [sp, #0x20] > 0x202a8 <+124>: add sp, sp, #0x30 ; =3D0x30=20 > 0x202ac <+128>: ret =20 >=20 > (lldb) disass -n value > a.out`value: > 0x204cc <+0>: sub sp, sp, #0x10 ; =3D0x10=20 > 0x204d0 <+4>: str x0, [sp, #0x8] > 0x204d4 <+8>: ldrb w8, [sp, #0x8] > 0x204d8 <+12>: mov w1, w8 > 0x204dc <+16>: mov w0, w8 > 0x204e0 <+20>: str w1, [sp, #0x4] > 0x204e4 <+24>: add sp, sp, #0x10 ; =3D0x10=20 > 0x204e8 <+28>: ret =20 >=20 > (lldb) disass -n test_setup > a.out`test_setup: > 0x202b0 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x202b4 <+4>: stp x29, x30, [sp, #0x10] > 0x202b8 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x202bc <+12>: orr x0, xzr, #0x3800 > 0x202c0 <+16>: bl 0x205b0 ; symbol stub for: = malloc > 0x202c4 <+20>: adrp x30, 48 > 0x202c8 <+24>: add x30, x30, #0x0 ; =3D0x0=20 > 0x202cc <+28>: str x0, [x30] > 0x202d0 <+32>: ldr x0, [x30] > 0x202d4 <+36>: cbnz x0, 0x202e4 ; <+52> at = swap_testing.c:78 > 0x202d8 <+40>: orr w0, wzr, #0x6 > 0x202dc <+44>: bl 0x205c0 ; symbol stub for: = raise > 0x202e0 <+48>: str w0, [sp, #0x4] > 0x202e4 <+52>: str xzr, [sp, #0x8] > 0x202e8 <+56>: orr x8, xzr, #0x3800 > 0x202ec <+60>: ldr x9, [sp, #0x8] > 0x202f0 <+64>: cmp x9, x8 > 0x202f4 <+68>: b.hs 0x2033c ; <+140> at = swap_testing.c:81 > 0x202f8 <+72>: ldr x0, [sp, #0x8] > 0x202fc <+76>: bl 0x204cc ; value at = swap_testing.c:72 > 0x20300 <+80>: adrp x30, 48 > 0x20304 <+84>: add x30, x30, #0x0 ; =3D0x0=20 > 0x20308 <+88>: adrp x8, 48 > 0x2030c <+92>: add x8, x8, #0x8 ; =3D0x8=20 > 0x20310 <+96>: ldr x9, [sp, #0x8] > 0x20314 <+100>: add x8, x8, x9 > 0x20318 <+104>: strb w0, [x8] > 0x2031c <+108>: ldr x8, [x30] > 0x20320 <+112>: ldr x9, [sp, #0x8] > 0x20324 <+116>: add x8, x8, x9 > 0x20328 <+120>: strb w0, [x8] > 0x2032c <+124>: ldr x8, [sp, #0x8] > 0x20330 <+128>: add x8, x8, #0x1 ; =3D0x1=20 > 0x20334 <+132>: str x8, [sp, #0x8] > 0x20338 <+136>: b 0x202e8 ; <+56> at = swap_testing.c > 0x2033c <+140>: ldp x29, x30, [sp, #0x10] > 0x20340 <+144>: add sp, sp, #0x20 ; =3D0x20=20 > 0x20344 <+148>: ret =20 >=20 > (lldb) disass -n test_check > a.out`test_check: > 0x20348 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x2034c <+4>: stp x29, x30, [sp, #0x10] > 0x20350 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x20354 <+12>: b 0x20358 ; <+16> at = swap_testing.c > 0x20358 <+16>: mov w8, wzr > 0x2035c <+20>: adrp x9, 51 > 0x20360 <+24>: add x9, x9, #0x808 ; =3D0x808=20 > 0x20364 <+28>: ldrb w10, [x9] > 0x20368 <+32>: stur w8, [x29, #-0x4] > 0x2036c <+36>: tbnz w10, #0x0, 0x2038c ; <+68> at = swap_testing.c > 0x20370 <+40>: orr x8, xzr, #0x3800 > 0x20374 <+44>: adrp x9, 51 > 0x20378 <+48>: add x9, x9, #0x810 ; =3D0x810=20 > 0x2037c <+52>: ldr x9, [x9] > 0x20380 <+56>: cmp x9, x8 > 0x20384 <+60>: cset w10, lo > 0x20388 <+64>: stur w10, [x29, #-0x4] > 0x2038c <+68>: ldur w8, [x29, #-0x4] > 0x20390 <+72>: tbz w8, #0x0, 0x203ec ; <+164> at = swap_testing.c:95 > 0x20394 <+76>: adrp x8, 51 > 0x20398 <+80>: add x8, x8, #0x810 ; =3D0x810=20 > 0x2039c <+84>: ldr x0, [x8] > 0x203a0 <+88>: bl 0x204cc ; value at = swap_testing.c:72 > 0x203a4 <+92>: adrp x8, 51 > 0x203a8 <+96>: add x8, x8, #0x810 ; =3D0x810=20 > 0x203ac <+100>: adrp x30, 51 > 0x203b0 <+104>: add x30, x30, #0x808 ; =3D0x808=20 > 0x203b4 <+108>: adrp x9, 48 > 0x203b8 <+112>: add x9, x9, #0x8 ; =3D0x8=20 > 0x203bc <+116>: uxtb w0, w0 > 0x203c0 <+120>: ldr x10, [x8] > 0x203c4 <+124>: add x9, x9, x10 > 0x203c8 <+128>: ldrb w11, [x9] > 0x203cc <+132>: cmp w0, w11 > 0x203d0 <+136>: cset w11, ne > 0x203d4 <+140>: and w11, w11, #0x1 > 0x203d8 <+144>: strb w11, [x30] > 0x203dc <+148>: ldr x9, [x8] > 0x203e0 <+152>: add x9, x9, #0x1 ; =3D0x1=20 > 0x203e4 <+156>: str x9, [x8] > 0x203e8 <+160>: b 0x20358 ; <+16> at = swap_testing.c > 0x203ec <+164>: b 0x203f0 ; <+168> at = swap_testing.c > 0x203f0 <+168>: mov w8, wzr > 0x203f4 <+172>: adrp x9, 51 > 0x203f8 <+176>: add x9, x9, #0x818 ; =3D0x818=20 > 0x203fc <+180>: ldrb w10, [x9] > 0x20400 <+184>: str w8, [sp, #0x8] > 0x20404 <+188>: tbnz w10, #0x0, 0x20424 ; <+220> at = swap_testing.c > 0x20408 <+192>: orr x8, xzr, #0x3800 > 0x2040c <+196>: adrp x9, 51 > 0x20410 <+200>: add x9, x9, #0x820 ; =3D0x820=20 > 0x20414 <+204>: ldr x9, [x9] > 0x20418 <+208>: cmp x9, x8 > 0x2041c <+212>: cset w10, lo > 0x20420 <+216>: str w10, [sp, #0x8] > 0x20424 <+220>: ldr w8, [sp, #0x8] > 0x20428 <+224>: tbz w8, #0x0, 0x20488 ; <+320> at = swap_testing.c > 0x2042c <+228>: adrp x8, 51 > 0x20430 <+232>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20434 <+236>: ldr x0, [x8] > 0x20438 <+240>: bl 0x204cc ; value at = swap_testing.c:72 > 0x2043c <+244>: adrp x8, 51 > 0x20440 <+248>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20444 <+252>: adrp x30, 51 > 0x20448 <+256>: add x30, x30, #0x818 ; =3D0x818=20 > 0x2044c <+260>: adrp x9, 48 > 0x20450 <+264>: add x9, x9, #0x0 ; =3D0x0=20 > 0x20454 <+268>: uxtb w0, w0 > 0x20458 <+272>: ldr x9, [x9] > 0x2045c <+276>: ldr x10, [x8] > 0x20460 <+280>: add x9, x9, x10 > 0x20464 <+284>: ldrb w11, [x9] > 0x20468 <+288>: cmp w0, w11 > 0x2046c <+292>: cset w11, ne > 0x20470 <+296>: and w11, w11, #0x1 > 0x20474 <+300>: strb w11, [x30] > 0x20478 <+304>: ldr x9, [x8] > 0x2047c <+308>: add x9, x9, #0x1 ; =3D0x1=20 > 0x20480 <+312>: str x9, [x8] > 0x20484 <+316>: b 0x203f0 ; <+168> at = swap_testing.c > 0x20488 <+320>: adrp x8, 51 > 0x2048c <+324>: add x8, x8, #0x808 ; =3D0x808=20 > 0x20490 <+328>: ldrb w9, [x8] > 0x20494 <+332>: tbz w9, #0x0, 0x204a4 ; <+348> at = swap_testing.c > 0x20498 <+336>: orr w0, wzr, #0x6 > 0x2049c <+340>: bl 0x205c0 ; symbol stub for: = raise > 0x204a0 <+344>: str w0, [sp, #0x4] > 0x204a4 <+348>: adrp x8, 51 > 0x204a8 <+352>: add x8, x8, #0x818 ; =3D0x818=20 > 0x204ac <+356>: ldrb w9, [x8] > 0x204b0 <+360>: tbz w9, #0x0, 0x204c0 ; <+376> at = swap_testing.c:105 > 0x204b4 <+364>: orr w0, wzr, #0x6 > 0x204b8 <+368>: bl 0x205c0 ; symbol stub for: = raise > -> 0x204bc <+372>: str w0, [sp] > 0x204c0 <+376>: ldp x29, x30, [sp, #0x10] > 0x204c4 <+380>: add sp, sp, #0x20 ; =3D0x20=20 > 0x204c8 <+384>: ret =20 >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r314638M arm64 = aarch64 1200023 1200023 >=20 > buildworld buildlkernel did not have MALLOC_PRODUCTION=3D defined. The = kernel is a > non-debug kernel. (Previous to these experiments my other corruption = examples > were not caught by a debug kernel. I'm not hopeful that this simpler = context > would either.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Mar 14 07:58:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5483CD0B863 for ; Tue, 14 Mar 2017 07:58:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-172.reflexion.net [208.70.211.172]) (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 19F221984 for ; Tue, 14 Mar 2017 07:58:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30180 invoked from network); 14 Mar 2017 07:58:17 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Mar 2017 07:58:17 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 03:58:17 -0400 (EDT) Received: (qmail 2793 invoked from network); 14 Mar 2017 07:58:17 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Mar 2017 07:58:17 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 72316EC8123; Tue, 14 Mar 2017 00:58:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: amd64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) From: Mark Millard In-Reply-To: Date: Tue, 14 Mar 2017 00:58:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> To: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 07:58:24 -0000 [Another correction I'm afraid --about alternative program variations this time.] On 2017-Mar-13, at 11:52 PM, Mark Millard wrote: > I'm still at a loss about how to figure out what stages are messed > up. (Memory coherency? Some memory not swapped out? Bad data swapped > out? Wrong data swapped in?) >=20 > But at least I've found a much smaller/simpler example to demonstrate > some problem with in my Pine64+_ 2GB context. >=20 > The Pine64+ 2GB is the only amd64 context that I have access to. Someday I'll learn to type arm64 the first time instead of amd64. > The following program fails its check for data > having its expected byte pattern in dynamically > allocated memory after a fork/swap-out/swap-in > sequence. >=20 > I'll note that the program sleeps for 60s after > forking to give time to do something else to > cause the parent and child processes to swap > out (RES=3D0 as seen in top). The following about the extra test_check() was wrong. > Note the source code line: >=20 > // test_check(); // Adding this line prevents failure. >=20 > It seem that accessing the region contents before forking > and swapping avoids the problem. But there is a problem > if the region was only written-to before the fork/swap. This was because I'd carelessly moved some loop variables to globals in a way that depended on the initialization of the globals and the extra call changed those values. I've noted code adjustments below (3 lines). I get the failures with them as well. > Another point is the size of the region matters: <=3D 14K Bytes > fails and > 14K Bytes works for as much has I have tested. >=20 >=20 > # more swap_testing.c > // swap_testing.c >=20 > // Built via (c++ was clang++ 4.0 in my case): > // > // cc -g -std=3Dc11 -Wpedantic swap_testing.c > // -O0 and -O2 also gets the problem. >=20 > #include // for fork(), sleep(.) > #include // for pid_t > #include // for wait(.) >=20 > extern void test_setup(void); // Sets up the memory byte pattern. > extern void test_check(void); // Tests the memory byte pattern. >=20 > int main(void) > { > test_setup(); test_check(); // This test passes. >=20 > pid_t pid =3D fork(); > int wait_status =3D 0;; >=20 > if (0=20 > if (-1!=3Dwait_status && 0<=3Dpid) > { > if (0=3D=3Dpid) > { > sleep(60); >=20 > // During this manually force this process to > // swap out. I use something like: >=20 > // stress -m 1 --vm-bytes 1800M >=20 > // in another shell and ^C'ing it after top > // shows the swapped status desired. 1800M > // just happened to work on the Pine64+ 2GB > // that I was using. > } >=20 > test_check(); > } > } >=20 > // The memory and test code follows. >=20 > #include // for bool, true, false > #include // for size_t, NULL > #include // for malloc(.), free(.) >=20 > #include // for raise(.), SIGABRT >=20 > #define region_size (14u*1024u) > // Bad dyn_region pattern, parent and child > // processes: > // 256u, 4u*1024u, 8u*1024u, 9u*1024u, > // 12u*1024u, 14u*1024u >=20 > // Works: > // 14u*1024u+1u, 15u*1024u, 16u*1024u, > // 32u*1024u, 256u*1024u*1024u >=20 > typedef volatile unsigned char value_type; >=20 > struct region_struct { value_type array[region_size]; }; > typedef struct region_struct region; >=20 > static region gbl_region; > static region * volatile dyn_region =3D NULL; >=20 > static value_type value(size_t v) { return (value_type)v; } >=20 > void test_setup(void) { > dyn_region =3D malloc(sizeof(region)); > if (!dyn_region) raise(SIGABRT); >=20 > for(size_t i=3D0u; i (*dyn_region).array[i] =3D gbl_region.array[i] =3D value(i); > } > } >=20 > static volatile bool gbl_failed =3D false; // Until potentially = disproved > static volatile size_t gbl_pos =3D 0u; >=20 > static volatile bool dyn_failed =3D false; // Until potentially = disproved > static volatile size_t dyn_pos =3D 0u; >=20 > void test_check(void) { gbl_pos =3D 0u; > while (!gbl_failed && gbl_pos gbl_failed =3D (value(gbl_pos) !=3D gbl_region.array[gbl_pos]); > gbl_pos++; > } >=20 dyn_pos =3D 0u; > while (!dyn_failed && dyn_pos dyn_failed =3D (value(dyn_pos) !=3D = (*dyn_region).array[dyn_pos]); > // Note: When the memory pattern fails this case is that > // records the failure. > dyn_pos++; > } >=20 > if (gbl_failed) raise(SIGABRT); > if (dyn_failed) raise(SIGABRT); // lldb reports this line for the = __raise call. > // when it fails (both parent and = child processes). > } I'm not bothering to redo the details below for the line number variations. > Other details from lldb (not using -O2 so things are > simpler, not presented in the order examined): >=20 > # lldb a.out -c /var/crash/a.out.11575.core > (lldb) target create "a.out" --core "/var/crash/a.out.11575.core" > Core file '/var/crash/a.out.11575.core' (aarch64) was loaded. > (lldb) bt > * thread #1, name =3D 'a.out', stop reason =3D signal SIGABRT > * frame #0: 0x0000000040113d38 libc.so.7`_thr_kill + 8 > frame #1: libc.so.7`__raise(s=3D6) at raise.c:52 > frame #2: a.out`test_check at swap_testing.c:103 > frame #3: a.out`main at swap_testing.c:42 > frame #4: 0x0000000000020184 a.out`__start + 364 > frame #5: ld-elf.so.1`.rtld_start at rtld_start.S:41 >=20 > (lldb) up 2 > frame #2: a.out`test_check at swap_testing.c:103 > 100 } > 101 =09 > 102 if (gbl_failed) raise(SIGABRT); > -> 103 if (dyn_failed) raise(SIGABRT); // lldb reports this = line for the __raise call. > 104 // when it fails (both = parent and child processes). > 105 } >=20 > (lldb) print dyn_pos > (size_t) $0 =3D 2 >=20 > (That is one after the failure position.) >=20 >=20 > (lldb) print dyn_region > (region *volatile) $3 =3D 0x0000000040616000 >=20 > (lldb) print *dyn_region > (region) $1 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\0' > [2] =3D '\0' > . . . (all '\0' bytes) . . . > [251] =3D '\0' > [252] =3D '\0' > [253] =3D '\0' > [254] =3D '\0' > [255] =3D '\0' > ... > } > } >=20 > (lldb) print gbl_region > (region) $2 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\x01' > [2] =3D '\x02' > . . . > [251] =3D '\xfb' > [252] =3D '\xfc' > [253] =3D '\xfd' > [254] =3D '\xfe' > [255] =3D '\xff' > ... > } > } >=20 > (lldb) disass -n main > a.out`main: > 0x2022c <+0>: sub sp, sp, #0x30 ; =3D0x30=20 > 0x20230 <+4>: stp x29, x30, [sp, #0x20] > 0x20234 <+8>: add x29, sp, #0x20 ; =3D0x20=20 > 0x20238 <+12>: stur wzr, [x29, #-0x4] > 0x2023c <+16>: bl 0x202b0 ; test_setup at = swap_testing.c:74 > 0x20240 <+20>: bl 0x20580 ; symbol stub for: = fork > 0x20244 <+24>: mov w8, wzr > 0x20248 <+28>: stur w0, [x29, #-0x8] > 0x2024c <+32>: stur wzr, [x29, #-0xc] > 0x20250 <+36>: ldur w0, [x29, #-0x8] > 0x20254 <+40>: cmp w8, w0 > 0x20258 <+44>: b.ge 0x20268 ; <+60> at = swap_testing.c > 0x2025c <+48>: sub x0, x29, #0xc ; =3D0xc=20 > 0x20260 <+52>: bl 0x20590 ; symbol stub for: = wait > 0x20264 <+56>: str w0, [sp, #0x10] > 0x20268 <+60>: mov w8, #-0x1 > 0x2026c <+64>: ldur w9, [x29, #-0xc] > 0x20270 <+68>: cmp w8, w9 > 0x20274 <+72>: b.eq 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20278 <+76>: mov w8, wzr > 0x2027c <+80>: ldur w9, [x29, #-0x8] > 0x20280 <+84>: cmp w8, w9 > 0x20284 <+88>: b.gt 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20288 <+92>: ldur w8, [x29, #-0x8] > 0x2028c <+96>: cbnz w8, 0x2029c ; <+112> at = swap_testing.c:42 > 0x20290 <+100>: orr w0, wzr, #0x3c > 0x20294 <+104>: bl 0x205a0 ; symbol stub for: = sleep > 0x20298 <+108>: str w0, [sp, #0xc] > 0x2029c <+112>: bl 0x20348 ; test_check at = swap_testing.c:89 > 0x202a0 <+116>: ldur w0, [x29, #-0x4] > 0x202a4 <+120>: ldp x29, x30, [sp, #0x20] > 0x202a8 <+124>: add sp, sp, #0x30 ; =3D0x30=20 > 0x202ac <+128>: ret =20 >=20 > (lldb) disass -n value > a.out`value: > 0x204cc <+0>: sub sp, sp, #0x10 ; =3D0x10=20 > 0x204d0 <+4>: str x0, [sp, #0x8] > 0x204d4 <+8>: ldrb w8, [sp, #0x8] > 0x204d8 <+12>: mov w1, w8 > 0x204dc <+16>: mov w0, w8 > 0x204e0 <+20>: str w1, [sp, #0x4] > 0x204e4 <+24>: add sp, sp, #0x10 ; =3D0x10=20 > 0x204e8 <+28>: ret =20 >=20 > (lldb) disass -n test_setup > a.out`test_setup: > 0x202b0 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x202b4 <+4>: stp x29, x30, [sp, #0x10] > 0x202b8 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x202bc <+12>: orr x0, xzr, #0x3800 > 0x202c0 <+16>: bl 0x205b0 ; symbol stub for: = malloc > 0x202c4 <+20>: adrp x30, 48 > 0x202c8 <+24>: add x30, x30, #0x0 ; =3D0x0=20 > 0x202cc <+28>: str x0, [x30] > 0x202d0 <+32>: ldr x0, [x30] > 0x202d4 <+36>: cbnz x0, 0x202e4 ; <+52> at = swap_testing.c:78 > 0x202d8 <+40>: orr w0, wzr, #0x6 > 0x202dc <+44>: bl 0x205c0 ; symbol stub for: = raise > 0x202e0 <+48>: str w0, [sp, #0x4] > 0x202e4 <+52>: str xzr, [sp, #0x8] > 0x202e8 <+56>: orr x8, xzr, #0x3800 > 0x202ec <+60>: ldr x9, [sp, #0x8] > 0x202f0 <+64>: cmp x9, x8 > 0x202f4 <+68>: b.hs 0x2033c ; <+140> at = swap_testing.c:81 > 0x202f8 <+72>: ldr x0, [sp, #0x8] > 0x202fc <+76>: bl 0x204cc ; value at = swap_testing.c:72 > 0x20300 <+80>: adrp x30, 48 > 0x20304 <+84>: add x30, x30, #0x0 ; =3D0x0=20 > 0x20308 <+88>: adrp x8, 48 > 0x2030c <+92>: add x8, x8, #0x8 ; =3D0x8=20 > 0x20310 <+96>: ldr x9, [sp, #0x8] > 0x20314 <+100>: add x8, x8, x9 > 0x20318 <+104>: strb w0, [x8] > 0x2031c <+108>: ldr x8, [x30] > 0x20320 <+112>: ldr x9, [sp, #0x8] > 0x20324 <+116>: add x8, x8, x9 > 0x20328 <+120>: strb w0, [x8] > 0x2032c <+124>: ldr x8, [sp, #0x8] > 0x20330 <+128>: add x8, x8, #0x1 ; =3D0x1=20 > 0x20334 <+132>: str x8, [sp, #0x8] > 0x20338 <+136>: b 0x202e8 ; <+56> at = swap_testing.c > 0x2033c <+140>: ldp x29, x30, [sp, #0x10] > 0x20340 <+144>: add sp, sp, #0x20 ; =3D0x20=20 > 0x20344 <+148>: ret =20 >=20 > (lldb) disass -n test_check > a.out`test_check: > 0x20348 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x2034c <+4>: stp x29, x30, [sp, #0x10] > 0x20350 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x20354 <+12>: b 0x20358 ; <+16> at = swap_testing.c > 0x20358 <+16>: mov w8, wzr > 0x2035c <+20>: adrp x9, 51 > 0x20360 <+24>: add x9, x9, #0x808 ; =3D0x808=20 > 0x20364 <+28>: ldrb w10, [x9] > 0x20368 <+32>: stur w8, [x29, #-0x4] > 0x2036c <+36>: tbnz w10, #0x0, 0x2038c ; <+68> at = swap_testing.c > 0x20370 <+40>: orr x8, xzr, #0x3800 > 0x20374 <+44>: adrp x9, 51 > 0x20378 <+48>: add x9, x9, #0x810 ; =3D0x810=20 > 0x2037c <+52>: ldr x9, [x9] > 0x20380 <+56>: cmp x9, x8 > 0x20384 <+60>: cset w10, lo > 0x20388 <+64>: stur w10, [x29, #-0x4] > 0x2038c <+68>: ldur w8, [x29, #-0x4] > 0x20390 <+72>: tbz w8, #0x0, 0x203ec ; <+164> at = swap_testing.c:95 > 0x20394 <+76>: adrp x8, 51 > 0x20398 <+80>: add x8, x8, #0x810 ; =3D0x810=20 > 0x2039c <+84>: ldr x0, [x8] > 0x203a0 <+88>: bl 0x204cc ; value at = swap_testing.c:72 > 0x203a4 <+92>: adrp x8, 51 > 0x203a8 <+96>: add x8, x8, #0x810 ; =3D0x810=20 > 0x203ac <+100>: adrp x30, 51 > 0x203b0 <+104>: add x30, x30, #0x808 ; =3D0x808=20 > 0x203b4 <+108>: adrp x9, 48 > 0x203b8 <+112>: add x9, x9, #0x8 ; =3D0x8=20 > 0x203bc <+116>: uxtb w0, w0 > 0x203c0 <+120>: ldr x10, [x8] > 0x203c4 <+124>: add x9, x9, x10 > 0x203c8 <+128>: ldrb w11, [x9] > 0x203cc <+132>: cmp w0, w11 > 0x203d0 <+136>: cset w11, ne > 0x203d4 <+140>: and w11, w11, #0x1 > 0x203d8 <+144>: strb w11, [x30] > 0x203dc <+148>: ldr x9, [x8] > 0x203e0 <+152>: add x9, x9, #0x1 ; =3D0x1=20 > 0x203e4 <+156>: str x9, [x8] > 0x203e8 <+160>: b 0x20358 ; <+16> at = swap_testing.c > 0x203ec <+164>: b 0x203f0 ; <+168> at = swap_testing.c > 0x203f0 <+168>: mov w8, wzr > 0x203f4 <+172>: adrp x9, 51 > 0x203f8 <+176>: add x9, x9, #0x818 ; =3D0x818=20 > 0x203fc <+180>: ldrb w10, [x9] > 0x20400 <+184>: str w8, [sp, #0x8] > 0x20404 <+188>: tbnz w10, #0x0, 0x20424 ; <+220> at = swap_testing.c > 0x20408 <+192>: orr x8, xzr, #0x3800 > 0x2040c <+196>: adrp x9, 51 > 0x20410 <+200>: add x9, x9, #0x820 ; =3D0x820=20 > 0x20414 <+204>: ldr x9, [x9] > 0x20418 <+208>: cmp x9, x8 > 0x2041c <+212>: cset w10, lo > 0x20420 <+216>: str w10, [sp, #0x8] > 0x20424 <+220>: ldr w8, [sp, #0x8] > 0x20428 <+224>: tbz w8, #0x0, 0x20488 ; <+320> at = swap_testing.c > 0x2042c <+228>: adrp x8, 51 > 0x20430 <+232>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20434 <+236>: ldr x0, [x8] > 0x20438 <+240>: bl 0x204cc ; value at = swap_testing.c:72 > 0x2043c <+244>: adrp x8, 51 > 0x20440 <+248>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20444 <+252>: adrp x30, 51 > 0x20448 <+256>: add x30, x30, #0x818 ; =3D0x818=20 > 0x2044c <+260>: adrp x9, 48 > 0x20450 <+264>: add x9, x9, #0x0 ; =3D0x0=20 > 0x20454 <+268>: uxtb w0, w0 > 0x20458 <+272>: ldr x9, [x9] > 0x2045c <+276>: ldr x10, [x8] > 0x20460 <+280>: add x9, x9, x10 > 0x20464 <+284>: ldrb w11, [x9] > 0x20468 <+288>: cmp w0, w11 > 0x2046c <+292>: cset w11, ne > 0x20470 <+296>: and w11, w11, #0x1 > 0x20474 <+300>: strb w11, [x30] > 0x20478 <+304>: ldr x9, [x8] > 0x2047c <+308>: add x9, x9, #0x1 ; =3D0x1=20 > 0x20480 <+312>: str x9, [x8] > 0x20484 <+316>: b 0x203f0 ; <+168> at = swap_testing.c > 0x20488 <+320>: adrp x8, 51 > 0x2048c <+324>: add x8, x8, #0x808 ; =3D0x808=20 > 0x20490 <+328>: ldrb w9, [x8] > 0x20494 <+332>: tbz w9, #0x0, 0x204a4 ; <+348> at = swap_testing.c > 0x20498 <+336>: orr w0, wzr, #0x6 > 0x2049c <+340>: bl 0x205c0 ; symbol stub for: = raise > 0x204a0 <+344>: str w0, [sp, #0x4] > 0x204a4 <+348>: adrp x8, 51 > 0x204a8 <+352>: add x8, x8, #0x818 ; =3D0x818=20 > 0x204ac <+356>: ldrb w9, [x8] > 0x204b0 <+360>: tbz w9, #0x0, 0x204c0 ; <+376> at = swap_testing.c:105 > 0x204b4 <+364>: orr w0, wzr, #0x6 > 0x204b8 <+368>: bl 0x205c0 ; symbol stub for: = raise > -> 0x204bc <+372>: str w0, [sp] > 0x204c0 <+376>: ldp x29, x30, [sp, #0x10] > 0x204c4 <+380>: add sp, sp, #0x20 ; =3D0x20=20 > 0x204c8 <+384>: ret =20 >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r314638M arm64 = aarch64 1200023 1200023 >=20 > buildworld buildlkernel did not have MALLOC_PRODUCTION=3D defined. The = kernel is a > non-debug kernel. (Previous to these experiments my other corruption = examples > were not caught by a debug kernel. I'm not hopeful that this simpler = context > would either.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Mar 14 14:50: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 80286D0B580 for ; Tue, 14 Mar 2017 14:50:53 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34131F17; Tue, 14 Mar 2017 14:50:52 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.1] (port=63286 helo=caithnard.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cnnmc-000DnB-TA; Tue, 14 Mar 2017 14:50:42 +0000 Received: from [127.0.0.1] (port=31751 helo=caithnard.riddles.org.uk) by caithnard.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1cnnmc-0003qj-87; Tue, 14 Mar 2017 14:50:42 +0000 From: Andrew Gierth To: Michal Meloun Cc: Konstantin Belousov , mmel@freebsd.org, "freebsd-arm\@freebsd.org" Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: (Michal Meloun's message of "Sun, 12 Mar 2017 09:17:35 +0100") Message-ID: <87bmt353ct.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <20170310174444.GN16105@kib.kiev.ua> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Tue, 14 Mar 2017 14:50:23 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 14:50:53 -0000 >>>>> "Michal" == Michal Meloun writes: Michal> ARM is still tier2, but I significantly prefer getcontextx() Michal> (or any other, backward compatible) way. Michal> Unfortunately, on armv6, the VFP part of kernel <-> userland Michal> interaction is broken from day 1. The struct fpreg is also Michal> wrong and I'm not sure if or how we can to fix this in Michal> compatible way. Is there anything I can do to help make progress on this? -- Andrew. From owner-freebsd-arm@freebsd.org Tue Mar 14 15:50: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 97CC7D0C084 for ; Tue, 14 Mar 2017 15:50:43 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 6B61411B1 for ; Tue, 14 Mar 2017 15:50:42 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 098EA2142F1 for ; Tue, 14 Mar 2017 10:50:35 -0500 (CDT) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: PI3 build failure on 315244 Message-ID: <3d4e6e20-d41b-e4de-7ea9-589ed7882171@denninger.net> Date: Tue, 14 Mar 2017 10:50:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060400050608040501080807" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 15:50:43 -0000 This is a cryptographically signed message in MIME format. --------------ms060400050608040501080807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fails here: --- all_subdir_tests --- In file included from /pics/CrossBuild-12/src/tests/sys/geom/class/eli/hmac_test.c:5: In file included from /sys/sys/param.h:90: /sys/sys/types.h:253:9: error: unknown type name '__vm_ooffset_t'; did you mean '__vm_offset_t'? typedef __vm_ooffset_t vm_ooffset_t; ^~~~~~~~~~~~~~ __vm_offset_t /pics/Crochet-work/obj/arm64.aarch64/pics/CrossBuild-12/src/tmp/usr/inclu= de/machine/_types.h:90:20: note: '__vm_offset_t' declared here typedef __uint64_t __vm_offset_t; ^ In file included from /pics/CrossBuild-12/src/tests/sys/geom/class/eli/hmac_test.c:5: In file included from /sys/sys/param.h:90: /sys/sys/types.h:255:9: error: unknown type name '__vm_pindex_t' typedef __vm_pindex_t vm_pindex_t; ^ --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060400050608040501080807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMTQxNTUwMThaME8GCSqGSIb3DQEJBDFCBED+xlwQ Z1i8s1r6DSyp67ajBk1Lhq9YIR8SzGrZKw6LEHgG0QmKf4uJsfHoDiFCMeN53f3hmq/wdQZJ JI5LlPSKMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAjwiKdDxW0Lnk 9DCQ8MIG/98icE3tLPslBkr1fozEok+RcHCEiv7EQjPv+vU1T2VuRPFJHrqAapZ5us2OEKDV /D4PjwM7bB+TlfDc0ir77PIIV70FTSkR4llJZqIka3VHRQVdqtzz7es8C+jhc/UYDwM8ftX0 wnaF2skN08F8Y5V5Yfft94s2I30qzd6hjqkBRvHKrzXlA/7OLTwp+ysLI/5MwXG5k7LQX4+B w2W4qevShifdKKMV1RTAatvfj+o12BGA4KvEohzIsIRnNltkhON5O4AYv/O5EzDxMUlZiVQT deeCE74WX5eJdZCUclz57P/854x/XgkEkhHDVJea7rYmCDYCucwT8Mqj+cWDAYVq6ZwrdGLU 1+gZCX3lWc2rMhnG3h3QiAuXdd9LpBSKqLoSqpxL3nmmP/D+S/acH2Z/P+D7UTmHbHevMHm+ 527FHkUdeUXuRQ75WrGzNAawm+zBhTFL/XumcEh8OIdkYS4MZZanmNvqpNdpapq2c2K1FFGz DNAaOzqEBQpWPqz3aUd8T50IzX3pNlms3pgR2M6Olvl/VH3Yq7cq7/V/l7Dxrq+x5cOtdIt1 1PzVtGw+lZeAF2602cRIjBjbtJJcOflfdldaP/fa+K7U24luwtp7NkrOtNvw+rInKDLmGs70 xT6MNSS3aDm8Yjzo5EBv+gEAAAAAAAA= --------------ms060400050608040501080807-- From owner-freebsd-arm@freebsd.org Tue Mar 14 18:34: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 543E5D0B3D6 for ; Tue, 14 Mar 2017 18:34:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-180.reflexion.net [208.70.211.180]) (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 131201C4D for ; Tue, 14 Mar 2017 18:34:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6576 invoked from network); 14 Mar 2017 18:07:20 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Mar 2017 18:07:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 14:07:20 -0400 (EDT) Received: (qmail 742 invoked from network); 14 Mar 2017 18:07:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Mar 2017 18:07:20 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id AEAB4EC8534; Tue, 14 Mar 2017 11:07:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> Date: Tue, 14 Mar 2017 11:07:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> To: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 18:34:02 -0000 [This is just a correction to the subject-line text to say arm64 instead of amd64.] On 2017-Mar-14, at 12:58 AM, Mark Millard wrote: [Another correction I'm afraid --about alternative program variations this time.] On 2017-Mar-13, at 11:52 PM, Mark Millard wrote: > I'm still at a loss about how to figure out what stages are messed > up. (Memory coherency? Some memory not swapped out? Bad data swapped > out? Wrong data swapped in?) >=20 > But at least I've found a much smaller/simpler example to demonstrate > some problem with in my Pine64+_ 2GB context. >=20 > The Pine64+ 2GB is the only amd64 context that I have access to. Someday I'll learn to type arm64 the first time instead of amd64. > The following program fails its check for data > having its expected byte pattern in dynamically > allocated memory after a fork/swap-out/swap-in > sequence. >=20 > I'll note that the program sleeps for 60s after > forking to give time to do something else to > cause the parent and child processes to swap > out (RES=3D0 as seen in top). The following about the extra test_check() was wrong. > Note the source code line: >=20 > // test_check(); // Adding this line prevents failure. >=20 > It seem that accessing the region contents before forking > and swapping avoids the problem. But there is a problem > if the region was only written-to before the fork/swap. This was because I'd carelessly moved some loop variables to globals in a way that depended on the initialization of the globals and the extra call changed those values. I've noted code adjustments below (3 lines). I get the failures with them as well. > Another point is the size of the region matters: <=3D 14K Bytes > fails and > 14K Bytes works for as much has I have tested. >=20 >=20 > # more swap_testing.c > // swap_testing.c >=20 > // Built via (c++ was clang++ 4.0 in my case): > // > // cc -g -std=3Dc11 -Wpedantic swap_testing.c > // -O0 and -O2 also gets the problem. >=20 > #include // for fork(), sleep(.) > #include // for pid_t > #include // for wait(.) >=20 > extern void test_setup(void); // Sets up the memory byte pattern. > extern void test_check(void); // Tests the memory byte pattern. >=20 > int main(void) > { > test_setup(); test_check(); // This test passes. >=20 > pid_t pid =3D fork(); > int wait_status =3D 0;; >=20 > if (0=20 > if (-1!=3Dwait_status && 0<=3Dpid) > { > if (0=3D=3Dpid) > { > sleep(60); >=20 > // During this manually force this process to > // swap out. I use something like: >=20 > // stress -m 1 --vm-bytes 1800M >=20 > // in another shell and ^C'ing it after top > // shows the swapped status desired. 1800M > // just happened to work on the Pine64+ 2GB > // that I was using. > } >=20 > test_check(); > } > } >=20 > // The memory and test code follows. >=20 > #include // for bool, true, false > #include // for size_t, NULL > #include // for malloc(.), free(.) >=20 > #include // for raise(.), SIGABRT >=20 > #define region_size (14u*1024u) > // Bad dyn_region pattern, parent and child > // processes: > // 256u, 4u*1024u, 8u*1024u, 9u*1024u, > // 12u*1024u, 14u*1024u >=20 > // Works: > // 14u*1024u+1u, 15u*1024u, 16u*1024u, > // 32u*1024u, 256u*1024u*1024u >=20 > typedef volatile unsigned char value_type; >=20 > struct region_struct { value_type array[region_size]; }; > typedef struct region_struct region; >=20 > static region gbl_region; > static region * volatile dyn_region =3D NULL; >=20 > static value_type value(size_t v) { return (value_type)v; } >=20 > void test_setup(void) { > dyn_region =3D malloc(sizeof(region)); > if (!dyn_region) raise(SIGABRT); >=20 > for(size_t i=3D0u; i (*dyn_region).array[i] =3D gbl_region.array[i] =3D value(i); > } > } >=20 > static volatile bool gbl_failed =3D false; // Until potentially = disproved > static volatile size_t gbl_pos =3D 0u; >=20 > static volatile bool dyn_failed =3D false; // Until potentially = disproved > static volatile size_t dyn_pos =3D 0u; >=20 > void test_check(void) { gbl_pos =3D 0u; > while (!gbl_failed && gbl_pos gbl_failed =3D (value(gbl_pos) !=3D gbl_region.array[gbl_pos]); > gbl_pos++; > } >=20 dyn_pos =3D 0u; > while (!dyn_failed && dyn_pos dyn_failed =3D (value(dyn_pos) !=3D = (*dyn_region).array[dyn_pos]); > // Note: When the memory pattern fails this case is that > // records the failure. > dyn_pos++; > } >=20 > if (gbl_failed) raise(SIGABRT); > if (dyn_failed) raise(SIGABRT); // lldb reports this line for the = __raise call. > // when it fails (both parent and = child processes). > } I'm not bothering to redo the details below for the line number variations. > Other details from lldb (not using -O2 so things are > simpler, not presented in the order examined): >=20 > # lldb a.out -c /var/crash/a.out.11575.core > (lldb) target create "a.out" --core "/var/crash/a.out.11575.core" > Core file '/var/crash/a.out.11575.core' (aarch64) was loaded. > (lldb) bt > * thread #1, name =3D 'a.out', stop reason =3D signal SIGABRT > * frame #0: 0x0000000040113d38 libc.so.7`_thr_kill + 8 > frame #1: libc.so.7`__raise(s=3D6) at raise.c:52 > frame #2: a.out`test_check at swap_testing.c:103 > frame #3: a.out`main at swap_testing.c:42 > frame #4: 0x0000000000020184 a.out`__start + 364 > frame #5: ld-elf.so.1`.rtld_start at rtld_start.S:41 >=20 > (lldb) up 2 > frame #2: a.out`test_check at swap_testing.c:103 > 100 } > 101 =09 > 102 if (gbl_failed) raise(SIGABRT); > -> 103 if (dyn_failed) raise(SIGABRT); // lldb reports this = line for the __raise call. > 104 // when it fails (both = parent and child processes). > 105 } >=20 > (lldb) print dyn_pos > (size_t) $0 =3D 2 >=20 > (That is one after the failure position.) >=20 >=20 > (lldb) print dyn_region > (region *volatile) $3 =3D 0x0000000040616000 >=20 > (lldb) print *dyn_region > (region) $1 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\0' > [2] =3D '\0' > . . . (all '\0' bytes) . . . > [251] =3D '\0' > [252] =3D '\0' > [253] =3D '\0' > [254] =3D '\0' > [255] =3D '\0' > ... > } > } >=20 > (lldb) print gbl_region > (region) $2 =3D { > array =3D { > [0] =3D '\0' > [1] =3D '\x01' > [2] =3D '\x02' > . . . > [251] =3D '\xfb' > [252] =3D '\xfc' > [253] =3D '\xfd' > [254] =3D '\xfe' > [255] =3D '\xff' > ... > } > } >=20 > (lldb) disass -n main > a.out`main: > 0x2022c <+0>: sub sp, sp, #0x30 ; =3D0x30=20 > 0x20230 <+4>: stp x29, x30, [sp, #0x20] > 0x20234 <+8>: add x29, sp, #0x20 ; =3D0x20=20 > 0x20238 <+12>: stur wzr, [x29, #-0x4] > 0x2023c <+16>: bl 0x202b0 ; test_setup at = swap_testing.c:74 > 0x20240 <+20>: bl 0x20580 ; symbol stub for: = fork > 0x20244 <+24>: mov w8, wzr > 0x20248 <+28>: stur w0, [x29, #-0x8] > 0x2024c <+32>: stur wzr, [x29, #-0xc] > 0x20250 <+36>: ldur w0, [x29, #-0x8] > 0x20254 <+40>: cmp w8, w0 > 0x20258 <+44>: b.ge 0x20268 ; <+60> at = swap_testing.c > 0x2025c <+48>: sub x0, x29, #0xc ; =3D0xc=20 > 0x20260 <+52>: bl 0x20590 ; symbol stub for: = wait > 0x20264 <+56>: str w0, [sp, #0x10] > 0x20268 <+60>: mov w8, #-0x1 > 0x2026c <+64>: ldur w9, [x29, #-0xc] > 0x20270 <+68>: cmp w8, w9 > 0x20274 <+72>: b.eq 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20278 <+76>: mov w8, wzr > 0x2027c <+80>: ldur w9, [x29, #-0x8] > 0x20280 <+84>: cmp w8, w9 > 0x20284 <+88>: b.gt 0x202a0 ; <+116> at = swap_testing.c:44 > 0x20288 <+92>: ldur w8, [x29, #-0x8] > 0x2028c <+96>: cbnz w8, 0x2029c ; <+112> at = swap_testing.c:42 > 0x20290 <+100>: orr w0, wzr, #0x3c > 0x20294 <+104>: bl 0x205a0 ; symbol stub for: = sleep > 0x20298 <+108>: str w0, [sp, #0xc] > 0x2029c <+112>: bl 0x20348 ; test_check at = swap_testing.c:89 > 0x202a0 <+116>: ldur w0, [x29, #-0x4] > 0x202a4 <+120>: ldp x29, x30, [sp, #0x20] > 0x202a8 <+124>: add sp, sp, #0x30 ; =3D0x30=20 > 0x202ac <+128>: ret =20 >=20 > (lldb) disass -n value > a.out`value: > 0x204cc <+0>: sub sp, sp, #0x10 ; =3D0x10=20 > 0x204d0 <+4>: str x0, [sp, #0x8] > 0x204d4 <+8>: ldrb w8, [sp, #0x8] > 0x204d8 <+12>: mov w1, w8 > 0x204dc <+16>: mov w0, w8 > 0x204e0 <+20>: str w1, [sp, #0x4] > 0x204e4 <+24>: add sp, sp, #0x10 ; =3D0x10=20 > 0x204e8 <+28>: ret =20 >=20 > (lldb) disass -n test_setup > a.out`test_setup: > 0x202b0 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x202b4 <+4>: stp x29, x30, [sp, #0x10] > 0x202b8 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x202bc <+12>: orr x0, xzr, #0x3800 > 0x202c0 <+16>: bl 0x205b0 ; symbol stub for: = malloc > 0x202c4 <+20>: adrp x30, 48 > 0x202c8 <+24>: add x30, x30, #0x0 ; =3D0x0=20 > 0x202cc <+28>: str x0, [x30] > 0x202d0 <+32>: ldr x0, [x30] > 0x202d4 <+36>: cbnz x0, 0x202e4 ; <+52> at = swap_testing.c:78 > 0x202d8 <+40>: orr w0, wzr, #0x6 > 0x202dc <+44>: bl 0x205c0 ; symbol stub for: = raise > 0x202e0 <+48>: str w0, [sp, #0x4] > 0x202e4 <+52>: str xzr, [sp, #0x8] > 0x202e8 <+56>: orr x8, xzr, #0x3800 > 0x202ec <+60>: ldr x9, [sp, #0x8] > 0x202f0 <+64>: cmp x9, x8 > 0x202f4 <+68>: b.hs 0x2033c ; <+140> at = swap_testing.c:81 > 0x202f8 <+72>: ldr x0, [sp, #0x8] > 0x202fc <+76>: bl 0x204cc ; value at = swap_testing.c:72 > 0x20300 <+80>: adrp x30, 48 > 0x20304 <+84>: add x30, x30, #0x0 ; =3D0x0=20 > 0x20308 <+88>: adrp x8, 48 > 0x2030c <+92>: add x8, x8, #0x8 ; =3D0x8=20 > 0x20310 <+96>: ldr x9, [sp, #0x8] > 0x20314 <+100>: add x8, x8, x9 > 0x20318 <+104>: strb w0, [x8] > 0x2031c <+108>: ldr x8, [x30] > 0x20320 <+112>: ldr x9, [sp, #0x8] > 0x20324 <+116>: add x8, x8, x9 > 0x20328 <+120>: strb w0, [x8] > 0x2032c <+124>: ldr x8, [sp, #0x8] > 0x20330 <+128>: add x8, x8, #0x1 ; =3D0x1=20 > 0x20334 <+132>: str x8, [sp, #0x8] > 0x20338 <+136>: b 0x202e8 ; <+56> at = swap_testing.c > 0x2033c <+140>: ldp x29, x30, [sp, #0x10] > 0x20340 <+144>: add sp, sp, #0x20 ; =3D0x20=20 > 0x20344 <+148>: ret =20 >=20 > (lldb) disass -n test_check > a.out`test_check: > 0x20348 <+0>: sub sp, sp, #0x20 ; =3D0x20=20 > 0x2034c <+4>: stp x29, x30, [sp, #0x10] > 0x20350 <+8>: add x29, sp, #0x10 ; =3D0x10=20 > 0x20354 <+12>: b 0x20358 ; <+16> at = swap_testing.c > 0x20358 <+16>: mov w8, wzr > 0x2035c <+20>: adrp x9, 51 > 0x20360 <+24>: add x9, x9, #0x808 ; =3D0x808=20 > 0x20364 <+28>: ldrb w10, [x9] > 0x20368 <+32>: stur w8, [x29, #-0x4] > 0x2036c <+36>: tbnz w10, #0x0, 0x2038c ; <+68> at = swap_testing.c > 0x20370 <+40>: orr x8, xzr, #0x3800 > 0x20374 <+44>: adrp x9, 51 > 0x20378 <+48>: add x9, x9, #0x810 ; =3D0x810=20 > 0x2037c <+52>: ldr x9, [x9] > 0x20380 <+56>: cmp x9, x8 > 0x20384 <+60>: cset w10, lo > 0x20388 <+64>: stur w10, [x29, #-0x4] > 0x2038c <+68>: ldur w8, [x29, #-0x4] > 0x20390 <+72>: tbz w8, #0x0, 0x203ec ; <+164> at = swap_testing.c:95 > 0x20394 <+76>: adrp x8, 51 > 0x20398 <+80>: add x8, x8, #0x810 ; =3D0x810=20 > 0x2039c <+84>: ldr x0, [x8] > 0x203a0 <+88>: bl 0x204cc ; value at = swap_testing.c:72 > 0x203a4 <+92>: adrp x8, 51 > 0x203a8 <+96>: add x8, x8, #0x810 ; =3D0x810=20 > 0x203ac <+100>: adrp x30, 51 > 0x203b0 <+104>: add x30, x30, #0x808 ; =3D0x808=20 > 0x203b4 <+108>: adrp x9, 48 > 0x203b8 <+112>: add x9, x9, #0x8 ; =3D0x8=20 > 0x203bc <+116>: uxtb w0, w0 > 0x203c0 <+120>: ldr x10, [x8] > 0x203c4 <+124>: add x9, x9, x10 > 0x203c8 <+128>: ldrb w11, [x9] > 0x203cc <+132>: cmp w0, w11 > 0x203d0 <+136>: cset w11, ne > 0x203d4 <+140>: and w11, w11, #0x1 > 0x203d8 <+144>: strb w11, [x30] > 0x203dc <+148>: ldr x9, [x8] > 0x203e0 <+152>: add x9, x9, #0x1 ; =3D0x1=20 > 0x203e4 <+156>: str x9, [x8] > 0x203e8 <+160>: b 0x20358 ; <+16> at = swap_testing.c > 0x203ec <+164>: b 0x203f0 ; <+168> at = swap_testing.c > 0x203f0 <+168>: mov w8, wzr > 0x203f4 <+172>: adrp x9, 51 > 0x203f8 <+176>: add x9, x9, #0x818 ; =3D0x818=20 > 0x203fc <+180>: ldrb w10, [x9] > 0x20400 <+184>: str w8, [sp, #0x8] > 0x20404 <+188>: tbnz w10, #0x0, 0x20424 ; <+220> at = swap_testing.c > 0x20408 <+192>: orr x8, xzr, #0x3800 > 0x2040c <+196>: adrp x9, 51 > 0x20410 <+200>: add x9, x9, #0x820 ; =3D0x820=20 > 0x20414 <+204>: ldr x9, [x9] > 0x20418 <+208>: cmp x9, x8 > 0x2041c <+212>: cset w10, lo > 0x20420 <+216>: str w10, [sp, #0x8] > 0x20424 <+220>: ldr w8, [sp, #0x8] > 0x20428 <+224>: tbz w8, #0x0, 0x20488 ; <+320> at = swap_testing.c > 0x2042c <+228>: adrp x8, 51 > 0x20430 <+232>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20434 <+236>: ldr x0, [x8] > 0x20438 <+240>: bl 0x204cc ; value at = swap_testing.c:72 > 0x2043c <+244>: adrp x8, 51 > 0x20440 <+248>: add x8, x8, #0x820 ; =3D0x820=20 > 0x20444 <+252>: adrp x30, 51 > 0x20448 <+256>: add x30, x30, #0x818 ; =3D0x818=20 > 0x2044c <+260>: adrp x9, 48 > 0x20450 <+264>: add x9, x9, #0x0 ; =3D0x0=20 > 0x20454 <+268>: uxtb w0, w0 > 0x20458 <+272>: ldr x9, [x9] > 0x2045c <+276>: ldr x10, [x8] > 0x20460 <+280>: add x9, x9, x10 > 0x20464 <+284>: ldrb w11, [x9] > 0x20468 <+288>: cmp w0, w11 > 0x2046c <+292>: cset w11, ne > 0x20470 <+296>: and w11, w11, #0x1 > 0x20474 <+300>: strb w11, [x30] > 0x20478 <+304>: ldr x9, [x8] > 0x2047c <+308>: add x9, x9, #0x1 ; =3D0x1=20 > 0x20480 <+312>: str x9, [x8] > 0x20484 <+316>: b 0x203f0 ; <+168> at = swap_testing.c > 0x20488 <+320>: adrp x8, 51 > 0x2048c <+324>: add x8, x8, #0x808 ; =3D0x808=20 > 0x20490 <+328>: ldrb w9, [x8] > 0x20494 <+332>: tbz w9, #0x0, 0x204a4 ; <+348> at = swap_testing.c > 0x20498 <+336>: orr w0, wzr, #0x6 > 0x2049c <+340>: bl 0x205c0 ; symbol stub for: = raise > 0x204a0 <+344>: str w0, [sp, #0x4] > 0x204a4 <+348>: adrp x8, 51 > 0x204a8 <+352>: add x8, x8, #0x818 ; =3D0x818=20 > 0x204ac <+356>: ldrb w9, [x8] > 0x204b0 <+360>: tbz w9, #0x0, 0x204c0 ; <+376> at = swap_testing.c:105 > 0x204b4 <+364>: orr w0, wzr, #0x6 > 0x204b8 <+368>: bl 0x205c0 ; symbol stub for: = raise > -> 0x204bc <+372>: str w0, [sp] > 0x204c0 <+376>: ldp x29, x30, [sp, #0x10] > 0x204c4 <+380>: add sp, sp, #0x20 ; =3D0x20=20 > 0x204c8 <+384>: ret =20 >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r314638M arm64 = aarch64 1200023 1200023 >=20 > buildworld buildlkernel did not have MALLOC_PRODUCTION=3D defined. The = kernel is a > non-debug kernel. (Previous to these experiments my other corruption = examples > were not caught by a debug kernel. I'm not hopeful that this simpler = context > would either.) =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue Mar 14 21:04: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 9B24CD0DB60 for ; Tue, 14 Mar 2017 21:04:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 6567C1AF for ; Tue, 14 Mar 2017 21:04:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x232.google.com with SMTP id l7so8015282ioe.3 for ; Tue, 14 Mar 2017 14:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zxTQShifBP8dwMfQLmZYm+EhcvvFRJs+nk7EbJtzso0=; b=T2iaVmhavNf0uo6C6LMQ+5FT3wGmy6iy72+rogp7mHoobpGDbjFXH6LfJv5Bd6icNP B0xv+hfxb6oLrXZpi3F8aZvamIOzPzFKWPO4JRAvXP7ba0nbn4yU+aTLMfLQwNiSEE2p ix8FZAXmBePzP2UTG1Pw9ey4+ugNxWorGR/XRN/z+Yze1r/96DYm/Nuhn/cqrkfTCn8a J+4kVsUC7zlY7UfHRGPHrGkdgMjia+Sxlk1uzSgYUX979i4EJFNZ1+oUS7qPH8Nv6oCt JtFV3fwzjzpyEhBbHB8twDVXFh/Bfbmtj5nTxzRVU4PZehWuGMgRLx59WuE/AVnytkAC VP9A== 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=zxTQShifBP8dwMfQLmZYm+EhcvvFRJs+nk7EbJtzso0=; b=JxfumXKt2CyqP6DrYR7xNX5Mu6Z+UQx1Lckon4z+Y3oIP1w6vZ2w1hvLToU1Mityj8 Tk2KRnekGdw1UxXwY04pzhXiW9GMOST8xAAQ6yPuxgrTrCUNbC8oe7x9oRra5jQicOpr jAl08Y3g29gpWN6yEP9w2DoOjJqe1Te5zomCnTzgxUPcSrx4IpS8SIuSPw5Flpcx7ZaU PCRokudRZuYBBXCxauQ+LniVCPgJct2R2CtiBAWX+jpOL40vl+oQfz5bVDgMKy9fIrUr +wdsVmR2JRjlZG2exNTsxbdZAeZZeh1qpPQzrP2tKCADbVLb3BtLFkf0IGf64f/Zyore Dtyg== X-Gm-Message-State: AFeK/H1fQ91ffcPxcQgwJTyGOSTLqquSA0qxBfKF9V5k0JIZhViPf3N50KPzVciSq+HnMkYPhMu0KwZTc328iA== X-Received: by 10.107.201.196 with SMTP id z187mr2337399iof.172.1489525459770; Tue, 14 Mar 2017 14:04:19 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.39.195 with HTTP; Tue, 14 Mar 2017 14:03:59 -0700 (PDT) In-Reply-To: <3d4e6e20-d41b-e4de-7ea9-589ed7882171@denninger.net> References: <3d4e6e20-d41b-e4de-7ea9-589ed7882171@denninger.net> From: Ed Maste Date: Tue, 14 Mar 2017 17:03:59 -0400 X-Google-Sender-Auth: FIwW5YmVVTvdDhqtTdnSneylEto Message-ID: Subject: Re: PI3 build failure on 315244 To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:04:20 -0000 On 14 March 2017 at 11:50, Karl Denninger wrote: > Fails here: > > --- all_subdir_tests --- > In file included from > /pics/CrossBuild-12/src/tests/sys/geom/class/eli/hmac_test.c:5: > In file included from /sys/sys/param.h:90: > /sys/sys/types.h:253:9: error: unknown type name '__vm_ooffset_t'; did > you mean '__vm_offset_t'? > typedef __vm_ooffset_t vm_ooffset_t; > ^~~~~~~~~~~~~~ > __vm_offset_t > /pics/Crochet-work/obj/arm64.aarch64/pics/CrossBuild-12/src/tmp/usr/include/machine/_types.h:90:20: > note: '__vm_offset_t' declared here > typedef __uint64_t __vm_offset_t; > ^ > In file included from > /pics/CrossBuild-12/src/tests/sys/geom/class/eli/hmac_test.c:5: > In file included from /sys/sys/param.h:90: > /sys/sys/types.h:255:9: error: unknown type name '__vm_pindex_t' > typedef __vm_pindex_t vm_pindex_t; > ^ Was this a -DNO_CLEAN (or equivalent) build? As of r313194[1] vm_ooffset_t and vm_pindex_t should be __int64_t. I reproduced the same failure locally with -DNO_CLEAN, and the tmp/sys/sys/_types.h in my objdir was updated to remove the __vm_ooffset_t typedef, but the sys/sys/types.h was not updated. [1] https://reviews.freebsd.org/rS313194 From owner-freebsd-arm@freebsd.org Tue Mar 14 21:57: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 42BC1D0D010 for ; Tue, 14 Mar 2017 21:57:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id F157A11DD for ; Tue, 14 Mar 2017 21:57:34 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id AB6142143AD for ; Tue, 14 Mar 2017 16:57:33 -0500 (CDT) Subject: Re: PI3 build failure on 315244 References: <3d4e6e20-d41b-e4de-7ea9-589ed7882171@denninger.net> To: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: <6543fbcc-fb40-36e9-3934-5b39fb47e668@denninger.net> Date: Tue, 14 Mar 2017 16:57:16 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020005000007030005030400" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:57:35 -0000 This is a cryptographically signed message in MIME format. --------------ms020005000007030005030400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/14/2017 16:03, Ed Maste wrote: > On 14 March 2017 at 11:50, Karl Denninger wrote: >> Fails here: >> >> --- all_subdir_tests --- >> In file included from >> /pics/CrossBuild-12/src/tests/sys/geom/class/eli/hmac_test.c:5: >> In file included from /sys/sys/param.h:90: >> /sys/sys/types.h:253:9: error: unknown type name '__vm_ooffset_t'; did= >> you mean '__vm_offset_t'? >> typedef __vm_ooffset_t vm_ooffset_t; >> ^~~~~~~~~~~~~~ >> __vm_offset_t >> /pics/Crochet-work/obj/arm64.aarch64/pics/CrossBuild-12/src/tmp/usr/in= clude/machine/_types.h:90:20: >> note: '__vm_offset_t' declared here >> typedef __uint64_t __vm_offset_t; >> ^ >> In file included from >> /pics/CrossBuild-12/src/tests/sys/geom/class/eli/hmac_test.c:5: >> In file included from /sys/sys/param.h:90: >> /sys/sys/types.h:255:9: error: unknown type name '__vm_pindex_t' >> typedef __vm_pindex_t vm_pindex_t; >> ^ > Was this a -DNO_CLEAN (or equivalent) build? > > As of r313194[1] vm_ooffset_t and vm_pindex_t should be __int64_t. I > reproduced the same failure locally with -DNO_CLEAN, and the > tmp/sys/sys/_types.h in my objdir was updated to remove the > __vm_ooffset_t typedef, but the sys/sys/types.h was not updated. > > [1] https://reviews.freebsd.org/rS313194 Yes, but shouldn't have mattered because I cleared the entire work directory (since I updated the source just before starting the build.) Just rm -rf'd the work directory and re-ran with the -DNO_CLEAN commented out -- no change, still fails in the same place. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020005000007030005030400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMTQyMTU3MTZaME8GCSqGSIb3DQEJBDFCBEBSPl7r FevYPI5UogQEjnLtUUtvLAegLzepPOO+lqWv8GgpDB02PhKuEdYsaaO4GPrz70KBHjYUI5sz kkUzphKBMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAGBi9h9RIZBTL +rRZB/t51yhklLeItsayt9H+TCB3gt+YtTdiHEQtXvbGW7y40oVdx/QxaBw1lif1eFnTsla2 MAQRVUsqkAfF9SEnctC0k28YqOfAl+uAlOm8dcGTDoQTcHmvyO3elJ7t18QNqGsGk+XPk9CM WRhxGv449Ervg/UK3bYlucKozASnAQ3Wg3bysAfXRA5kbHX4cG6vfbMT4F6iijdaG7TRMk4a Ks+8GM2bdoLjPshh2P8WFwUrcw5je11FIlz4Ug41ORBQCxopCO3Ui9QB117oHFyyeFHHWMX3 rks2kSiouiYVgyWNrahTAI/K/T3ttqdLToFkbdd0aOtzqtIA8BJ9etIWX0GWmrFq9e8rN/K4 WHXXDg3mQnBbt9yt5lIQtv+kzCMigI/EMikHkZJ3neIGwtWq2G+prBMaVxW8YGphAC+EqSLt Nkm1IwEHaYrAghgWMf5K8//9wqOPulyrjzCkzaAL7k7+rM9JZt82fsVTy1XjG5FeQg62b9zs zwDnHCKTj6FufBJwDkgPbIdwx+Lf8cB/p9iewFOhp2PsTA6ZpdRszrpFrKPgEOUrABSVWPeX zfeBkPAf5uzjGnFsXAW174pZMn3AMxd2eg0mdCQRQd/hqDzlJ/tQDZuF2PxysjrYozjwlgRZ Tz1J62xdC/wcLdYNsLKuzlUAAAAAAAA= --------------ms020005000007030005030400-- From owner-freebsd-arm@freebsd.org Tue Mar 14 22:28: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 891F2D0D7E9 for ; Tue, 14 Mar 2017 22:28:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-179.reflexion.net [208.70.211.179]) (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 49C8215E7 for ; Tue, 14 Mar 2017 22:28:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31079 invoked from network); 14 Mar 2017 22:28:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Mar 2017 22:28:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 18:28:55 -0400 (EDT) Received: (qmail 26886 invoked from network); 14 Mar 2017 22:28:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Mar 2017 22:28:55 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 4CAC6EC8159; Tue, 14 Mar 2017 15:28:54 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] Date: Tue, 14 Mar 2017 15:28:53 -0700 References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> To: Andrew Turner , freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List In-Reply-To: <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:28:57 -0000 [test_check() between the fork and the wait/sleep prevents the failure from occurring. Even a small access to the memory at that stage prevents the failure. Details follow.] On 2017-Mar-14, at 11:07 AM, Mark Millard wrote: > [This is just a correction to the subject-line text to say arm64 > instead of amd64.] >=20 > On 2017-Mar-14, at 12:58 AM, Mark Millard wrote: >=20 > [Another correction I'm afraid --about alternative program variations > this time.] >=20 > On 2017-Mar-13, at 11:52 PM, Mark Millard wrote: >=20 >> I'm still at a loss about how to figure out what stages are messed >> up. (Memory coherency? Some memory not swapped out? Bad data swapped >> out? Wrong data swapped in?) >>=20 >> But at least I've found a much smaller/simpler example to demonstrate >> some problem with in my Pine64+_ 2GB context. >>=20 >> The Pine64+ 2GB is the only amd64 context that I have access to. >=20 > Someday I'll learn to type arm64 the first time instead of amd64. >=20 >> The following program fails its check for data >> having its expected byte pattern in dynamically >> allocated memory after a fork/swap-out/swap-in >> sequence. >>=20 >> I'll note that the program sleeps for 60s after >> forking to give time to do something else to >> cause the parent and child processes to swap >> out (RES=3D0 as seen in top). >=20 > The following about the extra test_check() was > wrong. >=20 >> Note the source code line: >>=20 >> // test_check(); // Adding this line prevents failure. >>=20 >> It seem that accessing the region contents before forking >> and swapping avoids the problem. But there is a problem >> if the region was only written-to before the fork/swap. There is a place that if a test_check call is put then the problem does not happen at any stage: I tried putting a call between the fork and the later wait/sleep code: int main(void) { test_setup(); test_check(); // Before fork() [passes] pid_t pid =3D fork(); int wait_status =3D 0;; // test_check(); // After fork(); before wait/sleep.=20 // If used it prevents failure later! if (0 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 5BCF7D0DBC7; Tue, 14 Mar 2017 23:47:20 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5DC81CE9; Tue, 14 Mar 2017 23:47:19 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id v2ENihnU040775 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Mar 2017 00:44:43 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id v2ENifKN051896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Mar 2017 00:44:41 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id v2ENiecG025847; Wed, 15 Mar 2017 00:44:40 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v2ENicbl025846; Wed, 15 Mar 2017 00:44:38 +0100 (CET) (envelope-from ticso) Date: Wed, 15 Mar 2017 00:44:38 +0100 From: Bernd Walter To: Mark Millard Cc: Andrew Turner , freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] Message-ID: <20170314234437.GA25820@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.507 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 23:47:20 -0000 On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: > [test_check() between the fork and the wait/sleep prevents the > failure from occurring. Even a small access to the memory at > that stage prevents the failure. Details follow.] Maybe a stupid question, since you might have written it somewhere. What medium do you swap to? I've seen broken firmware on microSD cards doing silent data corruption for some access patterns. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Mar 15 01:19:00 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 2A219D0A1CE for ; Wed, 15 Mar 2017 01:19:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-181.reflexion.net [208.70.211.181]) (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 CECBE117A for ; Wed, 15 Mar 2017 01:18:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 626 invoked from network); 15 Mar 2017 01:18:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Mar 2017 01:18:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Tue, 14 Mar 2017 21:18:58 -0400 (EDT) Received: (qmail 13043 invoked from network); 15 Mar 2017 01:18:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Mar 2017 01:18:58 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 40CE3EC7652; Tue, 14 Mar 2017 18:18:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <20170314234437.GA25820@cicely7.cicely.de> Date: Tue, 14 Mar 2017 18:18:56 -0700 Cc: Andrew Turner , freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: <830B8C57-C9B0-4902-94D2-A8E7F1CB9ADB@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> <20170314234437.GA25820@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 01:19:00 -0000 On 2017-Mar-14, at 4:44 PM, Bernd Walter wrote: > On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: >> [test_check() between the fork and the wait/sleep prevents the >> failure from occurring. Even a small access to the memory at >> that stage prevents the failure. Details follow.] > > Maybe a stupid question, since you might have written it somewhere. > What medium do you swap to? > I've seen broken firmware on microSD cards doing silent data > corruption for some access patterns. The root filesystem is on a USB SSD on a powered hub. Only the kernel is from the microSD card. I have several examples of the USB SSD model and have never observed such problems in any other context. The original issue that started this investigation has been reported by several people on the lists: Failed assertion: "tsd_booted" on arm64 specifically, no other contexts so far as I know. Earlier I had discovered that: A) I could use a swap-in to cause the messages from instances of sh or su that had swapped out earlier. B) The core dumps showed that a large memory region containing the global tsd_booted had all turned to be zero bytes. The assert is just exposing one of those zeros. (tsd_booted is from jemalloc that is in a .so that is loaded.) This prompted me to look for simpler contexts involving swapping that also show memory corruption. So far I've only managed to produce corrupted memory when fork and later swapping are both involved. Being a shared library global is not a requirement for the problem, although such contexts can have an issue. I've not made a simpler example of that yet, although I tried. I have not explored vfork, rfork, or any other alternatives. So far all failure examples end up with zeroed memory when the memory does not match the original pattern from before the fork. At least that is what the core dumps show for all examples that I've looked at. See bugzilla 217138 and 217239. In some respects this example is more analogous to the 217239 context as I remember. My tests on amd64, armv6 (really -mcpu=cortex-a7 so armv7), and powerpc64 have never produced any problems, including never getting the failed assertion. Only arm64. (But I've access to only one arm64 system, a Pine64+ 2GB.) Prior to this I tracked down a different arm64 problem to the fork_trampline code (for the child process) modifying a system register but in a place allowing interrupts that could also change the value. Andrew Turner fixed that one at the time. For this fork/swapping kind of issue I'm not sure that I'll be able to do more than provide the simpler example and the steps that I used. My isolating the internal stage(s) and specific problem(s) at the code level of detail does not seem likely. But whatever is found needs to be able to explain the contrast with an access after the fork but before the swap preventing the failing behavior. So what I've got so far hopefully does provide some hints to someone. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Mar 15 04:08: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 BDAE3D0D03F for ; Wed, 15 Mar 2017 04:08:53 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F4181DEC for ; Wed, 15 Mar 2017 04:08:53 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-qt0-x230.google.com with SMTP id r45so3985920qte.3 for ; Tue, 14 Mar 2017 21:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LQzX9yq/u00FyAciiSzvotSjDwglk1g9R/MdNQ6sfmw=; b=HeXtA6C0fhVdn7AZce1D2sq3/w4OfTIr4wI1U4z2HYZ9FnIn+qpI1UrcC53wcaS6VE yR6qwN/TOEFv/+2ICeTOBAOlcCY/RHVGrvpcLi2WixoiUzwoGyHebddnvS+RrLJfo4Ey 4g1+iOKftPGHxzQfHUWV6o50uo1rjk5jWUQl1DR/XhHZbECIwzG4KzxYvOt5JC6te0Vj adXwmTWB5LMkrk79setCh4rH5AiIRAOf7636pgp0/Dnnklu8R4txExtT9OHIq85p2rLO 96X9zKe8uPSlG7dtaPe7fqotYnSOMowhKfKe1X/3wVlErZf8I3co7VkJqXmEuD3urWFe C9kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LQzX9yq/u00FyAciiSzvotSjDwglk1g9R/MdNQ6sfmw=; b=BhMZNWrCLmxUMr3xhb4vlQ7IS2vsGveDnrJef2TRW36cPp5Oc49HdKfVjzsLB5NGee iqBc8y9YWQq6AZqjIbwu1yjkAYDDSatyeqoz7resxA2eNwu98UDDA0+oErZ0TBh/Wc6G T1t7F3K0v9D/BjhmH56OKMGNTXzfrsRusNYWuQkL/7j7qZcmU2XcbiXWQ/9KkQq75gdU IOC08rIx3lkkjTlTaC4jkFjgfByibWjKeyYNNJPr3bO4xNKusWzPrvRrR6VvWht6FurU IhcXsAgIO3LGCZsXnYDUS+xyZuea9eTV2HdMrI7ySIa7C/56+mS7BaHpHyY0GUDUiUTx 12Ww== X-Gm-Message-State: AFeK/H1sHtPjF84FGHESB2y78TqkvSVtPKUvmyo1Hd0Nghv0IpMA208N7Omh62F68brStRJXoGZQjn7wTD2Ovw== X-Received: by 10.237.54.100 with SMTP id e91mr967135qtb.224.1489550931896; Tue, 14 Mar 2017 21:08:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.116 with HTTP; Tue, 14 Mar 2017 21:08:21 -0700 (PDT) From: Jia-Shiun Li Date: Wed, 15 Mar 2017 12:08:21 +0800 Message-ID: Subject: portsnap failing on armv6 To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 04:08:53 -0000 Interestingly it does not fail on aarch64 or amd64. Only armv6. # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. Fetching public key from ec2-ap-northeast-1.portsnap.freebsd.org... done. Fetching snapshot tag from ec2-ap-northeast-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Tue Mar 14 08:07:45 CST 2017: 1ef35c58b905caf4c1ef8cf618bf3185c13b82fe73f0aa100% of 75 MB 142 kBps 09m02s Extracting snapshot... done. Verifying snapshot integrity... lam: unable to limit rights on: -: Function not implemented unexpected files in snapshot. # uname -a FreeBSD rpi2 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315196: Tue Mar 14 00:39:42 CST 2017 jsli@4cbsd:/personal/freebsd/ obj/x64/arm.armv6/personal/freebsd/fbsdsrc/sys/RPI2-NODEBUG arm -Jia-Shiun From owner-freebsd-arm@freebsd.org Wed Mar 15 04:18: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 A4E14D0D4C0 for ; Wed, 15 Mar 2017 04:18:32 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0060.outbound.protection.outlook.com [104.47.32.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BB691373; Wed, 15 Mar 2017 04:18:31 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GO6uxTVDViI+U1SPHOlw8CVCMLEJTdSTE8UfODgrV58=; b=RG5+Fz4cXyjrBDcYDXBW8rXUA8O+ckyqbhQanlyTAUZ3VcpxMzddT7VO6H/NbxFSVTbNmzlRIvwn4ts2zxe+WMrongaGt+zdvkIYqkWvgk1B1O1Q2bKyzMdyWe098QqPpt18LU4FGmK4iOqGRt6AIZuyhLgHRIMSGclVUWI/cwk= Received: from CO2PR05CA0054.namprd05.prod.outlook.com (10.166.88.150) by SN1PR0501MB1741.namprd05.prod.outlook.com (10.163.130.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 04:18:29 +0000 Received: from CY1NAM02FT029.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e45::209) by CO2PR05CA0054.outlook.office365.com (2603:10b6:102:2::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5 via Frontend Transport; Wed, 15 Mar 2017 04:18:29 +0000 Authentication-Results: spf=pass (sender IP is 129.130.18.151) smtp.mailfrom=ksu.edu; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ksu.edu; Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp2.campus.ksu.edu; Received: from ome-vm-smtp2.campus.ksu.edu (129.130.18.151) by CY1NAM02FT029.mail.protection.outlook.com (10.152.75.143) with Microsoft SMTP Server id 15.1.961.10 via Frontend Transport; Wed, 15 Mar 2017 04:18:28 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp2.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id v2F4IRac012040; Tue, 14 Mar 2017 23:18:28 -0500 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id B4821248006; Tue, 14 Mar 2017 23:18:27 -0500 (CDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id 606B4248309; Tue, 14 Mar 2017 23:18:25 -0500 (CDT) Received: by mail-wm0-f50.google.com with SMTP id t189so13454632wmt.1; Tue, 14 Mar 2017 21:18:25 -0700 (PDT) X-Gm-Message-State: AFeK/H0kpY74hGpcOUx9wY0TuVi/59Y5LlvrYo3j7xQJKDLXD2UBhrrxuI1uJStLnskqGHyjlXasNPT33N1n7g== X-Received: by 10.28.84.18 with SMTP id i18mr2599879wmb.12.1489551503882; Tue, 14 Mar 2017 21:18:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.9.77 with HTTP; Tue, 14 Mar 2017 21:18:03 -0700 (PDT) In-Reply-To: References: From: Kyle Evans Date: Tue, 14 Mar 2017 23:18:03 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: portsnap failing on armv6 To: Jia-Shiun Li CC: "freebsd-arm@freebsd.org" , Baptiste Daroussin Content-Type: text/plain; charset="UTF-8" X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(2980300002)(438002)(377454003)(189002)(24454002)(199003)(2950100002)(6246003)(90966002)(38730400002)(46386002)(110136004)(5820100001)(23676002)(6862004)(45336002)(9686003)(1411001)(4326008)(558084003)(54906002)(189998001)(61266001)(9896002)(498394004)(98316002)(450100002)(2906002)(50466002)(356003)(5660300001)(61726006)(86362001)(75432002)(42186005)(93516999)(305945005)(8936002)(106466001)(55446002)(88552002)(229853002)(63696999)(50986999)(54356999)(76176999)(53546007)(8676002)(55456009); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0501MB1741; H:ome-vm-smtp2.campus.ksu.edu; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1NAM02FT029; 1:uTIE88mZI6d6uV0JzkSyzxof7I5QFOBUM5BIjGo6EW0MEkJgm2advZ0DKKUHrF8hXChUawKAxPQ6j+ZVJdDhYqbEfRnsGobNvR9j79U2+vG/K3it9ZUdYWgv0wEBE3InQyh+rnF0MP7uP4YNQ4bZPzWpk7mfjoDBWj3BoNpkjCXPjnxoBUrE6VDNSHBKgi0YuD300NnIqbztK9QZZwcXVNULKiESezhtpzc3Z4hcGHt+Fhp3IDaVdQvtrmCQZmFrzhSsHgFdGBC9/PKUE1+//3DjdHwjTFT/Te5XxZB04vb3DQI/8LGsrEkMJfeaTk28nkHh4QabOPYZS8xi4Ifa5NNknKWR44Gl0XOy1fTJK87X7diWv+3i7e2/AOmm6QC49jBM3FA/cokhj+3k42HhCwhGxsw8eUjWwPsyuQDcwD0gPX6vaaiFjZRJtTxomobE5zyuVs6nzQ13tWFYQWFcDsazOTUPezYXR39kMC+FwF8zsnJRQ7uzRZerqnDyUc/M4/691ZJCwpcCfWo78eu05FrEYQ1XfxicQlIOSF4Vp4KyNvtPciKBH0A9hw5vyEkn X-MS-Office365-Filtering-Correlation-Id: d2eb40d0-5de7-4395-a7ed-08d46b5a552a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:SN1PR0501MB1741; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1741; 3:flNRkQEW8hcTW+KtH4oukPo78CVUAUxnrn9K5aXOOVTQ8i85J6d5nzznpA+PFltzJ0j4kllrRwVskBNeEWafvQ0dGPyYqQgd3jY1zhwvxU/FC+D0sUD8KOWC0N9XzE4tZWnkBUvSr+73oUBKojDLK6qmr9SbXmGcETUpr1QPQu3lznftRqTTDe6AtcaDLHhHtnLGKLXoqKb0od7xOJDn4HnqxsUGrFRSqAeKqQngCxkMPJd43oS76eFi6L0jrE28wDWsabEkl4eub8P2oRexEWrtpXdI/QMncm+bRq/6rmPvxIsaGG5ynIZG5qeutzflxCISUcuoQiBkkU+sIhSLIcJ6zD2Zl13NcezVF2hZE+kTXOO42v5mfkPrGRw3yNsZp42QnUYBuA2E5uaNZbIu5Q==; 25:eN7uMdQe6K8ztr61R3sRjxiifJ7wN18DMmzsQpq7MOIf+ybw3+H2/L7hbiRzlhZWSqt/suc3873e1l+gSmmICxE3IcOk2diTq78wwf+tqQfGaqOhhx2IE5/7WfqPutYQYOB1PUXCBkbjtc+3hK0CzngosmYKBahZ9GzS4vG4j4j5jcZL2Yruz7IwMNX0L1uv1z9kytazP9/llvZbLFyVi4haC9cfnewtWw1dKFNxzfGV8If+Tj7n/bZA1xoZCmDct2lIuCV5R4fbfv7nRdrTrdXy8X981bMQS+XosyHU3y29iq4l77U93FlesWE5/yWX19u9P/PMiG4Crgb/8boX5xbsYareMHukJ4cgB8bxVqhnmqtmmmReUaQphDZmvyjK1R1/gQSjl3E3F9lbSKSsZGgreXwY0mwpVWmHNbgEXyzpP/IRtUPgRLfI4Mf4O/kw5tiga3XggKlVbyvKMueJjA== X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1741; 31:BxOFg8r2GP8NYbaaE8hmjVCYtuNBIQKhULzVybsz7AuLwMuDI8EtpMdd4YX+17UgHUTOrRhCtXD7e57qIEmMbbMsFIakIW+jrzVXrPvQta9YjIMuz7yzVuqyLa9mnUKnlQLCZgQ49vwxxH2vI9MRTini5uIK/qb04GfufGkzt0W1y20sK31EqHnllzp39ggRPeGZYxg3PP4WO8LbMZUvvhcgWt8+gX2mwXM7PVVojkGMV1cIN1Isf59TLnkbQGen; 20:n/tM61bG8PeZUHjWrF6+xVcItgGx4EOLe4WrnpDUUDhG3P6aOFFjIpkv6Mx4gUnBA+zGdZu7X8wk/aTgPxHnKArt9IaHEnNJ+k/C9PeydTEvhyBrGEhYrAiFSC/6UGRTEuFKP13Z0yLa9jNBQzZUfs/oN7kIRpHmfl5SZ9e/VV8OfdyuwDhNH8LIhjelzglRtRfVBvmxeg2dHNUmiKNtbU0DgqJEqkFvxBoNPJuaL+m4lQAzpghVvBZ94GI6inFPcgZY7cBrW6WBqGxfP1cSGK9xnZPtTaeAB+F9mlnpIZpWcBsjDyvD98rfL2cqXESnq0jqGIl9gKsJzYI7t+Lpfo9JuP3JVOA9Aayt+MqrJC7AKcDe6Fc4B9jNl8Q8pcMS8tCOWWBsI2H+e8ousIpIHI6OBPoRdRJLPgNxqMheXFUtnWDy70T2RquF7kDAXjrqgy7MQWPhNqyNCbqnCyfn9W0C+oq6LhpoYpb/uNlW2TU1UxJUpvr6gJgk0tG6NGH+ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13015025)(8121501046)(5005006)(13017025)(13018025)(13023025)(13024025)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:SN1PR0501MB1741; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1741; X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1741; 4:C9Xb0+wT0oFXDfkofGYrpsjvUMnN4b4xNf2TWcxVCSu7+0Irhc2hz3W05NZ3oTGf9pT0kuAAi9/M01WJU/MQZ7owCf+EUY34/n9EcgJsQ77U92YK2FtXo0yBydXUBb/TqxNu0lonhMULdpy0Bhv8oxhXb2X7T4r7IjnUYS8pSqwBSIWCdeG2M04v+XHQj6iavJOE40bxiVXoKK/VYGT/VEMDTUzf5jMSSFa+NK77qqZsiPOdiq4UxCBCHV9LQV3fBp1/46LBkXTv/rTSaERKoPC9fhV/IlZHVBmQp/21YknYd/8Abn5YtgB1Aedm3oNLWcA9RhbKfhyz0kiNcf/ZG93Bw34il+Pe0QOTVGAQzMz5aybHko4s9Sb+i2Io9WqcC7Js3tHrMakls7FGJiKXp1iEuTRz/6NSRYYvyJA691+/JT/s8j+4bhR1ceCCVY0gjpUENNfpmZWNQ4Spli0h9B3WgnIeN2pYDRuJ8hYcbpTmawT6zukMPzVyD8AjgB/NgXFzPC792HaLva8KleWbCRnJIaImecC/vp+Cnv3w2MQklQ7GxMCdV/CoWX5/VCPrepOAmwC7g313qxiBnAbM/ZB+1RStMSNx4wxkgU8woRyEzkGgPSoupsRfwei2B6oIxKELAjW1XgjfnsjiiqBuZE0CCbEl/pUAqQKiWwFMDfAC24/BAGopf+qikykvhm+p X-Forefront-PRVS: 02475B2A01 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1MDFNQjE3NDE7MjM6ZGxlRmdGNHY1NFBWUVY3OU5sRUVLU21Y?= =?utf-8?B?ZWQ2byt4aFZYOWhobUFJTHBSd3VKZFVMeis1OWt0ei9LTjFxd3NWZENtbzZv?= =?utf-8?B?WEZ2VEl3c3V5UWFaTEhiQ1VtTUVmWjdFcXBUUlZVZCswWHR4cFdwMHIzVlB3?= =?utf-8?B?OW5tU28rY21yVUdjeVJZSXVSMzEzbGhtcFZtZjVjWkM1dXhkTlNPb1FIbGti?= =?utf-8?B?VTVTNDZWQzhYdFNWYnNUS1pGdjlaS2R3TFloVDBhclM3YmRnNGdOanVJT0JW?= =?utf-8?B?eDYvY0dsQitmVnJQUUJkOVl2MFZuQmhhYk1hdFp2WDVVWDJjY21jNlZtcmtm?= =?utf-8?B?b3dUbUdaTjVHQkxibXBpZTBMd3pHd2NJY3gvdVFndVVzZ0Zma2NITmxFVzc5?= =?utf-8?B?em84U0c4cEQxbHRGTzZDaHU3V1hKL1VwTWdram5lRXZkaWdPYlZDc1NNZ05l?= =?utf-8?B?cDZrcGkwVGFOZGxGQ0hObXBJdGFSS2dFcDRhU2tFRkN2bGtpNVRzRkhlNWhw?= =?utf-8?B?MDk1V1R2ZmdJTWUwZXZTRjhCcjRxV3Jncko1TlJvNGZEdjEzK2VaTWFkczdI?= =?utf-8?B?OG05ejV0eEU1WEtFZG5DWlN6V0lhUnZEQUNOeDVzMkhkMVJDcXYvOGJLbFBU?= =?utf-8?B?ZHRMSTFpRWVnaHpsQ29uWlNyeDMyMHpUS0FBVVRDRWxDWDBtNkdwTkExU3I3?= =?utf-8?B?ejNqRjVhN3NJUG5Ib29hNmp5OFBOc1Nxb3U4N1QxWGlST1hpZkJ4RGw5Q0tS?= =?utf-8?B?dUxqeGN6U2JQbkZWNzh2WXVqaUVvN2wzVk9wdVh2dVU1c0Fyak9JWjJGL3RL?= =?utf-8?B?ejU1OGhWUnZzVzFZK3JBdmJteXZ5akdXVXZYVVpkSWQxVkdmOXZLSkNmTnlh?= =?utf-8?B?bFRucSt2ZHJsTDJnMGVDQ3JuRDY2eUYrTnZZdFpEY1V1VmZmck9RTGk0ZkJy?= =?utf-8?B?Y2RTcGxlR1dhc0JwT3NXUFFLNEkwcFViZUNWUTNTYStCTFpJeGYwY2xPREQ0?= =?utf-8?B?WUVQWnJmRHMrekdxNnFhYnlsMFdQRHAzNDFkT1Vmc3NLRm9hMkthVmdxQ1ZD?= =?utf-8?B?WUlKaUpqYUh2MC9scTdtSHdyNnFuRmFWREdvMy9FY1lIZVpkVE5SRmpXNFdu?= =?utf-8?B?WnVpaUxGTnVBa3JMTVdDeEp0UlZndEgzSllFZktkcVlWLy9yeGE3ekFsbEll?= =?utf-8?B?NS9GejRlSmRhenpLRzJ1OGhmbFRRa3orTERwNHAwbnVDK21QSDh0U0xUb0NQ?= =?utf-8?B?K2kxVUVzUHVubWlvcUN3aWFhTmp1Um5DTG5wY013dkxSVDV2cjhFYitNdGNZ?= =?utf-8?B?MFRiWmlvUkt1bEU0YXhreVFpcmVMMGJ1VnlKYzA1L29NakN2R2dRWUFyd0U0?= =?utf-8?B?UytlaWRTTkhNUENBQlZCQi95Tll5TTBEVkVqejE0MHdCaHg1NHpXcXN0L0Er?= =?utf-8?B?dTZ4NktUWVBYTGZwY2ovMlV1Mlc3NTFmdHNRMGlneThnL3RHU05pTGdqdzJs?= =?utf-8?B?Y1p1VzE5QU83ODBEbzM5MW5Wbm1UaGtHTEdETG9BMWxNTDBCQUp0Q1Byc292?= =?utf-8?B?RjNndTgyb0F3TFhvNUUzTSt2TzYzQjN5WW1Wc1FmbzVLaDhjUndJUUF6NU1H?= =?utf-8?B?cWFEUmxIdi9STENHWVliUld2NEV3aHF4YUcxQ1RTSWkwNzBpN1htNFUzZFE9?= =?utf-8?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1741; 6:vDsH8WNadoXxGfRN79bY7ICIh4aE+aJWVXIDnUgoWAqc+OA1RPjlq4BN+UJRbR0+K66Ob7mbUbWmRd9NKONC40Z2zu93heZZK10KZ+bh6RjXlPRXzojU/LujXGbfJgVLDmT++xSV25vWb0zidt0JjK9GgK4V++9dkEzbuz6c0BO5u/1gSCfEHjNrVQqyCBfZA+M9yOJbXi6p+yHOUOb4Yos4VbaEbD0rhrCsbTwaSXVz6z8FepKkDAJ0cJ8pn+f7bpXQKsyO7pY+kYYdn9KmsVBVO6asK/dQaJHDUvWVbqesatimAKPsLXpQoM0E/qDrSiCZz9cmaNoq9UxqPh9kYsTqB2T3ua+oOtDebZtdrTVOUQj6gzUiO6yB5Irqyue12j9DSMAh2YhvcpIR1QsWFA==; 5:mZKXd2sgl91fcspEB6GDJHvK+SINvmNWTZLoPNGn7rmaUjg22CpzsRNuCcu2yfTjMSa56MiHyKnRD4chq4Ulv3ZeApL1h06dbNL3fCKsZcTVSugW1uWOjL9mQ8mLKSoTskTo2ITMQQgSuRT9zFyg/w==; 24:5+2o1yHGSj8aFTQaJazGbFGBNs2YrgCNFSu8XdO+zJR1+mT5vBgq/88l9MRBUyhmcyhKBJYKGQKOghyFC+zqITQZkXZnDNF78263QyN6YqQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1741; 7:5Q6EGZOgHv8VntwNpQ4JMRrsZ5GDHjKh9wjEw13nPSy6ZJ9bVADfeoMh1BbJQCOb/SVa1tMmUBXT7CoHG8N36llgHtvJ/IjwqVVHXkkYZLrwnDnkPardeD734MwiZmt1r+fLVIHl8nY1+7CF6zKwnHEppfvdE11+m17xBEP+fBVyf/5kPAwD6jkDMrHfx2Ukt56rWnbXmT7hxiBj90+ceoCY4+Gb6DVx/dlEKzWfpch3OHbhmqwuyl1BmzyqaEaI7SWiEoMOxxarqb5B7pMAO3wSs2Y2A/iPPiHF7PddXAkUY45Ru2vuWh2jfVOuXwmTajmyfT001F5LI96yFEaKqA==; 20:wNwKq26ptsa0MKWe7juXnaFc/5I6A3kvScEc5q4+xa3KwEx1tLktxAwCo2tGYgJnt9qEYMNpWc+U8YfIyQ8v1CnjHIkvGmQojHqxubckR7C9XgFgyKMI0b44wV6JftFowVPF6ZPnL6RmnWaGcF+7vjNWbxPe5jMF3lyfXmFwmQ0= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Mar 2017 04:18:28.3982 (UTC) X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp2.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1741 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 04:18:32 -0000 On Tue, Mar 14, 2017 at 11:08 PM, Jia-Shiun Li wrote: > [snip] > Verifying snapshot integrity... lam: unable to limit rights on: -: Function > not implemented Hi, This should be fixed by bapt@ in r315197 =) Thanks, Kyle Evans From owner-freebsd-arm@freebsd.org Wed Mar 15 04:33: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 1AF3BD0D88B for ; Wed, 15 Mar 2017 04:33:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-172.reflexion.net [208.70.211.172]) (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 C98A01D4F for ; Wed, 15 Mar 2017 04:33:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1303 invoked from network); 15 Mar 2017 04:35:38 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 15 Mar 2017 04:35:38 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Wed, 15 Mar 2017 00:33:09 -0400 (EDT) Received: (qmail 1852 invoked from network); 15 Mar 2017 04:33:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Mar 2017 04:33:09 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id DDA81EC8534; Tue, 14 Mar 2017 21:33:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: Date: Tue, 14 Mar 2017 21:33:08 -0700 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> To: Andrew Turner , freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 04:33:12 -0000 A single Byte access to a 4K Byte aligned region between the fork and wait/sleep/swap-out prevents that specific 4K Byte region from having the (bad) zeros. Sounds like a page sized unit of behavior to me. Details follow. On 2017-Mar-14, at 3:28 PM, Mark Millard wrote: > [test_check() between the fork and the wait/sleep prevents the > failure from occurring. Even a small access to the memory at > that stage prevents the failure. Details follow.] >=20 > On 2017-Mar-14, at 11:07 AM, Mark Millard wrote: >=20 >> [This is just a correction to the subject-line text to say arm64 >> instead of amd64.] >>=20 >> On 2017-Mar-14, at 12:58 AM, Mark Millard = wrote: >>=20 >> [Another correction I'm afraid --about alternative program variations >> this time.] >>=20 >> On 2017-Mar-13, at 11:52 PM, Mark Millard = wrote: >>=20 >>> I'm still at a loss about how to figure out what stages are messed >>> up. (Memory coherency? Some memory not swapped out? Bad data swapped >>> out? Wrong data swapped in?) >>>=20 >>> But at least I've found a much smaller/simpler example to = demonstrate >>> some problem with in my Pine64+_ 2GB context. >>>=20 >>> The Pine64+ 2GB is the only amd64 context that I have access to. >>=20 >> Someday I'll learn to type arm64 the first time instead of amd64. >>=20 >>> The following program fails its check for data >>> having its expected byte pattern in dynamically >>> allocated memory after a fork/swap-out/swap-in >>> sequence. >>>=20 >>> I'll note that the program sleeps for 60s after >>> forking to give time to do something else to >>> cause the parent and child processes to swap >>> out (RES=3D0 as seen in top). >>=20 >> The following about the extra test_check() was >> wrong. >>=20 >>> Note the source code line: >>>=20 >>> // test_check(); // Adding this line prevents failure. >>>=20 >>> It seem that accessing the region contents before forking >>> and swapping avoids the problem. But there is a problem >>> if the region was only written-to before the fork/swap. >=20 > There is a place that if a test_check call is put then the > problem does not happen at any stage: I tried putting a > call between the fork and the later wait/sleep code: I changed the byte sequence patterns to avoid zero values since the bad values are zeros: static value_type value(size_t v) { return (value_type)((v&0xFEu)|0x1u); = } // value now avoids the zero value since the failures // are zeros. With that I can then test accurately what bytes have bad values vs. do not. I also changed to: void partial_test_check(void) { if (value(0u)!=3Dgbl_region.array[0]) raise(SIGABRT); if (value(0u)!=3D(*dyn_region).array[0]) raise(SIGABRT); } since previously [0] had a zero value and so I'd used [1]. On this basis I'm now using the below. See the comments tied to partial_test_check() calls: extern void test_setup(void); // Sets up the memory byte = patterns. extern void test_check(void); // Tests the memory byte patterns. extern void partial_test_check(void); // Tests just [0] of each region // (gbl_region and dyn_region). int main(void) { test_setup(); test_check(); // Before fork() [passes] pid_t pid =3D fork(); int wait_status =3D 0;; // After fork; before waitsleep/swap-out. if (0=3D=3Dpid) partial_test_check(); // Even the above is sufficient by // itself to prevent failure for // region_size 1u through // 4u*1024u! // But 4u*1024u+1u and above fail // with this access to memory. // The failing test is of // (*dyn_region).array[4096u]. // This test never fails here. if (0 This suggests to me that the small access is forcing one or more = things to > be initialized for memory access that fork is not establishing of = itself. > It appears that if established correctly then the swap-out/swap-in > sequence would work okay without needing the manual access to the = memory. >=20 >=20 > So far via this test I've not seen any evidence of problems with the = global > region but only the dynamically allocated region. >=20 > However, the symptoms that started this investigation in a much more > complicated context had an area of global memory from a .so that ended > up being zero. >=20 > I think that things should be fixed for this simpler context first and > that further investigation of the sh/su related should wait to see = what > things are like after this test case works. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Mar 15 04:39:37 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 949D9D0DABB for ; Wed, 15 Mar 2017 04:39:37 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 505301082; Wed, 15 Mar 2017 04:39:37 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-qk0-x22e.google.com with SMTP id y76so4565389qkb.0; Tue, 14 Mar 2017 21:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hhVSJkwYngxhcBIZ0HZKbJNoxhDcSHSK3D2RHXAPTG4=; b=SwbjxwP8re1WZFA6KFbWVHYwUYfKXK/K8yajJebHiX/tdCAj5M/cuY11poYkigpDVY sT4ppP8ZwsshQeF3EixFWZqoNBJtWgmGz1nzu8HX91qAJl6P/w1hKp4/fe4Vg4YNX5JH MGJjEWWLuxHvAqkqIcmyCQLWIFciZWuVxx97XJ4LZ4w7Fj4Yp82+wmsZ9tMxiwiz4gMs YvLFaAoxkiPPaTiQNgSlunLq+p5I5ovGtgjn+/CZlMQOQx6yndXeBP7B8Ab9yHo+orur 0wPg8jwWK55j/HX1BrNmzFv1f5hxgop6W+Que3n1g4q+DZgr9ZvKkwgf7y30g3pPfAhX 7jQw== 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=hhVSJkwYngxhcBIZ0HZKbJNoxhDcSHSK3D2RHXAPTG4=; b=cl1Je4bdwnxp0rTzNHY6Yw3P0GBsbznXtcuGKluuPs1N+oORQR2+v3VRdb+9vQXDbV gTwd4S3kI2dH58B92FTRVkkKqBBaXGywkexJ6G/5eJ1DWNlGFpYmAsjuhc8U8XEBxtnV jSkHd8MSo79MfysnDttPN9/hCj07Ced/SOxb1ADFfMp35BluWBZSWAukl5Z+JDbeYfVI jHBLGv0NSCfg1qDY44whI6f/kSd6ODiyW00R/HZNc7OmIyqK19GLFEM4RdRPFCzuTKPo r9BcvN+uwNOSisZ2de9g04s7CyLuoVu896kIL6J+MLpSWsFtIfSa8qyMdtY/OWfn6Y8i 6mWw== X-Gm-Message-State: AFeK/H0id7OFyQZr5lRJzqdKbZadfxW0Y+/DmI/NZy0Y+LmcYFhIOH+YS6IsYLNvh1q2o3O593sCcvzMZdWaZA== X-Received: by 10.55.20.131 with SMTP id 3mr1109330qku.320.1489552776347; Tue, 14 Mar 2017 21:39:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.116 with HTTP; Tue, 14 Mar 2017 21:39:05 -0700 (PDT) In-Reply-To: References: From: Jia-Shiun Li Date: Wed, 15 Mar 2017 12:39:05 +0800 Message-ID: Subject: Re: portsnap failing on armv6 To: Kyle Evans Cc: "freebsd-arm@freebsd.org" , Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 04:39:37 -0000 Thank you. And Baptiste. I was lucky enough to get it just before the commit. ;) Will try later. Jia-Shiun. On Wed, Mar 15, 2017 at 12:18 PM, Kyle Evans wrote: > On Tue, Mar 14, 2017 at 11:08 PM, Jia-Shiun Li wrote: > > [snip] > > Verifying snapshot integrity... lam: unable to limit rights on: -: > Function > > not implemented > > Hi, > > This should be fixed by bapt@ in r315197 =) > > Thanks, > > Kyle Evans > From owner-freebsd-arm@freebsd.org Wed Mar 15 10:01:23 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 C5D60D0DC45 for ; Wed, 15 Mar 2017 10:01:23 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d: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 81B49F05; Wed, 15 Mar 2017 10:01:23 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-qk0-x232.google.com with SMTP id p64so8579420qke.1; Wed, 15 Mar 2017 03:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WVExiFM1qeY/WXzFaevx9/d5WiKERRQOv6K6CQqwEtk=; b=JEe6SEq8Zjc1q5hbUfjohYDVr+duJxA8UhsXCiZgaw8X981gopZjCYikO6K2Ur4Tcv nt/PA9sCU1b5HLuk9zbVGDXOryh41Xp93YbURY3Q3/j6WnZbDpvcCLUqjvf1licdZWWj Zy5+3G/PRscEf2xYbxtjthglxYxyWBFLPmmsgs0pkU0LUMXgSF9oVzDHhY/o1XERjSpe 0ZEGsfaSbzjb5ZsL6MEN7oDIhNoyOdkqYuLLSY6mdVYjbxRWu2Cyxn94zwqoGPmod+rl 5R3IhBVQ2jnpyUx9pUuV+fW2jmku5nHoGxxIBNBy+lVaDzYVtKZyrBvDrfNrg/Ut9ki1 Gxvw== 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=WVExiFM1qeY/WXzFaevx9/d5WiKERRQOv6K6CQqwEtk=; b=WIvJDRv/n272J7tqLyYVxVo+qVqaea7aMp0mRiPcUR8rVHXmReh0QVpC7T1r84zoaT usMZTMiEX1KZjnwxVfQOr0GPGddFlLgnTsHcFl4q05EAZ2oeyC4qBmeDshovxPnuYkGE VHY2gZpryMBVR70NEvRhIln0myY4UM2nm5YeoYM7GJSHC9zh2EP22ArQ9ea+69jvAFzJ I9N/ut3UFLQ6Q0IKYw4K7pMgQr7qnAUsO3OlDSDpb2Fj5qedO82etHpG5kmXnn57Cvrc G0Qg/9MugEeDqKpU1h8RT9eym5iwCLdMTgUoNOw9wxsIn6elVIUjl8wWbY9A6HeBvc+S 5cjg== X-Gm-Message-State: AFeK/H3xezABXxYbTet73eTR8lW+TRBdN1/2RMWPrxDHzTOw4Acinku0eTPGn4h0kHoXQvWWdjsMDxHvSbX8Jw== X-Received: by 10.55.75.19 with SMTP id y19mr1727334qka.25.1489572082237; Wed, 15 Mar 2017 03:01:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.116 with HTTP; Wed, 15 Mar 2017 03:00:51 -0700 (PDT) In-Reply-To: References: From: Jia-Shiun Li Date: Wed, 15 Mar 2017 18:00:51 +0800 Message-ID: Subject: Re: portsnap failing on armv6 To: Kyle Evans Cc: "freebsd-arm@freebsd.org" , Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 10:01:23 -0000 Hi Kyle, I simply rebuilt and replaced diff and the result is the same. According to portsnap source and its output, it suggests lam is to blame, not diff as r315197 implied. Or do I need to build something else? -Jia-Shiun. On Wed, Mar 15, 2017 at 12:39 PM, Jia-Shiun Li wrote: > Thank you. And Baptiste. > > I was lucky enough to get it just before the commit. ;) > > Will try later. > > > Jia-Shiun. > > > On Wed, Mar 15, 2017 at 12:18 PM, Kyle Evans wrote: > >> On Tue, Mar 14, 2017 at 11:08 PM, Jia-Shiun Li >> wrote: >> > [snip] >> > Verifying snapshot integrity... lam: unable to limit rights on: -: >> Function >> > not implemented >> >> Hi, >> >> This should be fixed by bapt@ in r315197 =) >> >> Thanks, >> >> Kyle Evans >> > > From owner-freebsd-arm@freebsd.org Wed Mar 15 11:55: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 4961AD0D471 for ; Wed, 15 Mar 2017 11:55:51 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12FC31ABD for ; Wed, 15 Mar 2017 11:55:51 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x233.google.com with SMTP id m27so64150609iti.0 for ; Wed, 15 Mar 2017 04:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YqnFryryRybGKt+bO2PwUsB56pnCocd+Z7fgLmMSb08=; b=AL79OBXrD5cXqO6agkLCDFmkdPXdsoxlazbzKnUADNH6UZVnz4xJeNb6f1QjslF4Df nZvVQY9L1YNir/V0DYEVG47FGUvfmig9x3dQHwboxJ5F/5JlYn3l5pP6yZE74JNDNXq/ bOXF5upvzNPSJF5hiS9x7cLQSO6cl+c4fz9VjCelOrTbPlj1v3cUpbb/JHBR0aowWDQt 6rEv0rU4278QOceL+bFNv7ZSKVfVRm7uGopz6vVjRxwbv29PA3NN5CUTmEtQkUd/vetL HCqAYceVpavbczZbWm//VDEZsJioynCeMoRwEgC+gjiwsfcFsL0P77Mqs3nBw8dl5lF+ INxA== 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=YqnFryryRybGKt+bO2PwUsB56pnCocd+Z7fgLmMSb08=; b=au/mDUHxeGN8HeUXcmvO+A1/+l4Pj+gQA6Z6cAqDaloYTouuNODILdq4mOIOtF5Vcq 305NtL5TBht5peQvqD+GXQewuZkos0RoEVkfcnlWzIb0qR1wQGsfKTf7Ppf91g4SCLAS YIY3C5lzGkS4eQSxDyk7YJzoFe2zKsN3MUwKgmRD6r7Jut2R42/k7CpnIpYlVvdRyyqB snngJEUO18zd9CKEAAXqHnt9U8RmtusmD+CUnXHiuKpbLNQRg6IKK6mURcZMZnskfwRd MbjYDurvU/G7Bbo9JCPeJYs9LDXpN7LoIOFX26xHj73cnw9d3YmzYocUYFdZn97syolB Uwrw== X-Gm-Message-State: AFeK/H1MXDayDNtyGGG4cYbRMd+a4NmEvXSnbMWpaNrzvoP4zHnJeMTVWqk9vLsf+MWWeGWn++6r585fX4RG8g== X-Received: by 10.36.80.213 with SMTP id m204mr20129765itb.105.1489578950400; Wed, 15 Mar 2017 04:55:50 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.30.209 with HTTP; Wed, 15 Mar 2017 04:55:30 -0700 (PDT) In-Reply-To: <6543fbcc-fb40-36e9-3934-5b39fb47e668@denninger.net> References: <3d4e6e20-d41b-e4de-7ea9-589ed7882171@denninger.net> <6543fbcc-fb40-36e9-3934-5b39fb47e668@denninger.net> From: Ed Maste Date: Wed, 15 Mar 2017 07:55:30 -0400 X-Google-Sender-Auth: z3F4R0eRUmoO0YPNogm6h21ZGKM Message-ID: Subject: Re: PI3 build failure on 315244 To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 11:55:51 -0000 On 14 March 2017 at 17:57, Karl Denninger wrote: > > Just rm -rf'd the work directory and re-ran with the -DNO_CLEAN > commented out -- no change, still fails in the same place. Indeed. glebius@ fixed this in r315292; previously the build was incorrectly trying to use headers from /sys. From owner-freebsd-arm@freebsd.org Wed Mar 15 12:25:41 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78A2FD0DA61 for ; Wed, 15 Mar 2017 12:25:41 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0041.outbound.protection.outlook.com [104.47.32.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC36E17A; Wed, 15 Mar 2017 12:25:37 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sN/Qbc/iO0pLe+FudJjGZ3psIY12+PLnAERCcDo4QtU=; b=W2kr99h/+xs1CnKQWBZ+QO94U1y0E+QZDbQmfXFm9QIzDLyyMzmZZkIEC34L1I0KSvvMw3tmMiGL9v96RAwQYPrtOJMEBIZSbGby2ob6K+/ZsvDo0l6XkoYDGERYRRjI35nAE8xJo6Q9YOwy8WBpIri0e+gXR9faoKl3h+XtGxk= Received: from BY1PR0501CA0040.namprd05.prod.outlook.com (10.162.139.50) by CY4PR05MB3256.namprd05.prod.outlook.com (10.172.156.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 12:25:35 +0000 Received: from SN1NAM02FT044.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e44::204) by BY1PR0501CA0040.outlook.office365.com (2a01:111:e400:4821::50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5 via Frontend Transport; Wed, 15 Mar 2017 12:25:35 +0000 Authentication-Results: spf=pass (sender IP is 129.130.18.151) smtp.mailfrom=ksu.edu; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ksu.edu; Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp2.campus.ksu.edu; Received: from ome-vm-smtp2.campus.ksu.edu (129.130.18.151) by SN1NAM02FT044.mail.protection.outlook.com (10.152.72.173) with Microsoft SMTP Server id 15.1.961.10 via Frontend Transport; Wed, 15 Mar 2017 12:25:35 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp2.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id v2FCPYPI027728; Wed, 15 Mar 2017 07:25:34 -0500 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id 4F65C24830A; Wed, 15 Mar 2017 07:25:34 -0500 (CDT) Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id EC47D248006; Wed, 15 Mar 2017 07:25:31 -0500 (CDT) Received: by mail-wr0-f169.google.com with SMTP id u48so9854724wrc.0; Wed, 15 Mar 2017 05:25:31 -0700 (PDT) X-Gm-Message-State: AFeK/H2JE8FCbN9r+4H+oZG1oWpUV9Qy3/b6MZvWhyVB+62Cs4ua7gGID0ArKxWs8S6lIY0j8M/35R07ie5Ebg== X-Received: by 10.223.152.83 with SMTP id v77mr2793427wrb.109.1489580730542; Wed, 15 Mar 2017 05:25:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.9.77 with HTTP; Wed, 15 Mar 2017 05:25:29 -0700 (PDT) Received: by 10.28.9.77 with HTTP; Wed, 15 Mar 2017 05:25:29 -0700 (PDT) In-Reply-To: References: From: Kyle Evans Date: Wed, 15 Mar 2017 07:25:29 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: portsnap failing on armv6 To: Jia-Shiun Li CC: , X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39450400003)(2980300002)(438002)(377454003)(24454002)(199003)(189002)(57704003)(6246003)(6862004)(356003)(59536001)(110136004)(55446002)(42186005)(9686003)(76176999)(61266001)(54906002)(63696999)(38730400002)(305945005)(86362001)(75432002)(229853002)(98316002)(93886004)(8676002)(61726006)(93516999)(106466001)(8936002)(54356999)(8576002)(498394004)(1411001)(2950100002)(90966002)(50986999)(88552002)(5660300001)(4326008)(512874002)(236005)(46386002)(53546007)(45336002)(84326002)(450100002)(2906002)(189998001)(55456009); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3256; H:ome-vm-smtp2.campus.ksu.edu; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM02FT044; 1:90YYdjA4rZUNx/VfqDa1wkqandPihbSEWpaVYMoV4z2GPFvkDn2Ny2qsSQadcHYl1qF8I42HsIctaEm0jY41aQtrzAO1dVbrRdseqG0UVPXh2QddyGztC8wQqAI/3w/qvNwzLjESI92BrvEIOLpU03S+E2znUnvHDDXUresRwEABgZTZkGZxnrvrX58B5HygJvlNXvqidhTkDj9pG62+t8womH3sqfXzaeYXMQGbRMpEHrcTpc5G4vQPVHF7qdHZ+nkPZfsa12tn52et8kuf3KpFFMOIcsecrXnojwwolhjyhlkvyuVzJbsURChliL6Fcj75Bckhv7HReguP48LyygO2TV9boHvLRxkWbq0xTHgpgZO46B9hx0viYgx/SepNccNToAsNGOeCWwrTqWm9DGlmLqPU3KLyPb5DqXXvt0RXi69T7HhhIWz/es3sYkhUhEFAI1VKvHt43np5UBzjZiAQSFs+kjsg63vx+ZD4lQ0YcN3DHbTSSmf3G0aCjPsocto0wMuDdWITrO28BDWbjRX4s7F9XDDU48luDAAvB43yG1ypNZCgc11KMpDbnecZ X-MS-Office365-Filtering-Correlation-Id: 79b8429d-b1bf-4e76-7552-08d46b9e619b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(2017030254020); SRVR:CY4PR05MB3256; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3256; 3:mZXkzTULoTMpd1cmyFQCIJgrc2Y92ievLHL+UXgJPljsC8wZ+b3zAsRkgmqh4dH9kjmHfffK7yztVztli4nF9YNRxm1WBbkIZl/9S+5T+FKpiu34KKRfV7UBwqT6MVM6EJOjiAO9TFR1luWnrg1eSrte7OW2UNAbM7MWGlyg8pbEe1v6ygqFE7eFYWjysrh8yzFEGBKCVVGqlH4qAOG/Aknmdwlw2PIjOL7S+GClfYiZDXucdH4i/MjDm7lC7kxgL0tYHLh+1zaaWI1BejBPULZIAzhXqCnOihSncRbzBwIZWhvdeuHy0uSlAXGiZX8QOpKudBtwDe9YQ8Vb95d30+1yVoJ/L5VkG+K1XRYpJo2aDDFDMkmoVUpqWFLQ8u21SNBYbUAyG48InPjS87idCTHLRtJnV/BYmNBhgCctOzY=; 25:vOpdWQYtBPCm7GSmr/k4C3VnpnXWNcP0P7jZ2UFv3Z1ucGpDo85B2eNTqlScBCiyZInuF1XgCRzqIT+EU1NCm6fp1qt2MxVsESfh+txCatfkPVFguCzu/1ou+Ohg8/LfJO8Su5fMDXCtllVPI+tJKuNIVcV+azf8bLTOZEAZbgffHYk/pJNIhDB9EaeM8A2OHYG/TisNIcAP7/a6w8VI2U4FkEZF0XGlTTrnDbijJkvLAn/NQF3j175Tq/cOSArbK8hruTaFaRLqcb95rfuFEoAHjVdMkwcQsahp8ui8HPcLy9RBcs7JkIob7lDV1GR3OMLpKXAf4l0/OofOAqpaByZ1mVO04Bwrh7ATftHPPf2bazpzo3VO13db7J0a7VyuASGyMcLtk8U9opAKHalf6P/y4KUBejpuRGa7CYiQiD/H0fOOCYL5HMcl2bQYwrDPcDitTB673hGM7n29BOcTJA== X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3256; 31:mSDr/jXeqiwngFE6Slcw7DZZdka7t76++lbxezHjEKrkUOoM/Q70QPgMfZSrZf1ELxac5uvg4rpCPZCrv8KFLqM2I+kYfeScTqUcufX0lHQVspeLFZ10LhG8pPj3AOcFLYxUtbsrMDHEfcw1dI+wGhIf6r7Iw4Cv+9KJRkZQkXPMhvspdOLMYRtjhEWUKgWHM9naZAd76411K30J/h1SIb6Qz8nj4XWXazeGKa5mbN1JyML8ycH47NJxjpCsktlTKr8hkSTvkVHrCfUFUueJBg==; 20:BuEBH2VpejO3au9bMZ1nx/pqHRdbSAwZF0DRsluZ+jUsnzU0eazN/EHSc1A7nXwfU8obTT2LEgbUci01acs/qXPnA0A9Az6HB3SsbEMxqyp5/SF0ddPKkGQT1ETZ403Z1ZTtpZx+ex7K4+qQoS5ZwAWyiir6lmdcEMYUEryuX2zSi2Jz9IAu2RcEY9+a5Jl7WDZJuTJOed33CvIBCgmN1jnEc0AFuy0IAOuhBImlZS032BqbV3HqlYBn8UD59vcC1GUf/Bi8QEOseWWdeXe44WuluMZQtXa18JReKYqwAgBcFFbzC+vmpAmL0LXWmn6j6H+p84SbXjqJIKElTzrwuTwWCQG8Lt1U+CCw4K/A8iXOokhpVCNLK8auHWjntrn3qfDmgg+CP4a012gLd7xa7rx8mmWmtCdLPfv16iitIeWNxLG+OYEbGyrnUa/2QwqqxPAm/o/T+D02p9YkSGR05o6ChaJ8igu9rMLps6Y2qmyAm9UU5Dn0JnVD/vdOGqrX X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(112903893386949); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13023025)(13018025)(13024025)(8121501046)(5005006)(13015025)(13017025)(3002001)(10201501046)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:CY4PR05MB3256; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3256; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3256; 4:fyDXN8yGLhzYKZ9c3fprTP2IV3IahKinnFn+OXVvgiza7OYgBzKGOilvZy6lulkjU87kwyAZddavZWYvLgsTkh6XnWIhx9b4amZ5bCIDrMWkf+bjIeWDC4R25OEIF5mk7cb99VhPF7moar51RBKPMaXRkoTc+SRLKS5ndShhMSwxkXk+88/e0vMoVCiUu/122TqF59cw/AowEQHesVYg5JZOahmP6b4NWrwVfdkwaUJ9cgfH+S8oV3p+esgLWC93jKARopRIrGdIs49B5SoengfiKj1y8cx4GSFcyLN3rarL9nBZMGZrw+pFTpLyfqtlAordIDfvHLJPU1JgxUbNbKrSsnQRnE82DoszBJZqrmu4gTVrvI7XYjJxgyp0xZE/Eqeut/zg/M3Z3vnnpSIzl5ygWk3WcjdOrsX6Yosyzq8xJb0xL9SkEBt/6EJoIsw55rO5EncNIvK+oeeuM7T/9YfOsKhy1oygkDMybDnsdxi8zsUX290pzYowi67nnTUCesxEMu438xNOOdiMwBtC+ZZMBhdkYqOy396Kf2twBxcW4y4v+aOTGh1Lr1s8fG9qehbCRJyE7cY3Wo9rZXMIlZbZh/4BK4Qk1IDo/0gb9GIsqwa6NS5e5bjiKXlnTq8IxMQykfabr5fKxbCdiSS8C1r61r/ip1z1a1THveBLVkpUDMJfuVU0TRZmZGrUIb1TTeZSxkBBRbmlAw5ts8LIi+Hq+lyJts5vw8SinlQrFblcysa/6/dxLLXV257uomjW X-Forefront-PRVS: 02475B2A01 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB3256; 23:IgbycZD5j+F7F/4YrJnpTSLQFe4irpN/k1GHL3STc?= =?us-ascii?Q?GNhxwm2bBg85WNFi7aViIT6zkkaoKpT6t0ZL1bqNOOCuc+8cJvIu6BB4aGsU?= =?us-ascii?Q?8NlrLuQhgMjg2ZfVyn0+Bw9IjoHpoPdYnbLdgXpL9VjnKpZjXzujAGQ9Vpis?= =?us-ascii?Q?ghyM7IdRMk6sJO42jlUkuq8fQnKDNXUeiI0pXAaJLO9PRVkF0hnZquA/Ou2L?= =?us-ascii?Q?mqfc9rgIRo/pQkv2koPBiqee8++s0pXeZZj/7xyzax1RyKdpRtWCHbZbg59f?= =?us-ascii?Q?s91NcOtcqWTAy8iKGEVzTIxO5290kQfYfqOSAh6C7AJe/I0QScXN+rKTGKvs?= =?us-ascii?Q?SaQhRsMUA4Ezr+Kvd0ljmYE9Nvzw4Fzw/ayLGhs1q2NFvDrcHlgWQHu76FJP?= =?us-ascii?Q?wbw9Hi+5XanNt83y7pIHZdA5yprMMsvzkUAZK9pxRESdlGKGweQ4owk4y79s?= =?us-ascii?Q?3SyQkNVwlFOHoyI3Ay5OK4RLdvukv1le9eKBHK4nSDDfKy0Q72mMfjoIp6eq?= =?us-ascii?Q?31fbg2+YxGi3e3szRL/gy1UeHZQyN8aU947/LDnpM6OVfpV0rBXB9IdhX9oo?= =?us-ascii?Q?6dJYXJUKHtc86phHdOZ8xZFvj0KkSZnmzyI2J82iGejqydb14Dk5YizziLCx?= =?us-ascii?Q?x/vbBVsY81iCV9xsQrnoSxU58vkrVcJtfeoK+85OCCkKxFBq/HYOBUUKg7wv?= =?us-ascii?Q?sPZGVDW2obaQpkHC5FpoFgQwwrGlNAEwzxUQlIJQUEyKvMI2BP3XtCaRKdBA?= =?us-ascii?Q?8jghIjyMZiHspZiGvZv9bfXvh13OnnEGBvTglCvrE95PshiN6bfNfXfO9lH6?= =?us-ascii?Q?gS89NtZhPhvT3ZOvZTcrQZZe8JX5orriapq1bnSgERvvcnWf/10uGZ6ImErt?= =?us-ascii?Q?zx//FUQK2W9425xVAwu9SgtOYoRREGLMI92AalYU5XtmvDT9rRA6RHDBS3AA?= =?us-ascii?Q?4MrjNICJ1Rhwz5LqGmRAh7J1lochyzqphunSoLkFdjBUyobVSR1xdn9w7na1?= =?us-ascii?Q?UWwnQ9sSJdYJDFHwb/cvyDusYCkBT7R2fcVTphj9xlG1t8lBhrgsnVpuGzs7?= =?us-ascii?Q?KGFLIt60O4iEqkyDlUptkva3MICw1CR1H0WBBBpQZtBEhUttWa8ZK0bVzB3D?= =?us-ascii?Q?QOEVoYZ1jORgkNsoKAEzPhF6W5+pEVcW03ZM2BaOwvR7JYAdov36nR636+OK?= =?us-ascii?Q?V3REuZaorWiS22NbSC6hSwFnrXwcjdyAOsWxP2p5xO189+m78p3FhCqKAY+M?= =?us-ascii?Q?s9J3iRAyYmwcwEuqqY=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3256; 6:uSya1hFNz9kIShAHxhV9jEZKHZHLmHN7gZrcastxknt69yq3zgyPdwGyBQ3EVCstw4eAJ1721NoKaG5HWDJsJNSTbF3q3AAPSKtU4cVS3VVnYzX4gPa0xpdtXEYijOdn3LV+KSMEakAHw0LIQiPbC5fJjqayLo4U72Zy9F2I161SAsQNsAgF/o2N5CfKlE/2l+lhZwMGI/CS2dBeQ2H7sgog7vCFI3ZivShavHQ9AwQlQedzoDcVmH3E4xJb8XWVEPIGEPZaXXbpddwEdWlkqYThgjIC37QaTfsaXj3vOu23fV1+q+VIAIiifLnwvYU/th/cUACREOekhIOZaDBQW1JemPhDvdLlMogt+fcpEWc2CXhlzf90E+t+niQPXWuQab+CgQnkGK2YXF+wH2UwVw==; 5:ZCFQQ9FN5Lz3ZIyM8ow1ICo4Oj1pTUHkLpdJsOVu9QVbh8v51uDwBWvFm5i3Uh8T1lRERd/7VEKZUHGp5+JPClFtZPTpn37yicaQ0n52D8+GwzM9Q3091dUwd4DQ6YgXFlYZC18olIuQ8Bk6bRY2+xlfygqYfbotiUDEQj6PlZ4=; 24:ckn8ZqEDZqAin8T/poAupMzBteQQokIy74cZX2E+xgkIbf8lhBONc7g1SGmlSWvBG0ReVEaH777eqKFlENQkgdcWKjhnzJj9+k1fxnOvmoE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3256; 7:jSRU2lNjDC6Omd86ZkN6qDzQ3m7UhANCskv0Chq/EPRLl5Lq9HQ0pLfVRHazNaoW+fduwCGduBEEca3RA9hkNEiRVmZirzBtmXuxZqiEZS7plWl+WUdGtr2zJNcKIVLxiaW/k0qdrdzOdKCVto5tRvFu+Sz+ejn1Gabm87bzyE6fhAqEB5WxK6OS3UBUMeseHXApn7UddC9cqbGoZux27c6su7S9uXS5n555rSXOCBvWQHMUuCga73zF/tdZlHk7+wZDzIuh30E7UAZZU76e+b46VX+tK4vqTImHCTMVBb/eFl+PCfbGLTRCt0IyPCGM3o8Rwll3VHnGRB3d69yztg==; 20:PA+u7rR9f6uPjhcuUiEkv9M9zBvE8suihCBI7ztGvZURMIRqq1szRUK/d4DCQeo4jE3Osb5Gcbvz/lMll/5l+0yquUQKjSL5X7JgkJ6618yb3w0jN22is82+jzcfxCTlreYNOSCRiJAbNxaydSmLCXwUwzcJKIaRj6dTk3UtIcc= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Mar 2017 12:25:35.0790 (UTC) X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp2.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3256 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 12:25:41 -0000 Oh, sorry, I definitely misread that. AllanJude@ had done a fix for lam back in r314095-ish, but that might not have covered the no-capsicum case. On Mar 15, 2017 5:01 AM, "Jia-Shiun Li" wrote: Hi Kyle, I simply rebuilt and replaced diff and the result is the same. According to portsnap source and its output, it suggests lam is to blame, not diff as r315197 implied. Or do I need to build something else? -Jia-Shiun. On Wed, Mar 15, 2017 at 12:39 PM, Jia-Shiun Li wrote: > Thank you. And Baptiste. > > I was lucky enough to get it just before the commit. ;) > > Will try later. > > > Jia-Shiun. > > > On Wed, Mar 15, 2017 at 12:18 PM, Kyle Evans wrote: > >> On Tue, Mar 14, 2017 at 11:08 PM, Jia-Shiun Li >> wrote: >> > [snip] >> > Verifying snapshot integrity... lam: unable to limit rights on: -: >> Function >> > not implemented >> >> Hi, >> >> This should be fixed by bapt@ in r315197 =) >> >> Thanks, >> >> Kyle Evans >> > > From owner-freebsd-arm@freebsd.org Wed Mar 15 13:32:36 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 20D64D0D54F for ; Wed, 15 Mar 2017 13:32:36 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id C9A631024 for ; Wed, 15 Mar 2017 13:32:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 0620C21660F for ; Wed, 15 Mar 2017 08:32:35 -0500 (CDT) Subject: Re: PI3 build failure on 315244 References: <3d4e6e20-d41b-e4de-7ea9-589ed7882171@denninger.net> <6543fbcc-fb40-36e9-3934-5b39fb47e668@denninger.net> To: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: Date: Wed, 15 Mar 2017 08:32:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070906090005040103070900" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:32:36 -0000 This is a cryptographically signed message in MIME format. --------------ms070906090005040103070900 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Confirmed -- appears to be fixed. On 3/15/2017 06:55, Ed Maste wrote: > On 14 March 2017 at 17:57, Karl Denninger wrote: >> Just rm -rf'd the work directory and re-ran with the -DNO_CLEAN >> commented out -- no change, still fails in the same place. > Indeed. glebius@ fixed this in r315292; previously the build was > incorrectly trying to use headers from /sys. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070906090005040103070900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMTUxMzMyMTdaME8GCSqGSIb3DQEJBDFCBEBFJaXk reDtvbUsB8lzSXmSUFwk+NbYgFTMarQEzsL5bEttq26uj00kPgCJvDwPXeTWOtGgKDm2TA+t yxItuiPXMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAXv90iiM4EuwL pthm51QGgbS2ZQ6kfx/TfYbeefEI53ANE0OBfF2PtrlcdJ+G35je2pg6X6gcHNUqdKYoL3o9 28jHFYZXAAzSeVyOKeusnudN5WN9cVvy5eEDl/KxkiMvBYB74ZlI/1bAKHgNgFwGtn+pbCnU vlkyDA+1yBPFmvGGZqIUMyL4yr+JhHpUlJGRAoSdLJRGfnlfyb15OfjPJuBPys56ihvocFGB Y2Q8/f0HUuYMpjZmTUCiXmCyk0MYrMCqlkOAhGG1zDnmBSifagenj3eh1Bkqlk/tdx/FpBXV JE6P3yaCg/F3/AQvAfolq4MDuJGmWs+HSYp6mnMLWudJCREAgwJ0/X5f3tysWJue2vQIGtp9 RO7ppgml6pSt574EY7h7d3l2sg3+Y2qWZ6E//RSLPNeqxJmMSB6h9oGoOdHCM+o+mpi0PVkX He8wqcXGU8nMOYqqUoF73eGJcQKVJN4Set1ROTKo9iqRtxXFrS7WrPzlqY43shgZ6vQTnT9l Zpo4F07F3eJWeNPWnF4+T6B20eZFAW6JIXGYk0nunBEFA2zMKUfSFWliD/9rtXxIV7e7F3BG 3YE4N+oX0dV12Q99VuvvHbMGey9tZKrdOgiC3roAHKWqtv1/v2ZGKkXrSVq1hlvPBWZe31Wt ASwCxLunibFDaMA3jVipHo4AAAAAAAA= --------------ms070906090005040103070900-- From owner-freebsd-arm@freebsd.org Wed Mar 15 15:11: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 85E64D09005 for ; Wed, 15 Mar 2017 15:11:56 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 648F582E for ; Wed, 15 Mar 2017 15:11:55 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (75-173-99-247.albq.qwest.net [75.173.99.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id B88DA1928BA for ; Wed, 15 Mar 2017 15:11:48 +0000 (UTC) To: freebsd-arm@freebsd.org From: Sean Bruno Subject: qemu-user regressions Message-ID: <206ac59c-9efc-522f-d7be-70a06a418b83@freebsd.org> Date: Wed, 15 Mar 2017 09:11:45 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KQ9oGKBSVJR6Vgh6NR6LwkagOnNEKOS4X" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:11:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KQ9oGKBSVJR6Vgh6NR6LwkagOnNEKOS4X Content-Type: multipart/mixed; boundary="FGr1go1j0mDUEprhP6vNsbVsJ0V86RSXP"; protected-headers="v1" From: Sean Bruno To: freebsd-arm@freebsd.org Message-ID: <206ac59c-9efc-522f-d7be-70a06a418b83@freebsd.org> Subject: qemu-user regressions --FGr1go1j0mDUEprhP6vNsbVsJ0V86RSXP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'd like to generate a smallish list of packages that I can use as a baseline regression list before I do merge updates to qemu proper. If you have a handful of packages that you use day-to-day, can you reply to this list with them and I'll add them to my 'best effort' list of things to try and not break. sean --FGr1go1j0mDUEprhP6vNsbVsJ0V86RSXP-- --KQ9oGKBSVJR6Vgh6NR6LwkagOnNEKOS4X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEuq1GMucSHejSCZfdEgHvyh5yfmQFAljJWbFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJB QUQ0NjMyRTcxMjFERThEMjA5OTdERDEyMDFFRkNBMUU3MjdFNjQACgkQEgHvyh5y fmT8eAgAmvUM7+p2kSRuSKkHxMO5EjVXbwoK0RYmFs/HmZm2MQjPLtvS0svgV3hT MscrzXGbut1Wxz3BseTZSKBkU+n1vNPFqYYQcmTy1F18Gi8rMg3okUdZ/bc5er5e Dm0TKXpIeaqmf8hrPPdyzx47fmrTl74f33JQaqUUmLwz9nWNQY+H3waahdJALfnX XYImhrQIwZjYsiPnYlqqCJ9Q0KvCZUhY1UDy7brNPJXLysxt2aR8L+VNQRMkT50o aE3rR4L67TETWMfmXQglxmz07Yl1u0rhCIk/EzzewhfVW8Ptuz6JbbnCPe+RnRoh PxhLI6nTL8+XhKTGYCwl+WfRdL+D+Q== =VAjE -----END PGP SIGNATURE----- --KQ9oGKBSVJR6Vgh6NR6LwkagOnNEKOS4X-- From owner-freebsd-arm@freebsd.org Wed Mar 15 15:30:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86379D09713 for ; Wed, 15 Mar 2017 15:30:11 +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 759D4104F for ; Wed, 15 Mar 2017 15:30:11 +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 v2FFUA9V025141 for ; Wed, 15 Mar 2017 15:30:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 217753] lld [llvm 4.0.0] Linker won't link on aarch64 (Error: Failed to open a.out) Date: Wed, 15 Mar 2017 15:30:10 +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 Only Me X-Bugzilla-Who: jbeich@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 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:30:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217753 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |DUPLICATE --- Comment #1 from Jan Beich (mail not working) --- Marking dup unless you can reproduce without qemu-user-static. lld works fi= ne on aarch64 reference machines[1]. [1] https://www.freebsd.org/internal/machines.html *** This bug has been marked as a duplicate of bug 217189 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Mar 15 15:58:15 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 CE96ED0D4CB for ; Wed, 15 Mar 2017 15:58:15 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABD0C1674; Wed, 15 Mar 2017 15:58:15 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id F28A1754; Wed, 15 Mar 2017 15:58:14 +0000 (UTC) Date: Wed, 15 Mar 2017 16:58:14 +0100 From: Baptiste Daroussin To: Jia-Shiun Li Cc: Kyle Evans , "freebsd-arm@freebsd.org" Subject: Re: portsnap failing on armv6 Message-ID: <20170315155814.mav2bvs45ol73itq@ivaldir.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nf5vctws3kridk4g" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170225 (1.8.0) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:58:15 -0000 --nf5vctws3kridk4g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 15, 2017 at 06:00:51PM +0800, Jia-Shiun Li wrote: > Hi Kyle, >=20 > I simply rebuilt and replaced diff and the result is the same. > According to portsnap source and its output, it suggests lam > is to blame, not diff as r315197 implied. Or do I need to > build something else? >=20 > -Jia-Shiun. >=20 >=20 There was an issue with lam(1) as well (not my fault this time :)) and I fixed it anyway in r315309. Best regards, Bapt --nf5vctws3kridk4g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAljJZJAACgkQY4mL3PG3 PloGJRAA1XxME0aQfDqUdlKEFzlcz0t+bDazZiHDt7LlQXCt1fuolyVjRgCsVXiX jrMECanQnRwRzaMf8kjSB1MjyO5LXti5i7xv78DjjknXbR9xiI1637E8z/f7mF9M P+EVEFwGj18XRGOy2cttOcjVRcgJqtGZG2sE1sWpPcRUH+I2nrIFNRLZx2DN00wO i/HsO3bCoyWL7IctEZJHzDvqyza/AHIIZcECIn0NHRODp6UQqC58oHnTkZlLXARl j8wOwwO/iN6gjHBj5l1FMoexHEkTjd1DLvZo5Hu6oWz1secDpFpQfA43CBuTRZZn o9nllukcY/gy1y75k4AJAUdgO5YV/6wjn9WMHrtSOIJxof0h3ff85vKU/R6m3kjK VODjKgJ/6oHMWlJVAaXGqsD3gcmb9dV7P0LfHYYIkUlHnfElyVZQO4nHDyLwL83U 7f2svGYYhhhJKy0MC/LJB5h+DGFkaFp+Lx39FcMZpMUzJykyp7vNtvYaKJymQS/I lFZ834BE/kWIyC74Plgsn7OC3PPlVhHeer47djWDwW0h45rT4mf2ynxy8pevj56a ASfZC9X9HcOlBtZ+VpoKd0SHZ3u27bBfb5g3NeIQdHYARXZO2kMANr+Ly8V6hvGn oLhvCOLWFUnllsagMgY0BGyJDMb2Ub/INcSYU1PQqSLZRzdm17k= =B5uR -----END PGP SIGNATURE----- --nf5vctws3kridk4g-- From owner-freebsd-arm@freebsd.org Wed Mar 15 18:13:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4A4CD0DE64 for ; Wed, 15 Mar 2017 18:13:24 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 99DF174F for ; Wed, 15 Mar 2017 18:13:24 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 8012E13A1D; Wed, 15 Mar 2017 18:13:22 +0000 (UTC) Subject: Re: portsnap failing on armv6 To: Kyle Evans , Jia-Shiun Li References: Cc: freebsd-arm@freebsd.org From: Allan Jude Message-ID: <0cfe38dd-32b2-6d82-b678-210e666b8cde@freebsd.org> Date: Wed, 15 Mar 2017 14:13:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3WcpfMs6E6MfBvajjExTs5ecspPw0vTPJ" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:13:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3WcpfMs6E6MfBvajjExTs5ecspPw0vTPJ Content-Type: multipart/mixed; boundary="lJsBqoVxLUoqjQMljdOqv1uQqD2OIdlS5"; protected-headers="v1" From: Allan Jude To: Kyle Evans , Jia-Shiun Li Cc: freebsd-arm@freebsd.org Message-ID: <0cfe38dd-32b2-6d82-b678-210e666b8cde@freebsd.org> Subject: Re: portsnap failing on armv6 References: In-Reply-To: --lJsBqoVxLUoqjQMljdOqv1uQqD2OIdlS5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-03-15 08:25, Kyle Evans wrote: > Oh, sorry, I definitely misread that. AllanJude@ had done a fix for lam= > back in r314095-ish, but that might not have covered the no-capsicum ca= se. >=20 >=20 > On Mar 15, 2017 5:01 AM, "Jia-Shiun Li" > wrote: >=20 > Hi Kyle, >=20 > I simply rebuilt and replaced diff and the result is the same. > According to portsnap source and its output, it suggests lam > is to blame, not diff as r315197 implied. Or do I need to > build something else? >=20 > -Jia-Shiun. >=20 >=20 > On Wed, Mar 15, 2017 at 12:39 PM, Jia-Shiun Li > wrote: >=20 > Thank you. And Baptiste. >=20 > I was lucky enough to get it just before the commit. ;) >=20 > Will try later. >=20 >=20 > Jia-Shiun. >=20 >=20 > On Wed, Mar 15, 2017 at 12:18 PM, Kyle Evans > wrote: >=20 > On Tue, Mar 14, 2017 at 11:08 PM, Jia-Shiun Li > > wrote: > > [snip] > > Verifying snapshot integrity... lam: unable to limit righ= ts on: -: Function > > not implemented >=20 > Hi, >=20 > This should be fixed by bapt@ in r315197 =3D) >=20 > Thanks, >=20 > Kyle Evans >=20 >=20 >=20 >=20 Portsnap will not work on armv6, as there are no freebsd-update builds for that architecture. However, lam(1) still does not work without capsicum. I am looking into it. --=20 Allan Jude --lJsBqoVxLUoqjQMljdOqv1uQqD2OIdlS5-- --3WcpfMs6E6MfBvajjExTs5ecspPw0vTPJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJYyYRBAAoJEBmVNT4SmAt+mLkQAKRiKZaai1i4Nx/n5VWCfoEP syxgbHd/3YX5LsZqK7HmL/FkFRYxAwVxUAK0iGanpiN30zjlM9bly73u3ToGBKE7 Mb8RTnY1t/7Xy1gpaU/imnoU/lWLxRR7rTHV4ToMY1OkR+MmOEHX95NPh/TAA/Nu kRGiefCOLYcPWcCn7vuch6xsl5V2hNQPwneP2Z137sui+Ls2vMSq2rfi2y+h4p0Q ssuMh8FlRrhI+VHHKVciNbs23RyE/uYOyHBBYIO0x0H6LkPiz0w1Q0Q1Qy/5oVlY a+ZBsdUXteHdJY0K8IAducKSLxYPBtqE6gL3dGJwPQB0Avhx2h8C4qngKnYqr60q fWhYOBaFh8dmMK4FYWNCmk7Xic3N6ZzN4EleBJ4Q1m8IQKa8wVlLHBj7DtVe4Q58 cTIQ3ngc6M3edp2BSFu+Xhkkq2H6zmKMP3R3fa/7ZSVS7B74R2L2pilARMvr5NDE +ozUonEPLxr1uuD8hgRU4NCwBz0azcSjgqOhEnTCLUVhs506YW7V9VVMRK5V1UFB Q2LdA4OP3w6IzwaAA71QnUt4y1Py7z+e42b8lYSiJ3UIALPNajbhsl4nIRtyDidi oj3hXA+02GLj6zTBOWYPlE5h/jhjTtRoFHiKniOAE3cHuUfT82a558zOKPq69cC3 r2z/dgfQE8BCQuTQBzwf =rC9F -----END PGP SIGNATURE----- --3WcpfMs6E6MfBvajjExTs5ecspPw0vTPJ-- From owner-freebsd-arm@freebsd.org Wed Mar 15 18:51:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FFD3D0EFA9 for ; Wed, 15 Mar 2017 18:51:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-176.reflexion.net [208.70.211.176]) (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 C5C5CEFF for ; Wed, 15 Mar 2017 18:51:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22829 invoked from network); 15 Mar 2017 18:51:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Mar 2017 18:51:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Wed, 15 Mar 2017 14:51:51 -0400 (EDT) Received: (qmail 16003 invoked from network); 15 Mar 2017 18:51:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Mar 2017 18:51:51 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 796CBEC9026; Wed, 15 Mar 2017 11:51:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <345EE889-A429-4C13-9B08-B762DA3F4D71@dsl-only.net> Date: Wed, 15 Mar 2017 11:51:49 -0700 Cc: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <201703151315.v2FDFWOr028842@sdf.org> <345EE889-A429-4C13-9B08-B762DA3F4D71@dsl-only.net> To: Scott Bennett X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:51:59 -0000 [Something strange happened to the automatic CC: fill-in for my original reply. Also I should have mentioned that for my test program if a variant is made that does not fork the swapping works fine.] On 2017-Mar-15, at 9:37 AM, Mark Millard wrote: > On 2017-Mar-15, at 6:15 AM, Scott Bennett wrote: >=20 >> On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard >> wrote: >>> On 2017-Mar-14, at 4:44 PM, Bernd Walter = wrote: >>>=20 >>>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: >>>>> [test_check() between the fork and the wait/sleep prevents the >>>>> failure from occurring. Even a small access to the memory at >>>>> that stage prevents the failure. Details follow.] >>>>=20 >>>> Maybe a stupid question, since you might have written it somewhere. >>>> What medium do you swap to? >>>> I've seen broken firmware on microSD cards doing silent data >>>> corruption for some access patterns. >>>=20 >>> The root filesystem is on a USB SSD on a powered hub. >>>=20 >>> Only the kernel is from the microSD card. >>>=20 >>> I have several examples of the USB SSD model and have >>> never observed such problems in any other context. >>>=20 >>> [remainder of irrelevant material deleted --SB] >>=20 >> You gave a very long-winded non-answer to Bernd's question, so = I'll >> repeat it here. What medium do you swap to? >=20 > My wording of: >=20 > The root filesystem is on a USB SSD on a powered hub. >=20 > was definitely poor. It should have explicitly mentioned the > swap partition too: >=20 > The root filesystem and swap partition are both on the same > USB SSD on a powered hub. >=20 > More detail from dmesg -a for usb: >=20 > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 480Mbps High Speed USB v2.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on = usbus0 > ugen1.1: at usbus1 > uhub1: on = usbus1 > ugen2.1: at usbus2 > uhub2: on = usbus2 > ugen3.1: at usbus3 > uhub3: on = usbus3 > . . . > uhub0: 1 port with 1 removable, self powered > uhub2: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > uhub3: 1 port with 1 removable, self powered > ugen3.2: at usbus3 > uhub4 on uhub3 > uhub4: on = usbus3 > uhub4: MTT enabled > uhub4: 4 ports with 4 removable, self powered > ugen3.3: at usbus3 > umass0 on uhub4 > umass0: on = usbus3 > umass0: SCSI over Bulk-Only; quirks =3D 0x0100 > umass0:0:0: Attached to scbus0 > . . . > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number > da0: 40.000MB/s transfers >=20 > (Edited a bit because there is other material interlaced, even > internal to some lines. Also: I removed the serial number of the > specific example device.) >=20 >> I will further note that any kind of USB device cannot = automatically >> be trusted to behave properly. USB devices are notorious, for = example, >> for momentarily dropping off-line and then immediately reconnecting. = (ZFS >> reacts very poorly to such events, BTW.) This misbehavior can be = caused >> by either processor involved, i.e., the one controlling either the >> upstream or the downstream device. Hubs are really bad about this, = but >> any USB device can be guilty. You may have a defective storage = device, >> its controller may be defective, or any controller in the chain all = the >> way back to the motherboard may be defective or, not defective, but >> corrupted by having been connected to another device with corrupted >> (infected) firmware that tries to flash itself into the firmware = flash >> chips in its potential victim. >> Flash memory chips, spinning disks, or {S,}{D,}RAM chips can be >> defective. Without parity bits, the devices may return bad data and = lie >> about the presence of corrupted data. That, for example, is where = ZFS >> is better than any kind of classical RAID because ZFS keeps checksums = on >> everything, so it has a reasonable chance of detecting corruption = even >> without parity support and, if there is any redundancy in the pool or = the >> data set, fixing the bad data machine. Even having parity generally >> allows only the detection of single-bit errors, but not of repairing = them. >> You should identify where you page/swap to and then try = substituting >> a different device for that function as a test to eliminate the = possibility >> of a bad storage device/controller. If the problem still occurs, = that >> means there still remains the possibility that another controller or = its >> firmware is defective instead. It could be a kernel bug, it is true, = but >> making sure there is no hardware or firmware error occurring is = important, >> and as I say, USB devices should always be considered suspect unless = and >> until proven innocent. >=20 > [FYI: This is a ufs context, not a zfs one.] >=20 > I'm aware of such things. There is no evidence that has resulted in > suggesting the USB devices that I can replace are a problem. Otherwise > I'd not be going down this path. I only have access to the one arm64 > device (a Pine64+ 2GB) so I've no ability to substitution-test what > is on that board. >=20 > It would be neat if some folks used my code to test other arm64 > contexts and reported the results. I'd be very interested. > (This is easier to do on devices that do not have massive > amounts of RAM, which may limit the range of devices or > device configurations that are reasonable to test.) >=20 > There is that other people using other devices have reported > the behavior that started this investigation. I can produce the > behavior that they reported, although I've not seen anyone else > listing specific steps that lead to the problem or ways to tell > if the symptom is going to happen before it actually does. Nor > have I seen any other core dump analysis. (I have bugzilla > submittals 217138 and 217239 tied to symptoms others have > reported as well as this test program material.) >=20 > Also, considering that for my test program I can control which pages > get the zeroed-problem by read-accessing even one byte of any 4K > Byte page that I want to make work normally, doing so in the child > process of the fork, between the fork and the sleep/swap-out, it does > not suggest USB-device-specific behavior. The read-access is changing > the status of the page in some way as far as I can tell. >=20 > (Such read-accesses in the parent process make no difference to the > behavior.) I should have noted another comparison/contrast between having memory corruption and not in my context: I've tried variants of my test program that do not fork but just sleep for 60s to allow me to force the swap-out. I did this before adding fork and before using parital_test_check, for example. I gradually added things apparently involved in the reports others had made until I found a combination that produced a memory corruption test failure. These tests without fork involved find no problems with the memory content after the swap-in. For my test program it appears that fork-before-swap-out or the like is essential to having the problem occur. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Mar 16 05:11:30 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 AD5D1D0DDDC for ; Thu, 16 Mar 2017 05:11:30 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6785B19C5; Thu, 16 Mar 2017 05:11:30 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-qk0-x230.google.com with SMTP id y76so30618631qkb.0; Wed, 15 Mar 2017 22:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8M1GLwoLrSEafFefhTRuaBwjWE4ztmC4D5IK5On2oiE=; b=qsMwQTANmmZgUrc//aoOswqoOJZdTktJe0Cwe8bIvOPaYRXnWVYD0FFCIS7K2X9Pfj 3EaWBCREchQ50BGcpkOxabZxTeAyKfdkwd4Kw6679LQ5X9qvTITCJkYtjzfdYx8/8j66 1S4QOcebAUufqYhhZW1OCFPRbyhqZefoYOsOcBHh248Lg1MArpXw7Jh7rxMET2F7BGoH iVir9nz75h9Vs+0zwrqkAOfn2GiHpdiEndLG9X3Lm1DP70etGbJjmvDyorYTRBePQz59 y8tMLKobaYcxFGYVdyaTT3/scBpkQSeFqMiyfpT5ukz/MzEwkyIxXwqSqeXbEBrG+RwH CcIw== 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=8M1GLwoLrSEafFefhTRuaBwjWE4ztmC4D5IK5On2oiE=; b=V2ajqRBrwYY4vtar25J74HHTOuRSQxNZLdellQf4JEdyLCPiLz99fLcJIML8EndcSl T6apcEO5tfSsjKJmichLct748cjJF+oqjGw1hIm3CesDGM5RKdwRV90mu80iQF5bKS9l jByWq/2binIxvFLirXV3+7hH24wusC1bGZj8TmCO6STru5sxIjD7/fwFJT542lg51MDy 0UTDl6vTcfUvnDLghNANR225KcRDiC1MXOEijJhL8VmW6qduXT660oVdPjRQC+yI8ShV 4iOZFVCfWnh705C9SoIE1VEdEq+gijnGCMrqpUDb7wlDNAnRQ+zNeFdgmCv97/H6fKJV elHw== X-Gm-Message-State: AFeK/H3eTD1OvbWRAQVhEW/erB6o5guE2GnhBbOsxRNPo8W+qYcucP1fAgzFwJmUJSLeit28UFp9vzb1xnaxcg== X-Received: by 10.55.19.10 with SMTP id d10mr5945004qkh.312.1489641089339; Wed, 15 Mar 2017 22:11:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.116 with HTTP; Wed, 15 Mar 2017 22:10:58 -0700 (PDT) In-Reply-To: <20170315155814.mav2bvs45ol73itq@ivaldir.net> References: <20170315155814.mav2bvs45ol73itq@ivaldir.net> From: Jia-Shiun Li Date: Thu, 16 Mar 2017 13:10:58 +0800 Message-ID: Subject: Re: portsnap failing on armv6 To: Baptiste Daroussin Cc: Kyle Evans , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 05:11:30 -0000 On Wed, Mar 15, 2017 at 11:58 PM, Baptiste Daroussin wrote: > On Wed, Mar 15, 2017 at 06:00:51PM +0800, Jia-Shiun Li wrote: > > Hi Kyle, > > > > I simply rebuilt and replaced diff and the result is the same. > > According to portsnap source and its output, it suggests lam > > is to blame, not diff as r315197 implied. Or do I need to > > build something else? > > > > -Jia-Shiun. > > > > > > There was an issue with lam(1) as well (not my fault this time :)) > and I fixed it anyway in r315309. > > > It is working now. Thank you -Jia-Shiun. From owner-freebsd-arm@freebsd.org Thu Mar 16 06:08: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 E86EAD0E0B1; Thu, 16 Mar 2017 06:08:06 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from mx.sdf.org (mx.sdf.org [205.166.94.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ol.sdf.org", Issuer "ol.sdf.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B57F315F3; Thu, 16 Mar 2017 06:08:06 +0000 (UTC) (envelope-from bennett@sdf.org) Received: from sdf.org (IDENT:bennett@otaku.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id v2G67WMk026837 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Thu, 16 Mar 2017 06:07:32 GMT Received: (from bennett@localhost) by sdf.org (8.15.2/8.12.8/Submit) id v2G67Vwe023153; Thu, 16 Mar 2017 01:07:31 -0500 (CDT) From: Scott Bennett Message-Id: <201703160607.v2G67Vwe023153@sdf.org> Date: Thu, 16 Mar 2017 01:07:31 -0500 To: markmi@dsl-only.net Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org, freebsd-stable@freebsd.org References: <201703151315.v2FDFWOr028842@sdf.org> <345EE889-A429-4C13-9B08-B762DA3F4D71@dsl-only.net> In-Reply-To: User-Agent: Heirloom mailx 12.5 6/20/10 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 06:08:07 -0000 Mark Millard wrote: > [Something strange happened to the automatic CC: fill-in for my original > reply. Also I should have mentioned that for my test program if a > variant is made that does not fork the swapping works fine.] > > On 2017-Mar-15, at 9:37 AM, Mark Millard wrote: > > > On 2017-Mar-15, at 6:15 AM, Scott Bennett wrote: > > > >> On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard > >> wrote: > >>> On 2017-Mar-14, at 4:44 PM, Bernd Walter wrote: > >>> > >>>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: > >>>>> [test_check() between the fork and the wait/sleep prevents the > >>>>> failure from occurring. Even a small access to the memory at > >>>>> that stage prevents the failure. Details follow.] > >>>> > >>>> Maybe a stupid question, since you might have written it somewhere. > >>>> What medium do you swap to? > >>>> I've seen broken firmware on microSD cards doing silent data > >>>> corruption for some access patterns. > >>> > >>> The root filesystem is on a USB SSD on a powered hub. > >>> > >>> Only the kernel is from the microSD card. > >>> > >>> I have several examples of the USB SSD model and have > >>> never observed such problems in any other context. > >>> > >>> [remainder of irrelevant material deleted --SB] > >> > >> You gave a very long-winded non-answer to Bernd's question, so I'll > >> repeat it here. What medium do you swap to? > > > > My wording of: > > > > The root filesystem is on a USB SSD on a powered hub. > > > > was definitely poor. It should have explicitly mentioned the > > swap partition too: > > > > The root filesystem and swap partition are both on the same > > USB SSD on a powered hub. > > > > More detail from dmesg -a for usb: > > > > usbus0: 12Mbps Full Speed USB v1.0 > > usbus1: 480Mbps High Speed USB v2.0 > > usbus2: 12Mbps Full Speed USB v1.0 > > usbus3: 480Mbps High Speed USB v2.0 > > ugen0.1: at usbus0 > > uhub0: on usbus0 > > ugen1.1: at usbus1 > > uhub1: on usbus1 > > ugen2.1: at usbus2 > > uhub2: on usbus2 > > ugen3.1: at usbus3 > > uhub3: on usbus3 > > . . . > > uhub0: 1 port with 1 removable, self powered > > uhub2: 1 port with 1 removable, self powered > > uhub1: 1 port with 1 removable, self powered > > uhub3: 1 port with 1 removable, self powered > > ugen3.2: at usbus3 > > uhub4 on uhub3 > > uhub4: on usbus3 > > uhub4: MTT enabled > > uhub4: 4 ports with 4 removable, self powered > > ugen3.3: at usbus3 > > umass0 on uhub4 > > umass0: on usbus3 > > umass0: SCSI over Bulk-Only; quirks = 0x0100 > > umass0:0:0: Attached to scbus0 > > . . . > > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > > da0: Fixed Direct Access SPC-4 SCSI device > > da0: Serial Number > > da0: 40.000MB/s transfers > > > > (Edited a bit because there is other material interlaced, even > > internal to some lines. Also: I removed the serial number of the > > specific example device.) Thank you. That presents a much clearer picture. > > > >> I will further note that any kind of USB device cannot automatically > >> be trusted to behave properly. USB devices are notorious, for example, > >> > >> [reasons why deleted --SB] > >> > >> You should identify where you page/swap to and then try substituting > >> a different device for that function as a test to eliminate the possibility > >> of a bad storage device/controller. If the problem still occurs, that > >> means there still remains the possibility that another controller or its > >> firmware is defective instead. It could be a kernel bug, it is true, but > >> making sure there is no hardware or firmware error occurring is important, > >> and as I say, USB devices should always be considered suspect unless and > >> until proven innocent. > > > > [FYI: This is a ufs context, not a zfs one.] Right. It's only a Pi, after all. :-) > > > > I'm aware of such things. There is no evidence that has resulted in > > suggesting the USB devices that I can replace are a problem. Otherwise > > I'd not be going down this path. I only have access to the one arm64 > > device (a Pine64+ 2GB) so I've no ability to substitution-test what > > is on that board. There isn't even one open port on that hub that you could plug a flash drive into temporarily to be the paging device? You could then try your tests before returning to the normal configuration. If there isn't an open port, then how about plugging a second hub into one of the first hub's ports and moving the displaced device to the second hub? A flash drive could then be plugged in. That kind of configuration is obviously a bad idea for the long run, but just to try your tests it ought to work well enough. (BTW, if a USB storage device containing a paging area drops off=line even momentarily and the system needs to use it, that is the beginning of the end, even though it may take up to a few minutes for everything to lock up. You probably won't be able to do an orderly shutdown, but will instead have to crash it with the power switch. In the case of something like a Pi, this is an unpleasant fact of life, to be sure.) I think I buy your arguments, given the evidence you've collected thus far, including what you've added below. I just like to eliminate possibilities that are much simpler to deal with before facing nastinesses like bugs in the VM subsystem. :-) > > > > It would be neat if some folks used my code to test other arm64 > > contexts and reported the results. I'd be very interested. > > (This is easier to do on devices that do not have massive > > amounts of RAM, which may limit the range of devices or > > device configurations that are reasonable to test.) > > > > There is that other people using other devices have reported > > the behavior that started this investigation. I can produce the > > behavior that they reported, although I've not seen anyone else > > listing specific steps that lead to the problem or ways to tell > > if the symptom is going to happen before it actually does. Nor > > have I seen any other core dump analysis. (I have bugzilla > > submittals 217138 and 217239 tied to symptoms others have > > reported as well as this test program material.) > > > > Also, considering that for my test program I can control which pages > > get the zeroed-problem by read-accessing even one byte of any 4K > > Byte page that I want to make work normally, doing so in the child > > process of the fork, between the fork and the sleep/swap-out, it does > > not suggest USB-device-specific behavior. The read-access is changing > > the status of the page in some way as far as I can tell. > > > > (Such read-accesses in the parent process make no difference to the > > behavior.) > > I should have noted another comparison/contrast between > having memory corruption and not in my context: > > I've tried variants of my test program that do not fork but > just sleep for 60s to allow me to force the swap-out. I > did this before adding fork and before using > parital_test_check, for example. I gradually added things > apparently involved in the reports others had made > until I found a combination that produced a memory > corruption test failure. > > These tests without fork involved find no problems with > the memory content after the swap-in. > > For my test program it appears that fork-before-swap-out > or the like is essential to having the problem occur. > A comment about terminology seems in order here. It bothers me considerably to see you writing "swap out" or "swapping" where it seems like you mean to write "page out" or "paging". A BSD system whose swapping mechanism gets activated has already waded very deeply into the quicksand and frequently cannot be gotten out in a reasonable amount of time even with manual assistance. It is often quicker to crash it, reboot, and wait for the fsck(8) cleanups to complete. Orderly shutdowns, even of the kind that results from a quick poke to the power button, typically get mired in the same mess that already has the system in knots. Also, BSD systems since 3.0BSD, unlike older AT&T (pre-SysVR2.3) systems, do not swap in, just out. A swapped out process, once the system determines that it has adequate resources again to attempt to run the process, will have the interrupted text page paged in and the rest will be paged in by the normal mechanism of page faults and page-in operations. I assume you must already know all this, which is a large part of why it grates on me that you appear to be using the wrong terms. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-arm@freebsd.org Thu Mar 16 09:07: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 6A5AED0F9EB for ; Thu, 16 Mar 2017 09:07:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 2BD811031 for ; Thu, 16 Mar 2017 09:07:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22332 invoked from network); 16 Mar 2017 09:07:25 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 16 Mar 2017 09:07:25 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 16 Mar 2017 05:07:25 -0400 (EDT) Received: (qmail 28883 invoked from network); 16 Mar 2017 09:07:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Mar 2017 09:07:25 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 29159EC7ED9; Thu, 16 Mar 2017 02:07:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <201703160607.v2G67Vwe023153@sdf.org> Date: Thu, 16 Mar 2017 02:07:23 -0700 Cc: FreeBSD Current , freebsd-arm@freebsd.org, freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1019DBB4-5A92-41FE-90B5-63F3F658CF3D@dsl-only.net> References: <201703151315.v2FDFWOr028842@sdf.org> <345EE889-A429-4C13-9B08-B762DA3F4D71@dsl-only.net> <201703160607.v2G67Vwe023153@sdf.org> To: Scott Bennett X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 09:07:32 -0000 On 2017-Mar-15, at 11:07 PM, Scott Bennett wrote: > Mark Millard wrote: >=20 >> [Something strange happened to the automatic CC: fill-in for my = original >> reply. Also I should have mentioned that for my test program if a >> variant is made that does not fork the swapping works fine.] >>=20 >> On 2017-Mar-15, at 9:37 AM, Mark Millard = wrote: >>=20 >>> On 2017-Mar-15, at 6:15 AM, Scott Bennett = wrote: >>>=20 >>>> On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard >>>> wrote: >>>>> On 2017-Mar-14, at 4:44 PM, Bernd Walter = wrote: >>>>>=20 >>>>>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: >>>>>>> [test_check() between the fork and the wait/sleep prevents the >>>>>>> failure from occurring. Even a small access to the memory at >>>>>>> that stage prevents the failure. Details follow.] >>>>>>=20 >>>>>> Maybe a stupid question, since you might have written it = somewhere. >>>>>> What medium do you swap to? >>>>>> I've seen broken firmware on microSD cards doing silent data >>>>>> corruption for some access patterns. >>>>>=20 >>>>> The root filesystem is on a USB SSD on a powered hub. >>>>>=20 >>>>> Only the kernel is from the microSD card. >>>>>=20 >>>>> I have several examples of the USB SSD model and have >>>>> never observed such problems in any other context. >>>>>=20 >>>>> [remainder of irrelevant material deleted --SB] >>>>=20 >>>> You gave a very long-winded non-answer to Bernd's question, so = I'll >>>> repeat it here. What medium do you swap to? >>>=20 >>> My wording of: >>>=20 >>> The root filesystem is on a USB SSD on a powered hub. >>>=20 >>> was definitely poor. It should have explicitly mentioned the >>> swap partition too: >>>=20 >>> The root filesystem and swap partition are both on the same >>> USB SSD on a powered hub. >>>=20 >>> More detail from dmesg -a for usb: >>>=20 >>> usbus0: 12Mbps Full Speed USB v1.0 >>> usbus1: 480Mbps High Speed USB v2.0 >>> usbus2: 12Mbps Full Speed USB v1.0 >>> usbus3: 480Mbps High Speed USB v2.0 >>> ugen0.1: at usbus0 >>> uhub0: on = usbus0 >>> ugen1.1: at usbus1 >>> uhub1: = on usbus1 >>> ugen2.1: at usbus2 >>> uhub2: on = usbus2 >>> ugen3.1: at usbus3 >>> uhub3: = on usbus3 >>> . . . >>> uhub0: 1 port with 1 removable, self powered >>> uhub2: 1 port with 1 removable, self powered >>> uhub1: 1 port with 1 removable, self powered >>> uhub3: 1 port with 1 removable, self powered >>> ugen3.2: at usbus3 >>> uhub4 on uhub3 >>> uhub4: = on usbus3 >>> uhub4: MTT enabled >>> uhub4: 4 ports with 4 removable, self powered >>> ugen3.3: at usbus3 >>> umass0 on uhub4 >>> umass0: on = usbus3 >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>> umass0:0:0: Attached to scbus0 >>> . . . >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> da0: Fixed Direct Access SPC-4 SCSI device >>> da0: Serial Number >>> da0: 40.000MB/s transfers >>>=20 >>> (Edited a bit because there is other material interlaced, even >>> internal to some lines. Also: I removed the serial number of the >>> specific example device.) >=20 > Thank you. That presents a much clearer picture. >>>=20 >>>> I will further note that any kind of USB device cannot = automatically >>>> be trusted to behave properly. USB devices are notorious, for = example, >>>>=20 >>>> [reasons why deleted --SB] >>>>=20 >>>> You should identify where you page/swap to and then try = substituting >>>> a different device for that function as a test to eliminate the = possibility >>>> of a bad storage device/controller. If the problem still occurs, = that >>>> means there still remains the possibility that another controller = or its >>>> firmware is defective instead. It could be a kernel bug, it is = true, but >>>> making sure there is no hardware or firmware error occurring is = important, >>>> and as I say, USB devices should always be considered suspect = unless and >>>> until proven innocent. >>>=20 >>> [FYI: This is a ufs context, not a zfs one.] >=20 > Right. It's only a Pi, after all. :-) It is a Pine64+ 2GB, not an rpi3. >>>=20 >>> I'm aware of such things. There is no evidence that has resulted in >>> suggesting the USB devices that I can replace are a problem. = Otherwise >>> I'd not be going down this path. I only have access to the one arm64 >>> device (a Pine64+ 2GB) so I've no ability to substitution-test what >>> is on that board. >=20 > There isn't even one open port on that hub that you could plug a > flash drive into temporarily to be the paging device? Why do you think that I've never tried alternative devices? It is just that the result was no evidence that my usually-in-use SSD is having a special/local problem: the behavior continues across all such contexts when the Pine64+ 2GB is involved. (Again I have not had access to an alternate to the one arm64 board. That limits my substitution testing possibilities.) Why would you expect a Flash drive to be better than another SSD for such testing? (The SSD that I usually use even happens to be a USB 3.0 SSD, capable of USB 3.0 speeds in USB 3.0 contexts. So is the hub that I usually use for that matter.) > You could then > try your tests before returning to the normal configuration. If there > isn't an open port, then how about plugging a second hub into one of > the first hub's ports and moving the displaced device to the second > hub? A flash drive could then be plugged in. That kind of = configuration > is obviously a bad idea for the long run, but just to try your tests = it > ought to work well enough. I have access to more SSDs that I can use than I do to Flash drives. I see no reason to specifically use a Flash drive. > (BTW, if a USB storage device containing a > paging area drops off=3Dline even momentarily and the system needs to = use > it, that is the beginning of the end, even though it may take up to a = few > minutes for everything to lock up. The system does not lock up, even days or weeks later, with having done dozens of experiments that show memory corruption failures over those days. The only processes showing memory corruption so far are those that were the parent or child for a fork that were later swapped out to have zero RES(ident memory) and then even later swapped back in. The context has no such issues. You are inventing problems that do not exist in my context. That is why none of my list submittals mention such problems: they did not occur. > You probably won't be able to do an > orderly shutdown, but will instead have to crash it with the power = switch. > In the case of something like a Pi, this is an unpleasant fact of = life, > to be sure.) Such things did not occur and has nothing to do with my context so far. > I think I buy your arguments, given the evidence you've collected > thus far, including what you've added below. I just like to eliminate > possibilities that are much simpler to deal with before facing = nastinesses > like bugs in the VM subsystem. :-) When I started this I found no evidence of device-specific problems. My investigation activity goes back to long before my list submittals. And I repeat: Other people have reported the symptoms that started this investigation. They did so before I ever started my activities. They were using none of the specific devices that I have access to. Likely the types of devices were frequently even different, such as a rpi3 instead of a Pine64+ 2GB or a different USB drive. I was able to get the symptoms that they reported. >>> It would be neat if some folks used my code to test other arm64 >>> contexts and reported the results. I'd be very interested. >>> (This is easier to do on devices that do not have massive >>> amounts of RAM, which may limit the range of devices or >>> device configurations that are reasonable to test.) >>>=20 >>> There is that other people using other devices have reported >>> the behavior that started this investigation. I can produce the >>> behavior that they reported, although I've not seen anyone else >>> listing specific steps that lead to the problem or ways to tell >>> if the symptom is going to happen before it actually does. Nor >>> have I seen any other core dump analysis. (I have bugzilla >>> submittals 217138 and 217239 tied to symptoms others have >>> reported as well as this test program material.) >>>=20 >>> Also, considering that for my test program I can control which pages >>> get the zeroed-problem by read-accessing even one byte of any 4K >>> Byte page that I want to make work normally, doing so in the child >>> process of the fork, between the fork and the sleep/swap-out, it = does >>> not suggest USB-device-specific behavior. The read-access is = changing >>> the status of the page in some way as far as I can tell. >>>=20 >>> (Such read-accesses in the parent process make no difference to the >>> behavior.) >>=20 >> I should have noted another comparison/contrast between >> having memory corruption and not in my context: >>=20 >> I've tried variants of my test program that do not fork but >> just sleep for 60s to allow me to force the swap-out. I >> did this before adding fork and before using >> parital_test_check, for example. I gradually added things >> apparently involved in the reports others had made >> until I found a combination that produced a memory >> corruption test failure. >>=20 >> These tests without fork involved find no problems with >> the memory content after the swap-in. >>=20 >> For my test program it appears that fork-before-swap-out >> or the like is essential to having the problem occur. >>=20 > A comment about terminology seems in order here. It bothers > me considerably to see you writing "swap out" or "swapping" where > it seems like you mean to write "page out" or "paging". A BSD > system whose swapping mechanism gets activated has already waded > very deeply into the quicksand and frequently cannot be gotten out > in a reasonable amount of time even with manual assistance. It is > often quicker to crash it, reboot, and wait for the fsck(8) cleanups > to complete. Orderly shutdowns, even of the kind that results from > a quick poke to the power button, typically get mired in the same > mess that already has the system in knots. Also, BSD systems since > 3.0BSD, unlike older AT&T (pre-SysVR2.3) systems, do not swap in, > just out. A swapped out process, once the system determines that it > has adequate resources again to attempt to run the process, will have > the interrupted text page paged in and the rest will be paged in by > the normal mechanism of page faults and page-in operations. I assume > you must already know all this, which is a large part of why it grates > on me that you appear to be using the wrong terms. You apparently did not read any of the material about how the test is done or are unfamiliar with what "stress -m 1 --vm-bytes 1800M" does when there is only 2GB of RAM. I am deliberately inducing swapping in other processes, including the 2 from my test program (after the fork), not just paging. (stress is a port, not part of the base system.) When I say swap-out and swap-in I mean it. =46rom the source code of my test program: sleep(60); // During this manually force this process to // swap out. I use something like: // stress -m 1 --vm-bytes 1800M // in another shell and ^C'ing it after top // shows the swapped status desired. 1800M // just happened to work on the Pine64+ 2GB // that I was using. I watch with top -PCwaopid . That type of stress run uses about 1.8 GiBytes after a bit, which is enough to cause the swapping of other processes, including the two that I am testing (post-fork). (Some RAM is in use already before the stress run, which explains not needing 2 GiBytes to be in use by stress.) Look at a "top -PCwaopid" display: there are columns for RES(ident memory) and SWAP. I cause my 2 test processes to show zero RES and everything under SWAP, starting sometime during the 60s sleep/wait. Why would I cause swapping? Because buildworld causes such swap-outs at times when there is only 2GBytes of RAM, including processes that forked earlier, and as a result the corrupted memory problems show up later in some processes that were swapped out at the time. The build eventually stops for process failures tied to the corruptions of memory in the failing processes. (At least that is what my testing strongly suggests.) But that is a very complicated context to use for analysis or testing of the problem. My test program is vastly simpler and easier/quicker to set up and test when used with stress as well. Such was the kind of thing I was trying to find. I want the Pine64+ 2GB to work well enough to be able to have buildworld (-j 4) complete correctly without having to restart the build --even when everything has to be rebuilt. So I'm trying to find and provide enough evidence to help someone fix the problems that are observed to block such buildworld activity. Again: others have reported such arm64 problems on the lists before I ever got into this activity. The evidence is that the issues are not a local property of my environment. Swapping is supposed to work. I can do buildworld (-j 4) on armv6 (really -mcpu=3Dcortex-a7 so armv7-a) and the swapping it causes works fine. This is true for both a bpim3 (2 GiBytes of RAM) and a rpi2 (1 GiByte of RAM so even more swapping). On a powerpc64 with 16 GiBytes I've built things that caused 26 GiBytes of swap to be in use some of the time (during 4 ld's running in parallel), with lots of processes having zero for RES(ident memory) and all their space listed under SWAP in a "top -PCwaopid" display. This too has no problems with swapping of previously forked processes (or of any other processes). For the likes of a Pine64+ 2GB to be "self hosted"=20 for source-code based updates, swapping of previously forked processes must work and currently such swapping is unreliable. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Mar 16 10:41: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 C9F61D0EE1C for ; Thu, 16 Mar 2017 10:41:18 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 608961D4D for ; Thu, 16 Mar 2017 10:41:17 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: by mail-wr0-x241.google.com with SMTP id g10so5347643wrg.0 for ; Thu, 16 Mar 2017 03:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sylvaingarrigues-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=OhQNUGc/w88dqtVNJ0LUsWDHJl280wWI/swYwvJpZOQ=; b=KnjPDzJIg3GpIZaMly1zThgGTY6yI2CX3ohmX3gFHPpBNYApvPBppA4UxdAaBZTPLZ 8XkmuwZynjRU7eHBrQfCTkbmm7Ive9LtG9GHzmyzZqsbAo6XLSRA1ayvD5zHTQkjRqty 38CkLcYJKPAY2fZ5+fnf9Q4XlEIwKaKZzUkFZ/2FN2ogBA5+1hzAk9/vJXBtnLxX9MJt BvP0WedNkcVYSRftpeZZyFDrTnManFf7Pxx4DyE5o4czAAcd+7b69cijvid/MFFOV1+u LcMfJ3Xu16HKXaVcpvKAJVTByQH7xIA7QdoqM5Y92mhPiwM23GTp4bY7T1tEYdHuFy8V Y42Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=OhQNUGc/w88dqtVNJ0LUsWDHJl280wWI/swYwvJpZOQ=; b=FH+ZmbXvGk9gW3gLDYkyYrQdUW+q/6g4DZXHQM+S1touK82akzcPREy9KTohxXmnhb rPVZE524riHGvyskmU4hjy01+P4i8UyUTAiWwRsu70obvM+l2kmmkdFWVNGoa/XC0mKN m8O1T9ObiVrrXJFAD1aCDqAowvRGl3xz4jZNk0z5o7MfEyux0b5l5EYESV008bHXPslz /2osrBY6MLr5qMILUia8LO8Ibmzuun+d08In4JbFG8zVzw62DzhEQNh+kjPvbuca2OZJ Ucu/LLKqnNHDcpf4sEUkkz98obioD4QNVDGmgaQ/U6VlML646owUgM5mImSysLk3VR8A tKTA== X-Gm-Message-State: AFeK/H2U1VtDBA8HCaBr4C1bqZXgKBNya9zrDpwBEXYymcsmkd6tezhG0O/f7PZKdfqFSg== X-Received: by 10.223.172.101 with SMTP id v92mr8230085wrc.49.1489660875992; Thu, 16 Mar 2017 03:41:15 -0700 (PDT) Received: from [172.21.11.111] ([158.255.96.238]) by smtp.gmail.com with ESMTPSA id y43sm5680574wrd.0.2017.03.16.03.41.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 03:41:15 -0700 (PDT) From: Sylvain Garrigues Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Date: Thu, 16 Mar 2017 11:41:14 +0100 References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> To: freebsd-arm In-Reply-To: <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:41:18 -0000 Hi, > Le 10 mars 2017 =C3=A0 18:51, Mark Millard a = =C3=A9crit : >=20 > So overall: >=20 > If the ABI stays as it is for 11 (or 12), floating point in > general (VFP with or without NEON) and Integer NEON can be > broken when signals are involved that allow the code to keep > going instead of exiting the process. (This means all NEON use > is subject to the issue.) Reading through this thread I understand one can definitely get into = trouble with a system which has CPUTYPE=3Dcortex-a7 in make.conf (or = even some -mcpu=3Dcortex-a7 in some CFLAGS variable there), especially = if a port does FP stuff in a signal handler (because FP registers are = not well preserved / restored on the kernel side). As Michal wrote: > Unfortunately, on armv6, the VFP part of kernel <-> userland = interaction > is broken from day 1.=20 This kind of frightens me, is there any plan to fix it soon (I=E2=80=99d = help if I could)?=20 I understand Andrew's tiny patch = (https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D180669&action=3Ddif= f = ) fixes VFP interactions during signal handling, would that fix all = the "VFP part of kernel <-> userland interaction =C2=BB? Is fixing VFP already being discussed in a Phabricator=E2=80=99s review = or are you guys discussing a backward-compatible alternative to = ABI-breaking (although we are not required to do so since we are still = tier-2) elsewhere? Needless to say, I see strong interest in being able to just dump = "CPUTYPE=3D" in make.conf on arm and be confident my = system will be fine and fine-tuned, just like I do for all my x86/amd64 = machines with such a flag. Have all a good day, Sylvain= From owner-freebsd-arm@freebsd.org Thu Mar 16 15:16: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 3084CD0F291 for ; Thu, 16 Mar 2017 15:16:51 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 C744E185D for ; Thu, 16 Mar 2017 15:16:50 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wr0-x233.google.com with SMTP id u108so34252205wrb.3 for ; Thu, 16 Mar 2017 08:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:references:to:reply-to:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=NnalR0S8S3VJapFc/vTDhTHgiUkbuS1LoXgO78UMk1s=; b=liD3OMwX3u8sjH/Oh9RJCr1NoyQBppM6r/E5iaN6uFevbD5XXFm01747l71+ugzZmb 5/Cw0iPNxIQB6qrHI3y4+L06++HLUibU4pYC7rOVaS59/NUN6vR+ChOmVPuJvU7D9szK v+2vZvHTfpQo68cIttFlnn4s/ZcXJcanNLEVPzXqDcU4sTwJjDRYe5M+bptY+oJVRJb+ 1cYQ9E5ADx7c8cd46cqsfltqk7doN/lG/Np3ntV1eIFGqnAlSeZaeEagQwjk6dSyldWj /oaKKBvRHr27/kgVvj+V2ml+/iu5obUZQiOE3atVXNXomQLm7iVolB6Oq1rc6om0mak6 lVFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:reply-to:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NnalR0S8S3VJapFc/vTDhTHgiUkbuS1LoXgO78UMk1s=; b=WYvC7A43u/hMY9ixIs9JkxGu1zfjzj3CPWieaE9JovKU0YAnO5KF8vfVQ5CCScLmzh MQQ84fvnaU2ouoY7iZbuZcmuurAz75WvxX0QGuRV1Ef0aA512aikOf3mte5ObD3be7U4 6yeTJNHKPl5nGllOMtkun/aucn+wf0hwp0u65QSkI4EFVQhZtxHBXvldG8GQuEDp1IWZ 1KMHeWbnoto/Nv1FEJEx2OF36Ds8IqaSZV0v0RVRBXI2/tP9DoqYTr/S/fRnkBbrXnwz 0DMf5YP+HeD4rcWoZbcDYGqAetTpDwIIwkfm/WdXFRPS7emIDzaUR5YUOBSrR/TCNbma UeQQ== X-Gm-Message-State: AFeK/H3Hvr3a23YwxkRpIN5VJHv2xzNvT8DxvgQnCpReDOa8Rkyc3JSiS5eGqnIEQGqlwA== X-Received: by 10.223.142.40 with SMTP id n37mr8239259wrb.137.1489677408531; Thu, 16 Mar 2017 08:16:48 -0700 (PDT) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id o31sm6569751wrc.27.2017.03.16.08.16.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 08:16:48 -0700 (PDT) From: Michal Meloun X-Google-Original-From: Michal Meloun Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> To: Sylvain Garrigues , freebsd-arm Reply-To: mmel@freebsd.org Message-ID: <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> Date: Thu, 16 Mar 2017 16:16:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 15:16:51 -0000 On 16.03.2017 11:41, Sylvain Garrigues wrote: > Hi, > >> Le 10 mars 2017 à 18:51, Mark Millard a écrit : >> >> So overall: >> >> If the ABI stays as it is for 11 (or 12), floating point in >> general (VFP with or without NEON) and Integer NEON can be >> broken when signals are involved that allow the code to keep >> going instead of exiting the process. (This means all NEON use >> is subject to the issue.) > > Reading through this thread I understand one can definitely get into trouble with a system which has CPUTYPE=cortex-a7 in make.conf (or even some -mcpu=cortex-a7 in some CFLAGS variable there), especially if a port does FP stuff in a signal handler (because FP registers are not well preserved / restored on the kernel side). Not exactly. The problem is common for armv6, irrespective of CPUTYE or CFLAGS value. And can be observed *only* if program uses FP instructions in signal handler. > > As Michal wrote: >> Unfortunately, on armv6, the VFP part of kernel <-> userland interaction >> is broken from day 1. > > This kind of frightens me, is there any plan to fix it soon (I’d help if I could)? > > I understand Andrew's tiny patch (https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180669&action=diff ) fixes VFP interactions during signal handling, would that fix all the "VFP part of kernel <-> userland interaction »? > > Is fixing VFP already being discussed in a Phabricator’s review or are you guys discussing a backward-compatible alternative to ABI-breaking (although we are not required to do so since we are still tier-2) elsewhere? > > Needless to say, I see strong interest in being able to just dump "CPUTYPE=" in make.conf on arm and be confident my system will be fine and fine-tuned, just like I do for all my x86/amd64 machines with such a flag. > Firstly, thanks to Andrew for perfect bug analysis. Currently, you can compile you kernel/userland/port with CPUTYPE/CFLAGS without any additional problem(s). I use this for all my ARM systems for more that last 6-months... The 'other' interfaces are gdb, porcfs, libpthtread. I work on this, but I still have not any output. Michal From owner-freebsd-arm@freebsd.org Thu Mar 16 16:14:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DDEAD0F690 for ; Thu, 16 Mar 2017 16:14:11 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98B811AA4 for ; Thu, 16 Mar 2017 16:14:10 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: by mail-wm0-x229.google.com with SMTP id u132so39324302wmg.0 for ; Thu, 16 Mar 2017 09:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sylvaingarrigues-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jeHFzViCg/8rZI5L2rVdtBXClfNTAXC/M4w0ww46ef0=; b=Nam/FgSGBa/Kuis3o5M3fTYEEgcSibGkOKUdw2eUIw+qnfC31/qW3E70tmHdyFmspM B7R7zgzNStqT9i2zcMRsEuok8jO80XANF7GUTwx2F0CW7ZYaCE7rYWBE4h/blSk6dw+e DcqgPI4gqLRVST6eJGXINyDHvltvA5K9HK47cevI7ulMKxvygr7PVUdMIi6vxw2gB02O pNUA/wyf/gcXKNI2fgvURytdcxeGAt4xSuXtNML4bsjrhDFwNEOfRmxNMxJ2VvVLRFCR TrfEBXeaAi/XkZDEyuugkzCADB63rhyM5tVxHwu+vwXrGhbOgqCCAPzZ6iMQfM1gGLkl XOWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jeHFzViCg/8rZI5L2rVdtBXClfNTAXC/M4w0ww46ef0=; b=Ju0AISs7U679MIHHdbmwdBSEChqqKgkX6A1ilq8SvwmFrGwiQAbreWBYjYkziRI/vf pjMtpIO/lvT8I0SaBTW1KLrRtuDakGhgnbf322dZVMUzEF8Ank/nWyazEJPNMrgHg5sB 78kgtmed771KH8Ye8gQgL5yaycY0i1dm7wnjFHt+shvVC7Rvoy96pZnZGuzdwGsPHr1z aTgsf5TZqTgr9+HQy93aHFxRxI3XXxMCE0qBfcZA0CY84d2/+ZiPyO/7m/6jQFGnh0vt bmH9zHclRW2LFnZl4P9ejs0XzYKWrn20l0kKFAF7QoWS8T1PQkMMa94hMuvj2cRbzUXW Thww== X-Gm-Message-State: AFeK/H2GC0EKMKn6zwr47dUaWt1pmqGk8lUNqlRf6+aIZ6BzZecNhH9uSb4qtYq5Dh9pvA== X-Received: by 10.28.11.69 with SMTP id 66mr27382786wml.38.1489680848724; Thu, 16 Mar 2017 09:14:08 -0700 (PDT) Received: from [172.21.11.111] ([158.255.96.238]) by smtp.gmail.com with ESMTPSA id h3sm6728837wrb.6.2017.03.16.09.14.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 09:14:07 -0700 (PDT) From: Sylvain Garrigues Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Date: Thu, 16 Mar 2017 17:14:06 +0100 In-Reply-To: <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> Cc: freebsd-arm To: mmel@freebsd.org References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 16:14:11 -0000 > Le 16 mars 2017 =C3=A0 16:16, Michal Meloun a = =C3=A9crit : >=20 > Firstly, thanks to Andrew for perfect bug analysis. > Currently, you can compile you kernel/userland/port with = CPUTYPE/CFLAGS > without any additional problem(s). I use this for all my ARM systems = for > more that last 6-months... >=20 > The 'other' interfaces are gdb, porcfs, libpthtread. I work on this, = but > I still have not any output. Thank you so much for your quick feedback Michal. Good to know this = matter is into good hands. I=E2=80=99m afraid I'm still afraid about = `basic=E2=80=99 programs like git being still potentially broken when = kernel+world+ports have CPUTYPE=3Dcortex-a7 in make.conf - Andrew said a = simple `git clone' could fail, more precisely (quoting him): > I have determined that the sha1 failures occur only if the = NEON-enabled > SHA1 block function is interrupted by a signal. This explains why it > fails in git (which is using SIGALRM to set a "display progress" flag) > but not in standalone SHA1 tests; Removing CPUTYPE apparently fixes things hence I=E2=80=99m not 100% = confident yet of keeping CPUTYPE=3Dcortex-a7 myself even if only a few = ports might be affected. Git is an important port, who knows what other = ports are broken :-) Are you also working on the kernel part (as part of = the =E2=80=98other interfaces=E2=80=99 you mentioned) to fix this = fp-register-preserving-during-signal?=20 Thanks one more time for all analyses done so far and thanks in advance = for future work on this matter :-) Cheers=20= From owner-freebsd-arm@freebsd.org Thu Mar 16 16:51: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 A6F8DD0E49B for ; Thu, 16 Mar 2017 16:51:52 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 358C011FF for ; Thu, 16 Mar 2017 16:51:52 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id u132so40204888wmg.0 for ; Thu, 16 Mar 2017 09:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:references:to:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=HqLpQS2osieejPqbjuVLsFnyMOwE+fs7xbiyPvqnNEg=; b=KL0AYpv+OdEsGcjdc5wJLqMmCFf07DArPZFmjmHbQbEGw89U5/ATNhDVNHsI475p34 ryvTNdXV6XgK0FZJ7HyQsOxrrddZiMD708XQctVQ5lebPmgYXjrpHNMRildA/z9HbT+f uea7gDy0bSGbISF/nmWbSoG2lf4M6JNzYs6EFpGVi7y854j2PWjK+LgicQhxNampw7SW hYCSYE9Sh5rHtxFDQj7sGlxNzRjCuu1sW8CbXvQ3UYb3Qr3kOnRQpsjvyDVJhgB3uXEB uzSEs/D5cHT+dEIZUE1MKXz52bzzAGVwKf+3e8D/sRjR/DQvmqjpTgijXs8DOOTefbRt 2ASg== 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:references:to:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=HqLpQS2osieejPqbjuVLsFnyMOwE+fs7xbiyPvqnNEg=; b=ULmJviuB9IoayZPtepfIB4GixNTSd4SRdo/Fg4o0UVXdch8HzdA2cUFM+uH/4n4yTY 31lT7be6HVny3IDLEmm3jzpMp1TuCmqZ3gJ6hnKUzv+WgalPtu1kH9nMM523h60JBZ2+ 9EtCsqNVoEkLgEkEr/toi1haNXlze8Yo3Qoqz2wNtWlLP5u+p5WM8fJaY7hP/ibTmXhj 6OxnMZ0mTzpunFbEc5h8j/X1XVDIzbVjZhQ8pc7WVBccAXfDVWQ+T6+8HeA2e+WGKy5g Wm7B+iuquPRtD2BWyOEhUCJdQYXrO63OkHjMYTgQh09Dkl7GGu1DND9KeGKRHms7gjVB IHxQ== X-Gm-Message-State: AFeK/H3qTJVHK0S5piVPaHMt6PPVojOOGB2oRTMkbyhQjpGwuT41p1zyh9aY2wGWdxJISg== X-Received: by 10.28.72.193 with SMTP id v184mr25498459wma.105.1489683110331; Thu, 16 Mar 2017 09:51:50 -0700 (PDT) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id k8sm6767595wre.19.2017.03.16.09.51.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 09:51:49 -0700 (PDT) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> To: Sylvain Garrigues Cc: freebsd-arm Message-ID: <67504df9-9452-3ad3-b3b0-01d1a03727cc@freebsd.org> Date: Thu, 16 Mar 2017 17:51:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 16:51:52 -0000 On 16.03.2017 17:14, Sylvain Garrigues wrote: > >> Le 16 mars 2017 à 16:16, Michal Meloun > > a écrit : >> >> Firstly, thanks to Andrew for perfect bug analysis. >> Currently, you can compile you kernel/userland/port with CPUTYPE/CFLAGS >> without any additional problem(s). I use this for all my ARM systems for >> more that last 6-months... >> >> The 'other' interfaces are gdb, porcfs, libpthtread. I work on this, but >> I still have not any output. > > Thank you so much for your quick feedback Michal. Good to know this > matter is into good hands. I’m afraid I'm still afraid about `basic’ > programs like git being still potentially broken when > kernel+world+ports have CPUTYPE=cortex-a7 in make.conf - Andrew said a > simple `git clone' could fail, more precisely (quoting him): >> I have determined that the sha1 failures occur only if the NEON-enabled >> SHA1 block function is interrupted by a signal. This explains why it >> fails in git (which is using SIGALRM to set a "display progress" flag) >> but not in standalone SHA1 tests; > > Removing CPUTYPE apparently fixes things hence I’m not 100% confident > yet of keeping CPUTYPE=cortex-a7 myself even if only a few ports might > be affected. Git is an important port, who knows what other ports are > broken :-) Are you also working on the kernel part (as part of the > ‘other interfaces’ you mentioned) to fix this > fp-register-preserving-during-signal? > No, the issue is very clear (again, thanks to Andrew), and it's not related to CPUTYPE. Is this enough to confirm that the FPU instructions in a signal handler is not used so frequently? https://imagebin.ca/v/3FmLkPuRZ1IO All used ports from this picture (KDE4, LibreOffice + dependencies ) are built on Jetson TK1, with -mcpu=Cortex-A15 Michal From owner-freebsd-arm@freebsd.org Thu Mar 16 17:09:00 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 9530AD0EB7C for ; Thu, 16 Mar 2017 17:09:00 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 67433116E for ; Thu, 16 Mar 2017 17:08:59 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (global-5-142.nat-2.net.cam.ac.uk [131.111.5.142]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 47A5D4E718 for ; Thu, 16 Mar 2017 17:08:52 +0000 (UTC) Date: Thu, 16 Mar 2017 17:08:51 +0000 From: Andrew Turner To: Subject: Making INTRNG a requirement on armv6 Message-ID: X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:09:00 -0000 Hello arm, I would like to make INTRNG a requirement on armv6. This is to help with moving more armv6 kernel configurations into GENERIC. It also helps when we want a child interrupt controller, e.g. a GPIO driver. Most of the current armv6 kernel configurations already use INTRNG, so only a few places need to be updated.=20 I=E2=80=99ve run a test build making it an error to not have INTRNG enabled= and found the following armv6 configs fail: AML8726 ARMADAXP DIGI-CCWMX53 EFIKA_MX IMX53 IMX53-QSB VERSATILEPB YYHD18 I'm interested in people who have this hardware to try enabling INTRNG and testing. Note that this may require the interrupt controller driver the SoC uses to be ported to INTRNG. Andrew From owner-freebsd-arm@freebsd.org Thu Mar 16 17:27:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A689D0F41B for ; Thu, 16 Mar 2017 17:27:16 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E30D51FF4; Thu, 16 Mar 2017 17:27:15 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.1] (port=52118 helo=caithnard.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1coZB3-000HRK-Vp; Thu, 16 Mar 2017 17:27:06 +0000 Received: from [127.0.0.1] (port=43613 helo=caithnard.riddles.org.uk) by caithnard.riddles.org.uk with esmtp (Exim 4.89 (FreeBSD)) (envelope-from ) id 1coZB3-000HlW-6X; Thu, 16 Mar 2017 17:27:05 +0000 From: Andrew Gierth To: Sylvain Garrigues Cc: mmel@freebsd.org, freebsd-arm Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: (Sylvain Garrigues's message of "Thu, 16 Mar 2017 17:14:06 +0100") Message-ID: <87pohh2n3c.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Thu, 16 Mar 2017 17:27:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:27:16 -0000 >>>>> "Sylvain" =3D=3D Sylvain Garrigues wri= tes: Sylvain> Thank you so much for your quick feedback Michal. Good to know Sylvain> this matter is into good hands. I=E2=80=99m afraid I'm still afra= id Sylvain> about `basic=E2=80=99 programs like git being still potentially b= roken Sylvain> when kernel+world+ports have CPUTYPE=3Dcortex-a7 in make.conf - Sylvain> Andrew said a simple `git clone' could fail, more precisely Sylvain> (quoting him): =20 >> I have determined that the sha1 failures occur only if the >> NEON-enabled SHA1 block function is interrupted by a signal. This >> explains why it fails in git (which is using SIGALRM to set a >> "display progress" flag) but not in standalone SHA1 tests; Sylvain> Removing CPUTYPE apparently fixes things hence I=E2=80=99m not 10= 0% Sylvain> confident yet of keeping CPUTYPE=3Dcortex-a7 myself even if only Sylvain> a few ports might be affected. Git is an important port, who Sylvain> knows what other ports are broken :-) Let me clarify this. Without CPUTYPE, things _appear_ to work because only explicit use of floating-point exposes the bug, and it's extremely rare for programs to use floating-point in signal handlers, and even then the only result would be incorrect floating-point calculations in the interrupted code. With CPUTYPE, the compiler can generate NEON instructions for integer code; even without heavy optimization enabled, it might choose to use NEON register load/store to copy small data structures for example. One piece of code which is affected by this is the signal handling functions in libthr, which wrap the program's own signal handler functions; so now, _every_ signal handler in a program linked with libthr uses the NEON registers, and the result isn't limited to corrupting floating-point calculations but can corrupt data structures or copied memory, or the results of vectorized code. The specific failures that I saw -- git failing, emacs crashing, errors from openssl speed -- were all of this second kind and therefore not directly reproducible without CPUTYPE; but the test program I gave for the bug report demonstrates the problem by using explicit floating-point (in a highly contrived way) and therefore reproduces the issue even without CPUTYPE. So even though the bug is in the kernel and affects all armv6 targets whether NEON is in use or not, the chances of actually hitting it are pretty negligible if you built the world without CPUTYPE. But if you build with CPUTYPE, then potentially any code that catches a signal is affected; it's just that programs (like git) that combine signal handling with vectorized crypto code, or programs (like emacs) that use signal handling very heavily, have the greatest probability of failure. tl/dr: building without CPUTYPE is a workaround that simply reduces both the chance and severity of failure; building with CPUTYPE currently breaks almost everything, but with a probability that varies wildly depending on what the application does. --=20 Andrew. From owner-freebsd-arm@freebsd.org Thu Mar 16 17:37:41 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F709D0F786 for ; Thu, 16 Mar 2017 17:37:41 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DEA7014F1 for ; Thu, 16 Mar 2017 17:37:40 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 21f0786c-0a6f-11e7-b3c2-c9f38144898e 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 outbound2.ore.mailhop.org (Halon) with ESMTPSA id 21f0786c-0a6f-11e7-b3c2-c9f38144898e; Thu, 16 Mar 2017 17:36:48 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2GHbWtO006961; Thu, 16 Mar 2017 11:37:32 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1489685852.40576.165.camel@freebsd.org> Subject: Re: Making INTRNG a requirement on armv6 From: Ian Lepore To: Andrew Turner , freebsd-arm@freebsd.org Date: Thu, 16 Mar 2017 11:37:32 -0600 In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-7" 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:37:41 -0000 On Thu, 2017-03-16 at 17:08 +0000, Andrew Turner wrote: > Hello arm, > > I would like to make INTRNG a requirement on armv6. This is to help > with moving more armv6 kernel configurations into GENERIC. It also > helps when we want a child interrupt controller, e.g. a GPIO driver. > > Most of the current armv6 kernel configurations already use INTRNG, > so > only a few places need to be updated.  > > I¢ve run a test build making it an error to not have INTRNG enabled > and > found the following armv6 configs fail: > > AML8726 > ARMADAXP > DIGI-CCWMX53 > EFIKA_MX > IMX53 > IMX53-QSB > VERSATILEPB > YYHD18 > > I'm interested in people who have this hardware to try enabling > INTRNG > and testing. Note that this may require the interrupt controller > driver > the SoC uses to be ported to INTRNG. > > Andrew I'll try to find time to convert the imx5x driver this weekend. -- Ian From owner-freebsd-arm@freebsd.org Thu Mar 16 18:07: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 9C264D0F1BE for ; Thu, 16 Mar 2017 18:07:43 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::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 2E79C154F for ; Thu, 16 Mar 2017 18:07:42 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: by mail-wr0-x244.google.com with SMTP id u48so6887918wrc.1 for ; Thu, 16 Mar 2017 11:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sylvaingarrigues-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=hT6Y7Pf8ulvJfUWCM1txj+cMxt564LmaewpT/ol6gHo=; b=xNHA5HW3O42TocomDzbkWt006Gipr09drWRpKu0uJ73PNBgQZZUdM42rPqppuxeeeI fNtArR6kQJbppv65zjyQJGdEcy75AUhYdYQkEsBHsB/u7W2asmBhOat45lRer/+g5OPl Bn+A8arLQraZz213by2QNe9Ki4IWMN+e18zX1g/6i6lVDHXDZkxXdGU2bgO4XC6jB7eC 35Onq8uC2tSPi3eO2atd3zgBTGkn+GYup0Lo1Nn7eQoAErSyetGS0wr+rwWE7XaS4j/W kilGXMuKEr3wqICMe9mabJa5pR0b9aOwaNXv59qy29DEIaxxoTw0dDalgrOjrkVCTf2j 5OTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=hT6Y7Pf8ulvJfUWCM1txj+cMxt564LmaewpT/ol6gHo=; b=SY/xnLdf0oF3fJkkPjPFwcrYP8WVknivVsViA3kYEydDppL/J4pi5CbnduKydiUveY JpVPafmUQSGC1ho2WiDUStDyFrdoGzZJAXMwBLr0AYoI4zhNMWlnuvROYEdHlgzZrxQL TLzL6UgGSOqhyHfwMAxvR1buiBrBuk7OKLUPEECvtlQPyx8hiW0l+bGcXIZyH0Xf3f0d MY7oOS60g6/xbHIfvZ/neYrpzomu8JRu5J+xDWp9NsUXdla6fNxPSG26HYvGTk8j8mt2 Ed/fUz6IshFRn3tAbM/EH19ydC9ySSYnRTrF+GiNF+J3LY35ODN2ub4308SACkGAPfcr 64wQ== X-Gm-Message-State: AFeK/H2CCyZ+hW9l6rDW63m7WmVC0TFvCj+logcm9gGdrIHwnb71hKyalDMoPQ9zDg9ZOQ== X-Received: by 10.223.156.2 with SMTP id f2mr2618584wrc.176.1489687661256; Thu, 16 Mar 2017 11:07:41 -0700 (PDT) Received: from [172.21.11.111] ([158.255.96.238]) by smtp.gmail.com with ESMTPSA id k43sm7042767wrk.42.2017.03.16.11.07.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 11:07:40 -0700 (PDT) From: Sylvain Garrigues Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Date: Thu, 16 Mar 2017 19:07:39 +0100 References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> <87pohh2n3c.fsf@news-spur.riddles.org.uk> To: Andrew Gierth , mmel@freebsd.org, freebsd-arm In-Reply-To: <87pohh2n3c.fsf@news-spur.riddles.org.uk> Message-Id: X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 18:07:43 -0000 > Le 16 mars 2017 =C3=A0 18:27, Andrew Gierth = a =C3=A9crit : >=20 > tl/dr: building without CPUTYPE is a workaround that simply reduces = both > the chance and severity of failure; building with CPUTYPE currently > breaks almost everything, but with a probability that varies wildly > depending on what the application does. Got it now, thank you both Andrew and Michal. I can=E2=80=99t imagine = how lucky we are to have you guys analyze these behaviors so quickly and = accurately.=20 My conclusion of these discussions seems to be: - Andrew, you proposed a kernel patch which fixes / handles the saving = and restoring of FP registers during signal (kernel side). It seems it = greatly reduces the failure probability by allowing applications to have = FPU instructions in signal handlers. But it breaks ABI. - Michal, you mentioned you=E2=80=99d like to fix this in a way that = doesn=E2=80=99t break ABI, and that: * the "VFP part of kernel <-> userland interaction is broken from = day 1 =C2=BB <<=3D=3D was it just this signal part which was broken? * and "the struct fpreg is also wrong and I'm not sure if or how we = can to fix this in compatible way =C2=BB <<=3D=3D Andrew=E2=80=99s patch = doesn=E2=80=99t fix this right? Is this a serious problem doctor? What = are the symptoms? So what are you guys gonna do about all this, are you going to address = these issues, are you going to break the ABI in 12-CURRENT? Can wait to = hear about the next steps, the suspense is terrible :-)= From owner-freebsd-arm@freebsd.org Thu Mar 16 18:09: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 79EC0D0F21F for ; Thu, 16 Mar 2017 18:09:51 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from lungold.riddles.org.uk (lungold.riddles.org.uk [82.68.208.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22F84160E; Thu, 16 Mar 2017 18:09:50 +0000 (UTC) (envelope-from andrew@tao11.riddles.org.uk) Received: from [192.168.127.1] (port=44114 helo=caithnard.riddles.org.uk) by lungold.riddles.org.uk with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1coZqO-000HUd-0F; Thu, 16 Mar 2017 18:09:48 +0000 Received: from [127.0.0.1] (port=23618 helo=caithnard.riddles.org.uk) by caithnard.riddles.org.uk with esmtp (Exim 4.89 (FreeBSD)) (envelope-from ) id 1coZqN-000I0E-BS; Thu, 16 Mar 2017 18:09:47 +0000 From: Andrew Gierth To: Michal Meloun Cc: Sylvain Garrigues , mmel@freebsd.org, freebsd-arm Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? In-Reply-To: <67504df9-9452-3ad3-b3b0-01d1a03727cc@freebsd.org> (Michal Meloun's message of "Thu, 16 Mar 2017 17:51:49 +0100") Message-ID: <87lgs52kke.fsf@news-spur.riddles.org.uk> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> <67504df9-9452-3ad3-b3b0-01d1a03727cc@freebsd.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Date: Thu, 16 Mar 2017 18:09:47 +0000 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 18:09:51 -0000 >>>>> "Michal" == Michal Meloun writes: Michal> Is this enough to confirm that the FPU instructions in a signal Michal> handler is not used so frequently? Actually what it confirms is that it's rare for applications to use signal delivery heavily. Emacs is a notorious exception to this, since it has used SIGIO since time immemorial to have incoming keystrokes interrupt terminal redisplay (important on slow serial terminals, oh the nostalgia) and it kept the same basic design when moving to X, so it now gets SIGIO on X events, resulting in hundreds of signal deliveries just from moving the mouse past its window. To say that this is not normal application behaviour would be a massive understatement. The problem manifests in git clone despite the fact that signal delivery is infrequent there simply because it spends so much of its time executing the vectorized SHA1 block update; again, normal applications don't do this kind of thing, and are likely to use the VFP/NEON registers too transiently for there to be a significant chance of detectable corruption. Even most crypto apps wouldn't often take a signal delivery while running crypto code. As an example, I happen to be very familiar with PostgreSQL, which by normal standards (as opposed to Emacs standards) is a fairly heavy user of signals, and I don't think I could come up with a reliable demonstration of it being affected by this bug (except maybe by using SSL client connections). What I _would_ expect is that pgsql running on affected systems would experience a very slow rate of subtle data corruption problems, which might or might not ever be noticed. -- Andrew. From owner-freebsd-arm@freebsd.org Thu Mar 16 18:44: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 3FD78D0FD4C for ; Thu, 16 Mar 2017 18:44:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 F405B18C6 for ; Thu, 16 Mar 2017 18:44:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18902 invoked from network); 16 Mar 2017 18:44:28 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 16 Mar 2017 18:44:28 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 16 Mar 2017 14:44:28 -0400 (EDT) Received: (qmail 7637 invoked from network); 16 Mar 2017 18:44:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Mar 2017 18:44:28 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 7C05EEC90DB; Thu, 16 Mar 2017 11:44:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? From: Mark Millard In-Reply-To: <87pohh2n3c.fsf@news-spur.riddles.org.uk> Date: Thu, 16 Mar 2017 11:44:26 -0700 Cc: freebsd-arm , mmel@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6D4C0F5B-6F13-44DE-A1C6-83A1D3608EB4@dsl-only.net> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> <87pohh2n3c.fsf@news-spur.riddles.org.uk> To: Andrew Gierth , Sylvain Garrigues X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 18:44:31 -0000 On 2017-Mar-16, at 10:27 AM, Andrew Gierth = wrote: >=20 >>>>>> "Sylvain" =3D=3D Sylvain Garrigues = writes: >=20 > Sylvain> Thank you so much for your quick feedback Michal. Good to = know > Sylvain> this matter is into good hands. I=E2=80=99m afraid I'm still = afraid > Sylvain> about `basic=E2=80=99 programs like git being still = potentially broken > Sylvain> when kernel+world+ports have CPUTYPE=3Dcortex-a7 in make.conf = - > Sylvain> Andrew said a simple `git clone' could fail, more precisely > Sylvain> (quoting him): >=20 >>> I have determined that the sha1 failures occur only if the >>> NEON-enabled SHA1 block function is interrupted by a signal. This >>> explains why it fails in git (which is using SIGALRM to set a >>> "display progress" flag) but not in standalone SHA1 tests; >=20 > Sylvain> Removing CPUTYPE apparently fixes things hence I=E2=80=99m = not 100% > Sylvain> confident yet of keeping CPUTYPE=3Dcortex-a7 myself even if = only > Sylvain> a few ports might be affected. Git is an important port, who > Sylvain> knows what other ports are broken :-) >=20 > Let me clarify this. >=20 > Without CPUTYPE, things _appear_ to work because only explicit use of > floating-point exposes the bug, and it's extremely rare for programs = to > use floating-point in signal handlers, and even then the only result > would be incorrect floating-point calculations in the interrupted = code. >=20 > With CPUTYPE, the compiler can generate NEON instructions for integer > code; even without heavy optimization enabled, it might choose to use > NEON register load/store to copy small data structures for example. = One > piece of code which is affected by this is the signal handling = functions > in libthr, which wrap the program's own signal handler functions; so > now, _every_ signal handler in a program linked with libthr uses the > NEON registers, and the result isn't limited to corrupting > floating-point calculations but can corrupt data structures or copied > memory, or the results of vectorized code. >=20 > The specific failures that I saw -- git failing, emacs crashing, = errors > from openssl speed -- were all of this second kind and therefore not > directly reproducible without CPUTYPE; but the test program I gave for > the bug report demonstrates the problem by using explicit = floating-point > (in a highly contrived way) and therefore reproduces the issue even > without CPUTYPE. >=20 > So even though the bug is in the kernel and affects all armv6 targets > whether NEON is in use or not, the chances of actually hitting it are > pretty negligible if you built the world without CPUTYPE. But if you > build with CPUTYPE, then potentially any code that catches a signal is > affected; it's just that programs (like git) that combine signal > handling with vectorized crypto code, or programs (like emacs) that = use > signal handling very heavily, have the greatest probability of = failure. >=20 > tl/dr: building without CPUTYPE is a workaround that simply reduces = both > the chance and severity of failure; building with CPUTYPE currently > breaks almost everything, but with a probability that varies wildly > depending on what the application does. >=20 > --=20 > Andrew. As I understand there are also issues beyond the fix for signal delivery. On 2017-Mar-12, at 12:17 AM, Michal Meloun = wrote: > The struct fpreg is also wrong and I'm not sure if > or how we can to fix this in compatible way. Looking up some details shows sys/arm/include/reg.h with: struct fpreg { unsigned int fpr_fpsr; fp_reg_t fpr[8]; }; [Covers only 8 floating point registers?] and shows sys/arm/include/fp.h with: typedef struct fp_extended_precision { u_int32_t fp_exponent; u_int32_t fp_mantissa_hi; u_int32_t fp_mantissa_lo; } fp_extended_precision_t; typedef struct fp_extended_precision fp_reg_t; . . . /* * Type for a saved FP context, if we want to translate the context to a * user-readable form */ typedef struct { u_int32_t fpsr; fp_extended_precision_t regs[8]; } fp_state_t; So each of: struct fpreg fp_state_t has room for 8 instances of 96 bits (beyond fpsr), not sufficient for 32 double precision (i.e., 64-bit) registers. The arm code also has: # grep -r "\" /usr/src/sys/arm/ | more /usr/src/sys/arm/arm/machdep.c:fill_fpregs(struct thread *td, struct = fpreg *regs) /usr/src/sys/arm/arm/machdep.c:set_fpregs(struct thread *td, struct = fpreg *regs) /usr/src/sys/arm/include/reg.h:struct fpreg { /usr/src/sys/arm/include/reg.h:int fill_fpregs(struct thread *, = struct fpreg *); /usr/src/sys/arm/include/reg.h:int set_fpregs(struct thread *, = struct fpreg *); And the system has: /usr/src/sys/sys/procfs.h:typedef struct fpreg fpregset_t; /usr/src/sys/sys/procfs.h: size_t pr_fpregsetsz; /* = sizeof(fpregset_t) (1) */ /usr/src/sys/sys/procfs.h:typedef fpregset_t prfpregset_t; /usr/src/sys/sys/ptrace.h:struct fpreg; /usr/src/sys/sys/ptrace.h:int proc_read_fpregs(struct thread *_td, = struct fpreg *_fpreg); /usr/src/sys/sys/ptrace.h:int proc_write_fpregs(struct thread *_td, = struct fpreg *_fpreg); and: /usr/src/sys/kern/sys_process.c: * Ptrace doesn't support fpregs at all, = and there are no security holes /usr/src/sys/kern/sys_process.c: * or translations for fpregs, so we can = just copy them. /usr/src/sys/kern/sys_process.c:proc_read_fpregs(struct thread *td, = struct fpreg *fpregs) /usr/src/sys/kern/sys_process.c: PROC_ACTION(fill_fpregs(td, = fpregs)); /usr/src/sys/kern/sys_process.c:proc_write_fpregs(struct thread *td, = struct fpreg *fpregs) /usr/src/sys/kern/sys_process.c: PROC_ACTION(set_fpregs(td, = fpregs)); /usr/src/sys/kern/sys_process.c: struct fpreg fpreg; /usr/src/sys/kern/sys_process.c: error =3D = COPYIN(uap->addr, &r.fpreg, sizeof r.fpreg); /usr/src/sys/kern/sys_process.c: error =3D = COPYOUT(&r.fpreg, uap->addr, sizeof r.fpreg); /usr/src/sys/kern/sys_process.c: error =3D = PROC_WRITE(fpregs, td2, addr); /usr/src/sys/kern/sys_process.c: error =3D = PROC_READ(fpregs, td2, addr); and there is use of some of the above in: /usr/src/sys/kern/sys_process.c: * proc_read_fpregs, proc_write_fpregs /usr/src/sys/kern/sys_process.c:proc_read_fpregs(struct thread *td, = struct fpreg *fpregs) /usr/src/sys/kern/sys_process.c: PROC_ACTION(fill_fpregs(td, = fpregs)); /usr/src/sys/kern/sys_process.c:proc_write_fpregs(struct thread *td, = struct fpreg *fpregs) /usr/src/sys/kern/sys_process.c: PROC_ACTION(set_fpregs(td, = fpregs)); /usr/src/sys/kern/sys_process.c:proc_read_fpregs32(struct thread *td, = struct fpreg32 *fpregs32) /usr/src/sys/kern/sys_process.c: PROC_ACTION(fill_fpregs32(td, = fpregs32)); /usr/src/sys/kern/sys_process.c:proc_write_fpregs32(struct thread *td, = struct fpreg32 *fpregs32) /usr/src/sys/kern/sys_process.c: PROC_ACTION(set_fpregs32(td, = fpregs32)); I may not have found everything relevant. It appears that fp_state_t is unused in /usr/src/sys/ . Note: I was looking at /usr/src/sys/ for. . . # uname -paKU FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT r314687M amd64 = amd64 1200023 1200023 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Mar 16 18:57: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 9DB0AD0F1D4 for ; Thu, 16 Mar 2017 18:57:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-182.reflexion.net [208.70.211.182]) (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 4897811E0 for ; Thu, 16 Mar 2017 18:57:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6103 invoked from network); 16 Mar 2017 18:57:41 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 16 Mar 2017 18:57:41 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 16 Mar 2017 14:57:41 -0400 (EDT) Received: (qmail 15463 invoked from network); 16 Mar 2017 18:57:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Mar 2017 18:57:41 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id A8BC3EC902B; Thu, 16 Mar 2017 11:57:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? From: Mark Millard In-Reply-To: <87lgs52kke.fsf@news-spur.riddles.org.uk> Date: Thu, 16 Mar 2017 11:57:40 -0700 Cc: Michal Meloun , Sylvain Garrigues , freebsd-arm , mmel@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> <67504df9-9452-3ad3-b3b0-01d1a03727cc@freebsd.org> <87lgs52kke.fsf@news-spur.riddles.org.uk> To: Andrew Gierth X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 18:57:48 -0000 On 2017-Mar-16, at 11:09 AM, Andrew Gierth wrote: >>>>>> "Michal" =3D=3D Michal Meloun writes: >=20 > Michal> Is this enough to confirm that the FPU instructions in a = signal > Michal> handler is not used so frequently? >=20 > Actually what it confirms is that it's rare for applications to use > signal delivery heavily. Just a side note in this area: buildworld buildkernel (e.g., -j 4) makes heavy SIGCHLD signal usage overall but seems to survive relative to these VFP/NEON issues. I've not looked into why but may be the processes receiving the signals make no use of NEON for integer activity (and has no floating point code?). > Emacs is a notorious exception to this, since it has used SIGIO since > time immemorial to have incoming keystrokes interrupt terminal = redisplay > (important on slow serial terminals, oh the nostalgia) and it kept the > same basic design when moving to X, so it now gets SIGIO on X events, > resulting in hundreds of signal deliveries just from moving the mouse > past its window. To say that this is not normal application behaviour > would be a massive understatement. >=20 > The problem manifests in git clone despite the fact that signal = delivery > is infrequent there simply because it spends so much of its time > executing the vectorized SHA1 block update; again, normal applications > don't do this kind of thing, and are likely to use the VFP/NEON > registers too transiently for there to be a significant chance of > detectable corruption. Even most crypto apps wouldn't often take a > signal delivery while running crypto code. >=20 > As an example, I happen to be very familiar with PostgreSQL, which by > normal standards (as opposed to Emacs standards) is a fairly heavy = user > of signals, and I don't think I could come up with a reliable > demonstration of it being affected by this bug (except maybe by using > SSL client connections). What I _would_ expect is that pgsql running = on > affected systems would experience a very slow rate of subtle data > corruption problems, which might or might not ever be noticed. >=20 > --=20 > Andrew. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Mar 16 19:06: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 D3595D0F50E for ; Thu, 16 Mar 2017 19:06:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-177.reflexion.net [208.70.211.177]) (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 92F8417A2 for ; Thu, 16 Mar 2017 19:06:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17915 invoked from network); 16 Mar 2017 19:06:06 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Mar 2017 19:06:06 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 16 Mar 2017 15:06:06 -0400 (EDT) Received: (qmail 32300 invoked from network); 16 Mar 2017 19:06:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Mar 2017 19:06:06 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 8C793EC9026; Thu, 16 Mar 2017 12:06:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? From: Mark Millard In-Reply-To: <6D4C0F5B-6F13-44DE-A1C6-83A1D3608EB4@dsl-only.net> Date: Thu, 16 Mar 2017 12:06:04 -0700 Cc: freebsd-arm , mmel@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <91BB5C78-B2F8-458E-B5F4-DE31068D5943@dsl-only.net> References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <8737ely05c.fsf@news-spur.riddles.org.uk> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> <87pohh2n3c.fsf@news-spur.riddles.org.uk> <6D4C0F5B-6F13-44DE-A1C6-83A1D3608EB4@dsl-only.net> To: Andrew Gierth , Sylvain Garrigues X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 19:06:13 -0000 [I accidentally included some fpregs32 material, so this corrects the impression that might leave.] On 2017-Mar-16, at 11:44 AM, Mark Millard = wrote: > On 2017-Mar-16, at 10:27 AM, Andrew Gierth wrote: >>=20 >>>>>>> "Sylvain" =3D=3D Sylvain Garrigues = writes: >>=20 >> Sylvain> Thank you so much for your quick feedback Michal. Good to = know >> Sylvain> this matter is into good hands. I=E2=80=99m afraid I'm still = afraid >> Sylvain> about `basic=E2=80=99 programs like git being still = potentially broken >> Sylvain> when kernel+world+ports have CPUTYPE=3Dcortex-a7 in = make.conf - >> Sylvain> Andrew said a simple `git clone' could fail, more precisely >> Sylvain> (quoting him): >>=20 >>>> I have determined that the sha1 failures occur only if the >>>> NEON-enabled SHA1 block function is interrupted by a signal. This >>>> explains why it fails in git (which is using SIGALRM to set a >>>> "display progress" flag) but not in standalone SHA1 tests; >>=20 >> Sylvain> Removing CPUTYPE apparently fixes things hence I=E2=80=99m = not 100% >> Sylvain> confident yet of keeping CPUTYPE=3Dcortex-a7 myself even if = only >> Sylvain> a few ports might be affected. Git is an important port, who >> Sylvain> knows what other ports are broken :-) >>=20 >> Let me clarify this. >>=20 >> Without CPUTYPE, things _appear_ to work because only explicit use of >> floating-point exposes the bug, and it's extremely rare for programs = to >> use floating-point in signal handlers, and even then the only result >> would be incorrect floating-point calculations in the interrupted = code. >>=20 >> With CPUTYPE, the compiler can generate NEON instructions for integer >> code; even without heavy optimization enabled, it might choose to use >> NEON register load/store to copy small data structures for example. = One >> piece of code which is affected by this is the signal handling = functions >> in libthr, which wrap the program's own signal handler functions; so >> now, _every_ signal handler in a program linked with libthr uses the >> NEON registers, and the result isn't limited to corrupting >> floating-point calculations but can corrupt data structures or copied >> memory, or the results of vectorized code. >>=20 >> The specific failures that I saw -- git failing, emacs crashing, = errors >> from openssl speed -- were all of this second kind and therefore not >> directly reproducible without CPUTYPE; but the test program I gave = for >> the bug report demonstrates the problem by using explicit = floating-point >> (in a highly contrived way) and therefore reproduces the issue even >> without CPUTYPE. >>=20 >> So even though the bug is in the kernel and affects all armv6 targets >> whether NEON is in use or not, the chances of actually hitting it are >> pretty negligible if you built the world without CPUTYPE. But if you >> build with CPUTYPE, then potentially any code that catches a signal = is >> affected; it's just that programs (like git) that combine signal >> handling with vectorized crypto code, or programs (like emacs) that = use >> signal handling very heavily, have the greatest probability of = failure. >>=20 >> tl/dr: building without CPUTYPE is a workaround that simply reduces = both >> the chance and severity of failure; building with CPUTYPE currently >> breaks almost everything, but with a probability that varies wildly >> depending on what the application does. >>=20 >> --=20 >> Andrew. >=20 > As I understand there are also issues beyond the fix for signal > delivery. >=20 > On 2017-Mar-12, at 12:17 AM, Michal Meloun = wrote: >=20 >> The struct fpreg is also wrong and I'm not sure if >> or how we can to fix this in compatible way. >=20 > Looking up some details shows sys/arm/include/reg.h with: >=20 > struct fpreg { > unsigned int fpr_fpsr; > fp_reg_t fpr[8]; > }; >=20 > [Covers only 8 floating point registers?] >=20 > and shows sys/arm/include/fp.h with: >=20 > typedef struct fp_extended_precision { > u_int32_t fp_exponent; > u_int32_t fp_mantissa_hi; > u_int32_t fp_mantissa_lo; > } fp_extended_precision_t; >=20 > typedef struct fp_extended_precision fp_reg_t; > . . . > /* > * Type for a saved FP context, if we want to translate the context to = a > * user-readable form > */ >=20 > typedef struct { > u_int32_t fpsr; > fp_extended_precision_t regs[8]; > } fp_state_t; >=20 >=20 > So each of: >=20 > struct fpreg > fp_state_t >=20 > has room for 8 instances of 96 bits (beyond fpsr), not sufficient > for 32 double precision (i.e., 64-bit) registers. >=20 > The arm code also has: >=20 > # grep -r "\" /usr/src/sys/arm/ | more > /usr/src/sys/arm/arm/machdep.c:fill_fpregs(struct thread *td, struct = fpreg *regs) > /usr/src/sys/arm/arm/machdep.c:set_fpregs(struct thread *td, struct = fpreg *regs) > /usr/src/sys/arm/include/reg.h:struct fpreg { > /usr/src/sys/arm/include/reg.h:int fill_fpregs(struct thread *, = struct fpreg *); > /usr/src/sys/arm/include/reg.h:int set_fpregs(struct thread *, = struct fpreg *); >=20 > And the system has: >=20 > /usr/src/sys/sys/procfs.h:typedef struct fpreg fpregset_t; > /usr/src/sys/sys/procfs.h: size_t pr_fpregsetsz; /* = sizeof(fpregset_t) (1) */ > /usr/src/sys/sys/procfs.h:typedef fpregset_t prfpregset_t; > /usr/src/sys/sys/ptrace.h:struct fpreg; > /usr/src/sys/sys/ptrace.h:int proc_read_fpregs(struct thread *_td, = struct fpreg *_fpreg); > /usr/src/sys/sys/ptrace.h:int proc_write_fpregs(struct thread *_td, = struct fpreg *_fpreg); >=20 > and: >=20 > /usr/src/sys/kern/sys_process.c: * Ptrace doesn't support fpregs at = all, and there are no security holes > /usr/src/sys/kern/sys_process.c: * or translations for fpregs, so we = can just copy them. > /usr/src/sys/kern/sys_process.c:proc_read_fpregs(struct thread *td, = struct fpreg *fpregs) > /usr/src/sys/kern/sys_process.c: PROC_ACTION(fill_fpregs(td, = fpregs)); > /usr/src/sys/kern/sys_process.c:proc_write_fpregs(struct thread *td, = struct fpreg *fpregs) > /usr/src/sys/kern/sys_process.c: PROC_ACTION(set_fpregs(td, = fpregs)); > /usr/src/sys/kern/sys_process.c: struct fpreg fpreg; > /usr/src/sys/kern/sys_process.c: error =3D = COPYIN(uap->addr, &r.fpreg, sizeof r.fpreg); > /usr/src/sys/kern/sys_process.c: error =3D = COPYOUT(&r.fpreg, uap->addr, sizeof r.fpreg); > /usr/src/sys/kern/sys_process.c: error =3D = PROC_WRITE(fpregs, td2, addr); > /usr/src/sys/kern/sys_process.c: error =3D = PROC_READ(fpregs, td2, addr); >=20 > and there is use of some of the above in: >=20 > /usr/src/sys/kern/sys_process.c: * proc_read_fpregs, proc_write_fpregs > /usr/src/sys/kern/sys_process.c:proc_read_fpregs(struct thread *td, = struct fpreg *fpregs) > /usr/src/sys/kern/sys_process.c: PROC_ACTION(fill_fpregs(td, = fpregs)); > /usr/src/sys/kern/sys_process.c:proc_write_fpregs(struct thread *td, = struct fpreg *fpregs) > /usr/src/sys/kern/sys_process.c: PROC_ACTION(set_fpregs(td, = fpregs)); Sorry: I did not intend to include the "fpregs32" material: > /usr/src/sys/kern/sys_process.c:proc_read_fpregs32(struct thread *td, = struct fpreg32 *fpregs32) > /usr/src/sys/kern/sys_process.c: PROC_ACTION(fill_fpregs32(td, = fpregs32)); > /usr/src/sys/kern/sys_process.c:proc_write_fpregs32(struct thread *td, = struct fpreg32 *fpregs32) > /usr/src/sys/kern/sys_process.c: PROC_ACTION(set_fpregs32(td, = fpregs32)); I have not looked into fpregs32 at all. As far as I saw looking at fpregs material fpregs32 seemed to be separate. My guess would be fpregs32 is for amd64, powerpc64, sparc64, mips and their supporting 32 bit processes as well as 64-bit on 64-bit processors. So far as I know FreeBSD does not have such support for 32-bit code in arm64/aarch64 contexts. > I may not have found everything relevant. >=20 > It appears that fp_state_t is unused in /usr/src/sys/ . >=20 >=20 > Note: I was looking at /usr/src/sys/ for. . . >=20 > # uname -paKU > FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT r314687M amd64 = amd64 1200023 1200023 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Mar 17 01:42: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 685D8D0F7CA for ; Fri, 17 Mar 2017 01:42:12 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (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 3043217D2 for ; Fri, 17 Mar 2017 01:42:12 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-ot0-x235.google.com with SMTP id i1so76456994ota.3 for ; Thu, 16 Mar 2017 18:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=trZnzw/OPUIro3t0pe1B2zws2EyPfJ8dfrE3VOrC4Cw=; b=cwUuNTsho41+AhI/CqE7aQCnGfZT+frKh9UrzcdYT1UxJlrQx5KJPs3eJch/5ZC86D 8m6N39DrCIXOebV2mg1J0sznhoLJQsp7toOzCJnCLvf9PN2SeJyMK6cMY9+ROtN/Wynm wHABbS4O3moDUy0V2fgvONRhWXA8lfZhUslGwkW39pJu7gk77WyoMBY4V92Ibim8OuiJ 7Kg16Npr8/x3uHmywL5m7vIQAUjH3+Fj4+ZRpxp/c4EBkd03tZKEs8G31oFZXQboZdws CCJqJjVvuhS2oChBgdxzKS8RVW0oKQyO2xUGjW8Gqp9NFbqeEk6So5n0TE6yaB3824ol UIsQ== 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=trZnzw/OPUIro3t0pe1B2zws2EyPfJ8dfrE3VOrC4Cw=; b=k43csQ4VXN68ymZjXIhG9/th+nsUdVB5416RNFQUiAyDXsZevv5Txbky0n64gQ9jQB d7oYkfTkS3lcWezoNPdgWDdDDzZToe+EIgip3FE8AKGHD/Esr1t81h1XNInbwm7Vnp2X PWGg5AOPmW9zhA3xo+qN1jCPupSypp4bo5Ar1dyM4qMuHaM6qXwUKpfT4iJFV8Xq0YuM 3jOCSvKorqLUFJA8kTZDP4TzlhpfWZWw8xGAxaeEelRX7PTc+XL9RrXx0rsQNFyjRBqz XVey6q4O1uBEn19jt9LOw8VAskJ13+D0fvQZP71CqHHqIlUfCkOiEIPIUERZXZRKA12B ZLIA== X-Gm-Message-State: AFeK/H0lU06SWiA3NA710H8I32Hf4aYEascnBZVHbcRSo0zt1FTehnMtvsDE9k98HZOIlYOLQ6cnZWMQxiDg7Q== X-Received: by 10.157.60.123 with SMTP id j56mr6678298ote.235.1489714931313; Thu, 16 Mar 2017 18:42:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.221.71 with HTTP; Thu, 16 Mar 2017 18:42:11 -0700 (PDT) In-Reply-To: References: From: Ganbold Tsagaankhuu Date: Fri, 17 Mar 2017 09:42:11 +0800 Message-ID: Subject: Re: Making INTRNG a requirement on armv6 To: Andrew Turner Cc: "freebsd-arm@freebsd.org" , John Wehle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 01:42:12 -0000 On Fri, Mar 17, 2017 at 1:08 AM, Andrew Turner wrote= : > Hello arm, > > I would like to make INTRNG a requirement on armv6. This is to help > with moving more armv6 kernel configurations into GENERIC. It also > helps when we want a child interrupt controller, e.g. a GPIO driver. > > Most of the current armv6 kernel configurations already use INTRNG, so > only a few places need to be updated. > > I=E2=80=99ve run a test build making it an error to not have INTRNG enabl= ed and > found the following armv6 configs fail: > > AML8726 > ARMADAXP > DIGI-CCWMX53 > EFIKA_MX > IMX53 > IMX53-QSB > VERSATILEPB > YYHD18 > > I'm interested in people who have this hardware to try enabling INTRNG > and testing. Note that this may require the interrupt controller driver > the SoC uses to be ported to INTRNG. > As for Amlogic ones, iirc, John did some tests on his devices with INTRNG in December last year. John, May we know the status now? thanks a lot, Ganbold > > Andrew > _______________________________________________ > 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 Mar 17 02:21: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 A112FD0F57C for ; Fri, 17 Mar 2017 02:21:31 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 802F81A29; Fri, 17 Mar 2017 02:21:31 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 2A5EFBE2; Thu, 16 Mar 2017 22:15:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: qemu-user regressions From: Paul Mather In-Reply-To: <206ac59c-9efc-522f-d7be-70a06a418b83@freebsd.org> Date: Thu, 16 Mar 2017 22:15:05 -0400 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1C732A7F-CAB9-4F11-8B8C-E986A507AAEB@gromit.dlib.vt.edu> References: <206ac59c-9efc-522f-d7be-70a06a418b83@freebsd.org> To: Sean Bruno X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 02:21:31 -0000 On Mar 15, 2017, at 11:11 AM, Sean Bruno wrote: > I'd like to generate a smallish list of packages that I can use as a > baseline regression list before I do merge updates to qemu proper. >=20 > If you have a handful of packages that you use day-to-day, can you = reply > to this list with them and I'll add them to my 'best effort' list of > things to try and not break. My main one is sysutils/py-salt, as I use Salt to configure my systems, = including FreeBSD/arm. Cheers, Paul. From owner-freebsd-arm@freebsd.org Fri Mar 17 02:48: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 D0361D0FB9A for ; Fri, 17 Mar 2017 02:48:51 +0000 (UTC) (envelope-from john@feith.com) Received: from feith1.FEITH.COM (feith1.FEITH.COM [192.251.93.1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D41716EE for ; Fri, 17 Mar 2017 02:48:51 +0000 (UTC) (envelope-from john@feith.com) Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.15.1+Sun/8.12.9) with ESMTP id v2H2iepi000049; Thu, 16 Mar 2017 22:44:40 -0400 (EDT) (envelope-from john@jwlab.FEITH.COM) Received: from jwlab.FEITH.COM (localhost [127.0.0.1]) by jwlab.FEITH.COM (8.15.1+Sun/8.15.1) with ESMTP id v2H2ieQq013801; Thu, 16 Mar 2017 22:44:40 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.15.1+Sun/8.15.1/Submit) id v2H2ibXc013800; Thu, 16 Mar 2017 22:44:37 -0400 (EDT) Date: Thu, 16 Mar 2017 22:44:37 -0400 (EDT) From: John Wehle Message-Id: <201703170244.v2H2ibXc013800@jwlab.FEITH.COM> To: ganbold@gmail.com Subject: Re: Making INTRNG a requirement on armv6 Cc: andrew@fubar.geek.nz, freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-DCC-x.dcc-servers-Metrics: feith1; whitelist X-Scanned-By: MIMEDefang 2.67 on 192.251.93.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 02:48:51 -0000 > As for Amlogic ones, iirc, John did some tests on his devices with INTRNG > in December last year. The primary issue is regarding the older interrupt controller used on the aml8726-m3 and also present on the aml8726-m6. I did the original porting work using the aml8726-m6 with the older interrupt controller which seemed to work fine ... there didn't seem to be any interrupts being lost. It was only towards the end of the porting work that I switched the aml8726-m6 (which happens to have both the older controller and a GIC) to using the GIC. Back in December 2016 the aml8726-m6 (and -m8b) passed a smoke test using INTRNG with the GIC. Disabling INTRNG caused the aml8726-m3 and the aml8726-m6 (configured for the older interrupt controller) to "lose" clock interrupts. I did at that time see about updating the older Amlogic interrupt code to use INTRNG which was a pretty straight forward effort, though even with the updated code the older interrupt controller still suffered from "lost" clock interrupts. Unfortunately my attentions (as is probably evident) have been elsewhere so the "lost" clock interrupts issue is unresolved. I can see about providing the INTRNG version of the older Amlogic interrupt driver it that helps, however I'm probably not finding time to debug the "lost" clock interrupts issue anytime soon. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From owner-freebsd-arm@freebsd.org Fri Mar 17 07:39: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 948CBD0E642 for ; Fri, 17 Mar 2017 07:39:38 +0000 (UTC) (envelope-from mailbox@iqelite.com) Received: from mail2.iqelite.com (mail2.iqelite.com [67.207.134.120]) (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 711EE1B46 for ; Fri, 17 Mar 2017 07:39:38 +0000 (UTC) (envelope-from mailbox@iqelite.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=iqelite.com; s=iqe; t=1489734318; bh=Z+qI2Lh71d1L99wNKuRnztuKGPqmtn2hce+Eqa9HQNU=; h=MIME-Version:Subject:From:To:Date:Message-ID:List-Unsubscribe; b=PDwgvbHxQ5osTVmdOrdIIzqtYSuiTMuHZfs/9fmt1KmdnC053Z8i/d/D4XlqxFFTA 07huEtaM7DGvK0b6KDxi1R1AMFkGpNSc5+iPoTpTZy//JGUkHQwoK6HdDDcX3eR3QJ VnnWdfJ+vZpPbVM73L+3rfMTy+i+onSBLxHd2ed8= MIME-Version: 1.0 Subject: freebsd-arm, tienes un mensaje de giorgio.zoppi From: "giorgio.zoppi" To: freebsd-arm Date: Fri, 17 Mar 2017 07:04:53 -0000 Message-ID: <20170317070453.1462.91784@mail2.iqelite.com> X-Elite-Code: hg=hZkcSD8ECA; BounceHandler: http://a.iqelite.com/mail/bounce/ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 07:39:38 -0000 Hola freebsd-arm, Tienes un mensaje de giorgio.zoppi en IQ Elite para ti. = Haz click aqui a.iqelite.com/j/Yf9HA8/md1/?hg=3DhZkcSD8ECA para leer el men= saje = El equipo de IQ Elite --------------------------------------------------------------------------- Este mensaje estaba destinado a freebsd-arm@freebsd.org. Si no deseas segui= r recibiendo mensajes de IQ Elite, haz click en este enlace: a.iqelite.com/= common/unsubscribe/?code=3D888dd5bb&email=3Dfreebsd-arm@freebsd.org.&hg=3Dh= ZkcSD8ECA IQ Elite es un servicio con oficina principal en: C/ Gran de Gr= =C3=A0cia 15, 2=C2=BA 1=C2=AA, 08012 Barcelona, Espa=C3=B1a. ---------------------------------------------------------------------------= =20 From owner-freebsd-arm@freebsd.org Fri Mar 17 15:58: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 B029CD10F66 for ; Fri, 17 Mar 2017 15:58:13 +0000 (UTC) (envelope-from wlosh@bsdimp.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 7F4D11377 for ; Fri, 17 Mar 2017 15:58:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id g138so31251767itb.0 for ; Fri, 17 Mar 2017 08:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ahLuQ8yw3vd4EYb2KWEEjfezydShPiGdC06kfeq9nXM=; b=TMx+fym1APPWj3UyfWkFJJxbGfyLkdvoAr0N4wt2MVH33BRBtb4uzEGxJ33llHwiQ/ imOFxWqFs4WKqrliNAPdarZY6i9JOjTitw4cy5/OVWwjw4JaOrrJa+Ok14JxXy2EJ6bf F3aNUUU98+/ngQHjfxD3ZBz6bYmX3MGEsxX/KLBv9XMqnhCCEjNPQPSLs3Veyj8ZFI9n 2SqMUJuYshL3vBFVIatdvKlTOH/Z39kan/tjnLZjkJU+DDRj+ZCOihcNFI1aX/m+u2oi NXXZ9JPCJKuN5k4U+Qzp5TkU4ZA5dL42tiC6TgFp8vMKF3PjsnTVmJ9lCqttipz8scXx G6TQ== 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=ahLuQ8yw3vd4EYb2KWEEjfezydShPiGdC06kfeq9nXM=; b=YiWpJuM9igl8VgdM4lB8xLYG2l7OwNneIySu4xG7NVRYwQHdoFZJYxEFzdU1Oo9K2k /CV9nBqifhPn1dsV129xVxDmKK36ntWL5lbMFCrBJZHTROKSpEiiBqlhY5ax4MBynZ/I JHafwBMeXeFdcol8LfBokinny2bCTX/G5JvSUy5MokQxr3JQWmxlQUulUzdpmbfee8ZW lBZt31UyJGrbtAmUqBvU7H2pCnzF4PdlCS67kCAnQ7WzTK6jI0JxOH3TIKgdwLDtwyKi YmCjOmZFiblCANtvPH50ebYknw5ncyLhPGBBBMINy9vgeVMmt/QqyYtDKkBOZSSQ8TsV T+Kg== X-Gm-Message-State: AFeK/H0f8gA2b7mQmRoIUz6A3d3EZrsRE/EL8VJtZqvezzcQ9lPfvGdiJPZhY0Aq8YARH53NukAXY+CLIzbYHQ== X-Received: by 10.36.34.212 with SMTP id o203mr3230471ito.103.1489766274839; Fri, 17 Mar 2017 08:57:54 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Fri, 17 Mar 2017 08:57:54 -0700 (PDT) X-Originating-IP: [69.53.246.16] In-Reply-To: <201703170244.v2H2ibXc013800@jwlab.FEITH.COM> References: <201703170244.v2H2ibXc013800@jwlab.FEITH.COM> From: Warner Losh Date: Fri, 17 Mar 2017 09:57:54 -0600 X-Google-Sender-Auth: DxsQXTdkTG_d-mAEeUp4GlOZkKM Message-ID: Subject: Re: Making INTRNG a requirement on armv6 To: John Wehle Cc: Ganbold Tsagaankhuu , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 15:58:13 -0000 On Thu, Mar 16, 2017 at 8:44 PM, John Wehle wrote: >> As for Amlogic ones, iirc, John did some tests on his devices with INTRNG >> in December last year. > > The primary issue is regarding the older interrupt controller used on > the aml8726-m3 and also present on the aml8726-m6. I did the original > porting work using the aml8726-m6 with the older interrupt controller > which seemed to work fine ... there didn't seem to be any interrupts > being lost. It was only towards the end of the porting work that I > switched the aml8726-m6 (which happens to have both the older controller > and a GIC) to using the GIC. > > Back in December 2016 the aml8726-m6 (and -m8b) passed a smoke test using > INTRNG with the GIC. Disabling INTRNG caused the aml8726-m3 and the > aml8726-m6 (configured for the older interrupt controller) to "lose" > clock interrupts. > > I did at that time see about updating the older Amlogic interrupt code > to use INTRNG which was a pretty straight forward effort, though even > with the updated code the older interrupt controller still suffered > from "lost" clock interrupts. Unfortunately my attentions (as is > probably evident) have been elsewhere so the "lost" clock interrupts > issue is unresolved. > > I can see about providing the INTRNG version of the older Amlogic > interrupt driver it that helps, however I'm probably not finding > time to debug the "lost" clock interrupts issue anytime soon. Almost working code that has an issue or two, especially if those are documented, is much better than having to dump the port because we want to require INTRNG... So yes, if it isn't a huge hassle, can you dig that up? Warner From owner-freebsd-arm@freebsd.org Fri Mar 17 21:54: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 2ECB5D1082F for ; Fri, 17 Mar 2017 21:54:18 +0000 (UTC) (envelope-from john@feith.com) Received: from feith1.FEITH.COM (feith1.FEITH.COM [192.251.93.1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D80F21065 for ; Fri, 17 Mar 2017 21:54:17 +0000 (UTC) (envelope-from john@feith.com) Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.15.1+Sun/8.12.9) with ESMTP id v2HLsA8E016168; Fri, 17 Mar 2017 17:54:10 -0400 (EDT) (envelope-from john@jwlab.FEITH.COM) Received: from jwlab.FEITH.COM (localhost [127.0.0.1]) by jwlab.FEITH.COM (8.15.1+Sun/8.15.1) with ESMTP id v2HLsA5d014540; Fri, 17 Mar 2017 17:54:10 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.15.1+Sun/8.15.1/Submit) id v2HLs9DV014539; Fri, 17 Mar 2017 17:54:09 -0400 (EDT) Date: Fri, 17 Mar 2017 17:54:09 -0400 (EDT) From: John Wehle Message-Id: <201703172154.v2HLs9DV014539@jwlab.FEITH.COM> To: wlosh@bsdimp.com Subject: Re: Making INTRNG a requirement on armv6 Cc: ganbold@gmail.com, freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-DCC-sonic.net-Metrics: feith1; whitelist X-Scanned-By: MIMEDefang 2.67 on 192.251.93.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 21:54:18 -0000 > Almost working code that has an issue or two, especially if those are > documented, is much better than having to dump the port because we > want to require INTRNG... So yes, if it isn't a huge hassle, can you > dig that up? Yep ... not a problem. It'll probably be towards the end of next week by the time I dust it off and build it with the current tree. -- John From owner-freebsd-arm@freebsd.org Sat Mar 18 05:21: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 397A6D11FCE for ; Sat, 18 Mar 2017 05:21:32 +0000 (UTC) (envelope-from bunkertor@tiscali.it) Received: from zcsh.mail.ru (unknown [IPv6:2001:e00:25:223f:a6dc:beff:fea8:47d9]) by mx1.freebsd.org (Postfix) with ESMTP id E721EA8 for ; Sat, 18 Mar 2017 05:21:22 +0000 (UTC) (envelope-from bunkertor@tiscali.it) From: "bunkertor" To: "freebsd-arm" , "owner-mailmanbunkertor" Subject: =?utf-8?B?bmVlZCB5b3VyIGhlbHA=?= Date: Sat, 18 Mar 2017 08:20:41 +0300 Message-ID: <1814937827.20170318082041@tiscali.it> Content-Language: en-gb MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 05:21:32 -0000 SGV5IGZyaWVuZCwgDQoNCkkndmUganVzdCBmaW5pc2hlZCB3cml0aW5nIGFuIGFydGljbGUgYW5k IEkgd2FudGVkICB0byBhc2sgIHlvdSB0byB0YWtlIGEgbG9vayAgYXQgaXQgYW5kIHRlbGwgbWUg eW91ciBvcGluaW9uIGFib3V0IGl0LCBwbGVhc2UgcmVhZCB0aGUgd2hvbGUgIGFydGljbGUgaGVy ZSAgaHR0cDovL3ByaWNlLmFuZHJld3N0YXR6LmNvbS8xODE5DQoNCg0KUnVzaGluZywgYnVua2Vy dG9yDQoNCg== From owner-freebsd-arm@freebsd.org Sat Mar 18 13:26: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 16B55D12C80 for ; Sat, 18 Mar 2017 13:26:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 BF5A51792 for ; Sat, 18 Mar 2017 13:26:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28461 invoked from network); 18 Mar 2017 13:26:50 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 18 Mar 2017 13:26:50 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sat, 18 Mar 2017 09:26:50 -0400 (EDT) Received: (qmail 28762 invoked from network); 18 Mar 2017 13:26:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Mar 2017 13:26:49 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 274FEEC805D; Sat, 18 Mar 2017 06:26:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <1019DBB4-5A92-41FE-90B5-63F3F658CF3D@dsl-only.net> Date: Sat, 18 Mar 2017 06:26:48 -0700 Cc: freebsd-arm , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <826D525A-BDAF-4352-AD9F-A238B797BFAF@dsl-only.net> References: <201703151315.v2FDFWOr028842@sdf.org> <345EE889-A429-4C13-9B08-B762DA3F4D71@dsl-only.net> <201703160607.v2G67Vwe023153@sdf.org> <1019DBB4-5A92-41FE-90B5-63F3F658CF3D@dsl-only.net> To: Scott Bennett X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 13:26:58 -0000 [Summary: I've now tested on a rpi3 in addition to a pine64+ 2GB. Both contexts show the problem.] On 2017-Mar-16, at 2:07 AM, Mark Millard wrote: > On 2017-Mar-15, at 11:07 PM, Scott Bennett wrote: >=20 >> Mark Millard wrote: >>=20 >>> [Something strange happened to the automatic CC: fill-in for my = original >>> reply. Also I should have mentioned that for my test program if a >>> variant is made that does not fork the swapping works fine.] >>>=20 >>> On 2017-Mar-15, at 9:37 AM, Mark Millard = wrote: >>>=20 >>>> On 2017-Mar-15, at 6:15 AM, Scott Bennett = wrote: >>>>=20 >>>>> On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard >>>>> wrote: >>>>>> On 2017-Mar-14, at 4:44 PM, Bernd Walter = wrote: >>>>>>=20 >>>>>>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: >>>>>>>> [test_check() between the fork and the wait/sleep prevents the >>>>>>>> failure from occurring. Even a small access to the memory at >>>>>>>> that stage prevents the failure. Details follow.] >>>>>>>=20 >>>>>>> Maybe a stupid question, since you might have written it = somewhere. >>>>>>> What medium do you swap to? >>>>>>> I've seen broken firmware on microSD cards doing silent data >>>>>>> corruption for some access patterns. >>>>>>=20 >>>>>> The root filesystem is on a USB SSD on a powered hub. >>>>>>=20 >>>>>> Only the kernel is from the microSD card. >>>>>>=20 >>>>>> I have several examples of the USB SSD model and have >>>>>> never observed such problems in any other context. >>>>>>=20 >>>>>> [remainder of irrelevant material deleted --SB] >>>>>=20 >>>>> You gave a very long-winded non-answer to Bernd's question, so = I'll >>>>> repeat it here. What medium do you swap to? >>>>=20 >>>> My wording of: >>>>=20 >>>> The root filesystem is on a USB SSD on a powered hub. >>>>=20 >>>> was definitely poor. It should have explicitly mentioned the >>>> swap partition too: >>>>=20 >>>> The root filesystem and swap partition are both on the same >>>> USB SSD on a powered hub. >>>>=20 >>>> More detail from dmesg -a for usb: >>>>=20 >>>> usbus0: 12Mbps Full Speed USB v1.0 >>>> usbus1: 480Mbps High Speed USB v2.0 >>>> usbus2: 12Mbps Full Speed USB v1.0 >>>> usbus3: 480Mbps High Speed USB v2.0 >>>> ugen0.1: at usbus0 >>>> uhub0: on = usbus0 >>>> ugen1.1: at usbus1 >>>> uhub1: = on usbus1 >>>> ugen2.1: at usbus2 >>>> uhub2: on = usbus2 >>>> ugen3.1: at usbus3 >>>> uhub3: = on usbus3 >>>> . . . >>>> uhub0: 1 port with 1 removable, self powered >>>> uhub2: 1 port with 1 removable, self powered >>>> uhub1: 1 port with 1 removable, self powered >>>> uhub3: 1 port with 1 removable, self powered >>>> ugen3.2: at usbus3 >>>> uhub4 on uhub3 >>>> uhub4: = on usbus3 >>>> uhub4: MTT enabled >>>> uhub4: 4 ports with 4 removable, self powered >>>> ugen3.3: at usbus3 >>>> umass0 on uhub4 >>>> umass0: on = usbus3 >>>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>>> umass0:0:0: Attached to scbus0 >>>> . . . >>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>>> da0: Fixed Direct Access SPC-4 SCSI device >>>> da0: Serial Number >>>> da0: 40.000MB/s transfers >>>>=20 >>>> (Edited a bit because there is other material interlaced, even >>>> internal to some lines. Also: I removed the serial number of the >>>> specific example device.) >>=20 >> Thank you. That presents a much clearer picture. >>>>=20 >>>>> I will further note that any kind of USB device cannot = automatically >>>>> be trusted to behave properly. USB devices are notorious, for = example, >>>>>=20 >>>>> [reasons why deleted --SB] >>>>>=20 >>>>> You should identify where you page/swap to and then try = substituting >>>>> a different device for that function as a test to eliminate the = possibility >>>>> of a bad storage device/controller. If the problem still occurs, = that >>>>> means there still remains the possibility that another controller = or its >>>>> firmware is defective instead. It could be a kernel bug, it is = true, but >>>>> making sure there is no hardware or firmware error occurring is = important, >>>>> and as I say, USB devices should always be considered suspect = unless and >>>>> until proven innocent. >>>>=20 >>>> [FYI: This is a ufs context, not a zfs one.] >>=20 >> Right. It's only a Pi, after all. :-) >=20 > It is a Pine64+ 2GB, not an rpi3. >=20 >>>>=20 >>>> I'm aware of such things. There is no evidence that has resulted = in >>>> suggesting the USB devices that I can replace are a problem. = Otherwise >>>> I'd not be going down this path. I only have access to the one = arm64 >>>> device (a Pine64+ 2GB) so I've no ability to substitution-test what >>>> is on that board. >>=20 >> There isn't even one open port on that hub that you could plug a >> flash drive into temporarily to be the paging device? >=20 > Why do you think that I've never tried alternative devices? It > is just that the result was no evidence that my usually-in-use > SSD is having a special/local problem: the behavior continues > across all such contexts when the Pine64+ 2GB is involved. (Again > I have not had access to an alternate to the one arm64 board. > That limits my substitution testing possibilities.) >=20 > Why would you expect a Flash drive to be better than another SSD > for such testing? (The SSD that I usually use even happens to be > a USB 3.0 SSD, capable of USB 3.0 speeds in USB 3.0 contexts. So > is the hub that I usually use for that matter.) FYI: I now have access to a rpi3 in addition to a pine64+ 2GB. I've tested on the rpi3 using a different USB hub and a different SSD: no hardware device in common with the recent Pine64+ 2GB tests (other than console cabling and what handles the serial console). The fork-then-swap-out-then-swap-in failure happens in the rpi3 context as well. Because the rpi3 has only 1 GiByte of RAM the stress commands that I used were more like: stress -m 1 --vm-bytes 1000M to get zero RES(ident memory) for the two processes from my test program after it forks while they are waiting/sleeping. >> You could then >> try your tests before returning to the normal configuration. If = there >> isn't an open port, then how about plugging a second hub into one of >> the first hub's ports and moving the displaced device to the second >> hub? A flash drive could then be plugged in. That kind of = configuration >> is obviously a bad idea for the long run, but just to try your tests = it >> ought to work well enough. >=20 > I have access to more SSDs that I can use than I do to Flash drives. I > see no reason to specifically use a Flash drive. >=20 >> (BTW, if a USB storage device containing a >> paging area drops off=3Dline even momentarily and the system needs to = use >> it, that is the beginning of the end, even though it may take up to a = few >> minutes for everything to lock up. >=20 > The system does not lock up, even days or weeks later, with having = done > dozens of experiments that show memory corruption failures over those > days. The only processes showing memory corruption so far are those > that were the parent or child for a fork that were later swapped out > to have zero RES(ident memory) and then even later swapped back in. >=20 > The context has no such issues. You are inventing problems that do > not exist in my context. That is why none of my list submittals > mention such problems: they did not occur. >=20 >> You probably won't be able to do an >> orderly shutdown, but will instead have to crash it with the power = switch. >> In the case of something like a Pi, this is an unpleasant fact of = life, >> to be sure.) >=20 > Such things did not occur and has nothing to do with my context so = far. >=20 >> I think I buy your arguments, given the evidence you've collected >> thus far, including what you've added below. I just like to = eliminate >> possibilities that are much simpler to deal with before facing = nastinesses >> like bugs in the VM subsystem. :-) >=20 > When I started this I found no evidence of device-specific problems. > My investigation activity goes back to long before my list submittals. >=20 > And I repeat: Other people have reported the symptoms that started > this investigation. They did so before I ever started my activities. > They were using none of the specific devices that I have access to. > Likely the types of devices were frequently even different, such as > a rpi3 instead of a Pine64+ 2GB or a different USB drive. I was able > to get the symptoms that they reported. >=20 >>>> It would be neat if some folks used my code to test other arm64 >>>> contexts and reported the results. I'd be very interested. >>>> (This is easier to do on devices that do not have massive >>>> amounts of RAM, which may limit the range of devices or >>>> device configurations that are reasonable to test.) >>>>=20 >>>> There is that other people using other devices have reported >>>> the behavior that started this investigation. I can produce the >>>> behavior that they reported, although I've not seen anyone else >>>> listing specific steps that lead to the problem or ways to tell >>>> if the symptom is going to happen before it actually does. Nor >>>> have I seen any other core dump analysis. (I have bugzilla >>>> submittals 217138 and 217239 tied to symptoms others have >>>> reported as well as this test program material.) >>>>=20 >>>> Also, considering that for my test program I can control which = pages >>>> get the zeroed-problem by read-accessing even one byte of any 4K >>>> Byte page that I want to make work normally, doing so in the child >>>> process of the fork, between the fork and the sleep/swap-out, it = does >>>> not suggest USB-device-specific behavior. The read-access is = changing >>>> the status of the page in some way as far as I can tell. >>>>=20 >>>> (Such read-accesses in the parent process make no difference to the >>>> behavior.) >>>=20 >>> I should have noted another comparison/contrast between >>> having memory corruption and not in my context: >>>=20 >>> I've tried variants of my test program that do not fork but >>> just sleep for 60s to allow me to force the swap-out. I >>> did this before adding fork and before using >>> parital_test_check, for example. I gradually added things >>> apparently involved in the reports others had made >>> until I found a combination that produced a memory >>> corruption test failure. >>>=20 >>> These tests without fork involved find no problems with >>> the memory content after the swap-in. >>>=20 >>> For my test program it appears that fork-before-swap-out >>> or the like is essential to having the problem occur. >>>=20 >> A comment about terminology seems in order here. It bothers >> me considerably to see you writing "swap out" or "swapping" where >> it seems like you mean to write "page out" or "paging". A BSD >> system whose swapping mechanism gets activated has already waded >> very deeply into the quicksand and frequently cannot be gotten out >> in a reasonable amount of time even with manual assistance. It is >> often quicker to crash it, reboot, and wait for the fsck(8) cleanups >> to complete. Orderly shutdowns, even of the kind that results from >> a quick poke to the power button, typically get mired in the same >> mess that already has the system in knots. Also, BSD systems since >> 3.0BSD, unlike older AT&T (pre-SysVR2.3) systems, do not swap in, >> just out. A swapped out process, once the system determines that it >> has adequate resources again to attempt to run the process, will have >> the interrupted text page paged in and the rest will be paged in by >> the normal mechanism of page faults and page-in operations. I assume >> you must already know all this, which is a large part of why it = grates >> on me that you appear to be using the wrong terms. >=20 > You apparently did not read any of the material about how the test > is done or are unfamiliar with what "stress -m 1 --vm-bytes 1800M" > does when there is only 2GB of RAM. I am deliberately inducing > swapping in other processes, including the 2 from my test program > (after the fork), not just paging. (stress is a port, not part of > the base system.) >=20 > When I say swap-out and swap-in I mean it. >=20 > =46rom the source code of my test program: >=20 > sleep(60); >=20 > // During this manually force this process to > // swap out. I use something like: >=20 > // stress -m 1 --vm-bytes 1800M >=20 > // in another shell and ^C'ing it after top > // shows the swapped status desired. 1800M > // just happened to work on the Pine64+ 2GB > // that I was using. I watch with top -PCwaopid . >=20 > That type of stress run uses about 1.8 GiBytes after a bit, > which is enough to cause the swapping of other processes, > including the two that I am testing (post-fork). (Some RAM > is in use already before the stress run, which explains not > needing 2 GiBytes to be in use by stress.) >=20 > Look at a "top -PCwaopid" display: there are columns for > RES(ident memory) and SWAP. I cause my 2 test processes to > show zero RES and everything under SWAP, starting sometime > during the 60s sleep/wait. >=20 > Why would I cause swapping? Because buildworld causes such > swap-outs at times when there is only 2GBytes of RAM, > including processes that forked earlier, and as a result > the corrupted memory problems show up later in some processes > that were swapped out at the time. The build eventually > stops for process failures tied to the corruptions of memory > in the failing processes. (At least that is what my testing > strongly suggests.) >=20 > But that is a very complicated context to use for analysis or > testing of the problem. My test program is vastly simpler > and easier/quicker to set up and test when used with stress > as well. Such was the kind of thing I was trying to find. >=20 > I want the Pine64+ 2GB to work well enough to be able to have > buildworld (-j 4) complete correctly without having to restart > the build --even when everything has to be rebuilt. So I'm > trying to find and provide enough evidence to help someone fix > the problems that are observed to block such buildworld > activity. >=20 > Again: others have reported such arm64 problems on the lists > before I ever got into this activity. The evidence is that > the issues are not a local property of my environment. >=20 > Swapping is supposed to work. I can do buildworld (-j 4) > on armv6 (really -mcpu=3Dcortex-a7 so armv7-a) and the > swapping it causes works fine. This is true for both a > bpim3 (2 GiBytes of RAM) and a rpi2 (1 GiByte of RAM > so even more swapping). On a powerpc64 with 16 GiBytes > I've built things that caused 26 GiBytes of swap to be > in use some of the time (during 4 ld's running in > parallel), with lots of processes having zero for > RES(ident memory) and all their space listed under SWAP > in a "top -PCwaopid" display. This too has no problems > with swapping of previously forked processes (or of any > other processes). >=20 > For the likes of a Pine64+ 2GB to be "self hosted"=20 > for source-code based updates, swapping of previously > forked processes must work and currently such > swapping is unreliable. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Mar 18 14:44: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 63C21D12023 for ; Sat, 18 Mar 2017 14:44:39 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 019DE1A5A for ; Sat, 18 Mar 2017 14:44:38 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489848274; l=841; s=domk; d=obsigna.com; h=Mime-Version:To:Date:Subject:Content-Transfer-Encoding:Content-Type: From; bh=ZKgU1COyl/5BBwJTtgRzS2cvTmxXlwtfIajlsdsWc40=; b=RR2410gNpqFWOcjGitcxyTz0gZR/jjWKkqxMy7l/xNjD4hbV047pC1AgUIBq1NyOXY ADJkAZWhpLfkkTKQJ5jPjtDBwoNlQzZcrL1m786TvzTSdIN2fGcfuELXF+L0jweynD84 2qVZnzDY72NS//U0/xgTzTD27QyCifFxgVqk0= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0n99Hk6LY= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b8ae.virtua.com.br [187.2.184.174]) by smtp.strato.de (RZmta 40.1 DYNA|AUTH) with ESMTPSA id K03c82t2IEiXA1h (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sat, 18 Mar 2017 15:44:33 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id EF10B7506DAD for ; Sat, 18 Mar 2017 11:44:27 -0300 (BRT) From: "Dr. Rolf Jansen" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Identifying counterfeit microSD cards on a Beaglebone Black Message-Id: Date: Sat, 18 Mar 2017 11:44:28 -0300 To: freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 14:44:39 -0000 I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s write speed for = use with my Beaglebone Black.=20 The internal flash offers practical write speeds in the range of 2 to 3 = MB/s when copying data to it from a NFSv4 volume depending on the size = of the files being copied. Executing the same copy operation with said = microSDHC card as the target I see only 0.1 to 0.2 MB/s (less than = 1/10). I suspect now that I got a counterfeited card. Before I dump it, I would = like to run a definitive non-destructive test, preferably on the = Beaglebone Black, and I would like to ask you for suggestions. Also, it would be nice to see some speed values as a reference for = microSDHC card write speeds on: FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 Many thanks in advance for any help. Best regards Rolf= From owner-freebsd-arm@freebsd.org Sat Mar 18 15: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 5050DD12B68 for ; Sat, 18 Mar 2017 15:30:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 229B71161 for ; Sat, 18 Mar 2017 15:30:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id m27so50336159iti.0 for ; Sat, 18 Mar 2017 08:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=oa/o5e+vZ3ePtwCTDpiPltaLFyVMisjuSmewgRbmOJs=; b=bnDfXLMTRsAhSyhABxdy32GrpgcMi7nhp0l6f84d9fDTFkhsYvVT5kXZkNkmfd8FuA xb0Hce5mQPw87cCGxvhDYSNYP9Xg6cfz+KWxnjSX2kBe4wZ2v1o44Sda8vwKYdHy/b4m qiWAlA3lGlsibmCJm28LHsXYyaPLU5PqKN80W3gMd0uk0GMy4JiNrokwk4Vqqkc8Ni2C lpScjA0Xpz/8kGL2MDn6LV5y9HsCdlWBP4nRNdQ2N1PtLTTdKHhNcaBM5vIBG5pXWOz2 b0LLjznWQ/9wm8TuWPqmGudtdqeYb0GzcUDIM65cwee6qjsqwjMk39SLSuaesFfr1CIK xIqA== 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:content-transfer-encoding; bh=oa/o5e+vZ3ePtwCTDpiPltaLFyVMisjuSmewgRbmOJs=; b=kJDwo5WWAnnq26QhmhAOybIND4DLq/bXtOIf4sINOmqCmBxNaRdeyu1tddsT1TMZes 8QLizQmsPspHJykczsH0iI93NnNgNNHwdGs3+/6qA62ox9v+7c4qojdrRmxQkLxh12zm F6U8Az96IjhG2ktTTBHu5+OkGAlTFUdmo1phIpy6k1iqV73UL8p6ddu9kbQUF+zVHeS/ EGOaBzLunU8+EnbCWNqgSnwyM19Fd2r0XcAV0mAy9sVmz41VP8WRY1QtM2ZbDXE8/Gsx XUrk+0OGOkE/aZeEEhRwPlHEilfkpOP4vZGoJ++hRjRGGYzpb3o3I8OQRsRAyDm728Wi m9eA== X-Gm-Message-State: AFeK/H2UAjEgfyvCBAEkqzfN3aCtpIFm1JwasFk5kPNCK+wIiXHYy2luDYwv2rsWFaYJCOTQydHiTM+ihpmddA== X-Received: by 10.107.134.94 with SMTP id i91mr19837129iod.0.1489851016270; Sat, 18 Mar 2017 08:30:16 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Sat, 18 Mar 2017 08:30:15 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::108b] In-Reply-To: References: From: Warner Losh Date: Sat, 18 Mar 2017 09:30:15 -0600 X-Google-Sender-Auth: -4dJHlyoQbZ2QGIMXXGJ8c7i4ys Message-ID: Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black To: "Dr. Rolf Jansen" Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 15:30:17 -0000 On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen wrote: > I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s write speed for u= se with my Beaglebone Black. > > The internal flash offers practical write speeds in the range of 2 to 3 M= B/s when copying data to it from a NFSv4 volume depending on the size of th= e files being copied. Executing the same copy operation with said microSDHC= card as the target I see only 0.1 to 0.2 MB/s (less than 1/10). > > I suspect now that I got a counterfeited card. Before I dump it, I would = like to run a definitive non-destructive test, preferably on the Beaglebone= Black, and I would like to ask you for suggestions. > > Also, it would be nice to see some speed values as a reference for microS= DHC card write speeds on: > > FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 > > Many thanks in advance for any help. Copy a huge file from /dev/zero. Smaller files in the filesystem generate a lot of overhead and 'wait points' that slow down overall performance. Or better yet, dd to the raw device. /dev/random should generate data faster than the card can handle. Depends on what you mean by 'non-destructive' And all NAND sucks. It's a pig with lipstick on it. So you won't get even performance if the FTL in the SD card sucks. Garbage collection, internal house keeping, etc all can steal performance from the user application. These cards are generally designed to take a burst of writes when the camera or video is taken, then have it read back later. A mixed workload was never optimized for on most of these cards, so it can also significantly degrade performance even at low percentage mixtures. So all those things could be going on w/o it being a counterfeit. :(. Of course, it could have all those things going on and also be a counterfeit. Hard to say for sure unless the performance is wildly different. But 4MB/s write performance is pretty pathetic for a card of that size, so it's on the low end, which suffers most from uneven performance and "down hill with the wind" spec numbers. Warner From owner-freebsd-arm@freebsd.org Sat Mar 18 18: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 E91A9D12555 for ; Sat, 18 Mar 2017 18:03:47 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8743E104B for ; Sat, 18 Mar 2017 18:03:47 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489860224; l=3053; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=dnN0PVwJ/knyVQoyvkMavm7VKbmJbAw4fG55K4UcIjU=; b=DlTWh95D8fZUmLpojHEiecMf+WrG2REBKpB3pcuQ9Xec5LJ08aGh8RHdy0bF/eUl6b 4fRfiljUaIeoPBxr4nHLEGZD4ibI4JIj89Ho7uZ5/j4Solz28FtvFc51TJ/nDVvCfBoN /i0K/HIx4Es8FLvBcY/eRrf20zH7Wy4dq7ZlE= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0n99Hk6LY= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b8ae.virtua.com.br [187.2.184.174]) by smtp.strato.de (RZmta 40.1 DYNA|AUTH) with ESMTPSA id j04813t2II3hBzD (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sat, 18 Mar 2017 19:03:43 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 457587506DAD for ; Sat, 18 Mar 2017 15:03:40 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black From: "Dr. Rolf Jansen" In-Reply-To: Date: Sat, 18 Mar 2017 15:03:38 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 18:03:48 -0000 Am 18.03.2017 um 12:30 schrieb Warner Losh : > On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen = wrote: >> I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s write speed = for use with my Beaglebone Black. >>=20 >> The internal flash offers practical write speeds in the range of 2 to = 3 MB/s when copying data to it from a NFSv4 volume depending on the size = of the files being copied. Executing the same copy operation with said = microSDHC card as the target I see only 0.1 to 0.2 MB/s (less than = 1/10). >>=20 >> I suspect now that I got a counterfeited card. Before I dump it, I = would like to run a definitive non-destructive test, preferably on the = Beaglebone Black, and I would like to ask you for suggestions. >>=20 >> Also, it would be nice to see some speed values as a reference for = microSDHC card write speeds on: >>=20 >> FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 >>=20 >> Many thanks in advance for any help. >=20 > Copy a huge file from /dev/zero. Smaller files in the filesystem > generate a lot of overhead and 'wait points' that slow down overall > performance. >=20 > Or better yet, dd to the raw device. /dev/random should generate data > faster than the card can handle. Depends on what you mean by > 'non-destructive' >=20 > And all NAND sucks. It's a pig with lipstick on it. So you won't get > even performance if the FTL in the SD card sucks. Garbage collection, > internal house keeping, etc all can steal performance from the user > application. These cards are generally designed to take a burst of > writes when the camera or video is taken, then have it read back > later. A mixed workload was never optimized for on most of these > cards, so it can also significantly degrade performance even at low > percentage mixtures. >=20 > So all those things could be going on w/o it being a counterfeit. :(. > Of course, it could have all those things going on and also be a > counterfeit. Hard to say for sure unless the performance is wildly > different. But 4MB/s write performance is pretty pathetic for a card > of that size, so it's on the low end, which suffers most from uneven > performance and "down hill with the wind" spec numbers. Warner, thank you very much for taking your time responding. It is a Class 4 card, i.e. guaranteed minimum write speed should be 4 = MB/s, and I know the difference between advertised and practical speed, = I would have expected at lest 50 % of the advertised speed, i.e. = something in the range that can be achieved with the internal flash of = the BBB. I would even be happy if it would come close to 1 MB/s. But 0.1 = MB/s that is a quit huge difference -- 40 times less than the advertised = speed. You said, that 4 MB/s is "pretty pathetic". Therefore let me ask a = different question. What is the best write speed that can be achieved = with what model of a microSD card on a Beaglebone Black running FreeBSD = 12-Current? Many thanks and best regards Rolf From owner-freebsd-arm@freebsd.org Sat Mar 18 19:07: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 A5BAED12CF0 for ; Sat, 18 Mar 2017 19:07:27 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 8A62B1026 for ; Sat, 18 Mar 2017 19:07:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 1e9fef33-0c0e-11e7-bfb5-0d159cd3c324 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.ore.mailhop.org (Halon) with ESMTPSA id 1e9fef33-0c0e-11e7-bfb5-0d159cd3c324; Sat, 18 Mar 2017 19:07:24 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v2IJ7NSF012107; Sat, 18 Mar 2017 13:07:23 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1489864043.40576.219.camel@freebsd.org> Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black From: Ian Lepore To: "Dr. Rolf Jansen" , freebsd-arm@freebsd.org Date: Sat, 18 Mar 2017 13:07:23 -0600 In-Reply-To: References: 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 19:07:27 -0000 On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote: > Am 18.03.2017 um 12:30 schrieb Warner Losh : > > > > On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen > > wrote: > > > > > > I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s write > > > speed for use with my Beaglebone Black. > > > > > > The internal flash offers practical write speeds in the range of > > > 2 to 3 MB/s when copying data to it from a NFSv4 volume depending > > > on the size of the files being copied. Executing the same copy > > > operation with said microSDHC card as the target I see only 0.1 > > > to 0.2 MB/s (less than 1/10). > > > > > > I suspect now that I got a counterfeited card. Before I dump it, > > > I would like to run a definitive non-destructive test, preferably > > > on the Beaglebone Black, and I would like to ask you for > > > suggestions. > > > > > > Also, it would be nice to see some speed values as a reference > > > for microSDHC card write speeds on: > > > > > >    FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 > > > > > > Many thanks in advance for any help. > > Copy a huge file from /dev/zero. Smaller files in the filesystem > > generate a lot of overhead and 'wait points' that slow down overall > > performance. > > > > Or better yet, dd to the raw device. /dev/random should generate > > data > > faster than the card can handle. Depends on what you mean by > > 'non-destructive' > > > > And all NAND sucks. It's a pig with lipstick on it. So you won't > > get > > even performance if the FTL in the SD card sucks. Garbage > > collection, > > internal house keeping, etc all can steal performance from the user > > application. These cards are generally designed to take a burst of > > writes when the camera or video is taken, then have it read back > > later. A mixed workload was never optimized for on most of these > > cards, so it can also significantly degrade performance even at low > > percentage mixtures. > > > > So all those things could be going on w/o it being a counterfeit. > > :(. > > Of course, it could have all those things going on and also be a > > counterfeit. Hard to say for sure unless the performance is wildly > > different. But 4MB/s write performance is pretty pathetic for a > > card > > of that size, so it's on the low end, which suffers most from > > uneven > > performance and "down hill with the wind" spec numbers. > Warner, thank you very much for taking your time responding. > > It is a Class 4 card, i.e. guaranteed minimum write speed should be 4 > MB/s, and I know the difference between advertised and practical > speed, I would have expected at lest 50 % of the advertised speed, > i.e. something in the range that can be achieved with the internal > flash of the BBB. I would even be happy if it would come close to 1 > MB/s. But 0.1 MB/s that is a quit huge difference -- 40 times less > than the advertised speed. > > You said, that 4 MB/s is "pretty pathetic". Therefore let me ask a > different question. What is the best write speed that can be achieved > with what model of a microSD card on a Beaglebone Black running > FreeBSD 12-Current? > > Many thanks and best regards > > Rolf First we've got to keep in mind that BBB has a wimpy processor, and the sdhci driver for beaglebone uses PIO, not DMA.  If we try a naive test of writing 100mb of random data to the sdcard...  root@bb:~ # dd if=/dev/random of=/dev/mmcsd0s2 bs=1m count=100  100+0 records in  100+0 records out  104857600 bytes transferred in 14.559020 secs (7202243 bytes/sec) It comes in at 7mb/sec, but were we really measuring card performance?  root@bb:~ # dd if=/dev/random of=/dev/null bs=1m count=100  100+0 records in  100+0 records out  104857600 bytes transferred in 6.888693 secs (15221698 bytes/sec) So ~15mb/sec just generating and writing random numbers to /dev/null, that's not very good, in theory an sdcard can write faster than that. So let's take the random generation cpu cycles out of the picture by caching some random data...  root@bb:~ # dd if=/dev/random of=/tmp/rand bs=1m count=100  100+0 records in  100+0 records out  104857600 bytes transferred in 8.566184 secs (12240876 bytes/sec)  root@bb:~ # dd if=/tmp/rand of=/dev/null bs=1m  100+0 records in  100+0 records out  104857600 bytes transferred in 0.625300 secs (167691590 bytes/sec) That's more like it, now we're not measuring processor performance when we use dd.  Now let's see what a raw write to that same sdcard does using the cached random data...  root@bb:~ # dd if=/tmp/rand of=/dev/mmcsd0s2 bs=1m  100+0 records in  100+0 records out  104857600 bytes transferred in 7.777464 secs (13482236 bytes/sec) So that's about twice as fast as our first naive attempt to test writing 100mb of random data, and probably represents something pretty close to the actual BBB raw write speed under best-case conditions for an sdcard: large sequential writes. Now using that command to get actual numbers for some cards I have laying around:  Apacer   8gb class  10: 14226229 bytes/sec (industrial temp range)  Kingston 8gb class   4:  7008571 bytes/sec  Kingston 8gb class  10:  9715391 bytes/sec  Lexar    8gb class   6:  8821627 bytes/sec  Sandisk  2gb class n/a:  6163704 bytes/sec (predates speed classes)  Samsung 32gb class   6: 13482236 bytes/sec So the cards that perform best are the two I have which cost more than twice as much as any of the others.  Not surprising, I suppose. Remember all of these 'dd' tests are for an sdcard's best-case condition.  Real-world UFS accesses are anything but best-case.  The thing an sdcard is worst at is small writes (anything from single- sector to 16k is very small compared to the typical 4mb erase-block size on a modern sdcard).  Writing ufs metadata is lots and lots of small writes.  You can reduce the writes quite a bit by using softupdates without journaling. -- Ian