From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 04:04:44 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5D79CAAB; Sun, 1 Sep 2013 04:04:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 32B692419; Sun, 1 Sep 2013 04:04:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8144iwo014651; Sun, 1 Sep 2013 04:04:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8144iAK014650; Sun, 1 Sep 2013 04:04:44 GMT (envelope-from linimon) Date: Sun, 1 Sep 2013 04:04:44 GMT Message-Id: <201309010404.r8144iAK014650@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-arm@FreeBSD.org, mm@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: ports/179561: Compilation issue for www/lighttpd on raspberry pi X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 04:04:44 -0000 Old Synopsis: Compilation issue for lighttpd on raspberry pi New Synopsis: Compilation issue for www/lighttpd on raspberry pi Responsible-Changed-From-To: freebsd-arm->mm Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 1 04:02:55 UTC 2013 Responsible-Changed-Why: make this a ports PR and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=179561 From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 09:57:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4FFD18B1 for ; Sun, 1 Sep 2013 09:57:12 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 158CA2327 for ; Sun, 1 Sep 2013 09:57:12 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VG4P6-000Om8-Fa; Sun, 01 Sep 2013 10:57:10 +0100 Subject: Re: What's the recipe? Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FA3981F8-6D67-4245-ACAF-66E7F9FA3E0F"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <522229C0.5030504@m5p.com> Date: Sun, 1 Sep 2013 10:57:07 +0100 Message-Id: <98BEBCDF-D630-4D97-B9D2-F25323952142@grondar.org> References: <522229C0.5030504@m5p.com> To: George Mitchell X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 09:57:12 -0000 --Apple-Mail=_FA3981F8-6D67-4245-ACAF-66E7F9FA3E0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 31 Aug 2013, at 18:37, George Mitchell = wrote: > Have you built a working Raspberry Pi image recently? If so, for the > benefit of the rest of us, could you share a few secrets? I'm interested in this too! I got it right about a month ago (July = 2013), but the exercise is hard to repeat. > 1. What system did you do the build on? If it was an i386 or amd64, > what svn version was it built with? AMD64, SVN from src, not ports. > 2. What did you have in /etc/src.conf and /etc/make.conf, both for > building the build system itself and for building the RPi? /etc/make.conf had nothing that mattered, /etc/src.conf had a few "WITHOUT_x", (with x in {CVS, CTM, LPR and a few others of little consequence}). Importantly, things failed quickly if WITHOUT_GCC was in /etc/src.conf; u-boot didn't build on a box that had no legacy GCC. > 3. What svn version of /usr/src did you use in building the RPi image? CURRENT-of-the-day, and redoing "make xdev =85" seemed to help also. > 4. Did you use crochet? If so, what was the last commit in your git > log? Yes; can't remember what the latest commit was, but my usual practice is to get this sort of thing to "latest" before I build. > When I say "working," I'm hoping for the ability to run stably for a > number of days, running NFS and CUPS. I've been doing this since > January with a precompiled image I downloaded then which worked > wonderfully with one of my printers, but not the other one. Now > there's a patch that enables both printers to work, and I would love > to build a new image. So I've been thrashing around trying to find > the answers to the questions above without success. Thanks for any > help you can give! -- George I got it doing lightweight duty like leaving "top -S" running; I didn't have the time to do anything better, like I do now, and I'm battling; u-boot won't build right now. M --=20 Mark R V Murray --Apple-Mail=_FA3981F8-6D67-4245-ACAF-66E7F9FA3E0F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUiMPc958vKOKE6LNAQofGwP+OAtALqh6weamYf0lPm6cPOjjEbJLtdQp oSxm/qN0QJOxFPvf2dKrAvyq7W7tCcjYQan0RzEN4vgZ/ZYx0W8UtFnQskZciDl+ GBx46ALNJGt2l2/m4bah45/lnGcedSfWq52xEI2skabqWACKBRMxg3utmXq9fVjU B6kwkzLY5qk= =SJZU -----END PGP SIGNATURE----- --Apple-Mail=_FA3981F8-6D67-4245-ACAF-66E7F9FA3E0F-- From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 10:00:00 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BD6D4948 for ; Sun, 1 Sep 2013 10:00:00 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DC3F234E for ; Sun, 1 Sep 2013 10:00:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r81A00bG096393 for ; Sun, 1 Sep 2013 10:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r81A00VX096392; Sun, 1 Sep 2013 10:00:00 GMT (envelope-from gnats) Resent-Date: Sun, 1 Sep 2013 10:00:00 GMT Resent-Message-Id: <201309011000.r81A00VX096392@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Chie Taguchi Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9F1557FF for ; Sun, 1 Sep 2013 09:52:27 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A8C722EB for ; Sun, 1 Sep 2013 09:52:27 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r819qR3s016512 for ; Sun, 1 Sep 2013 09:52:27 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r819qR5G016511; Sun, 1 Sep 2013 09:52:27 GMT (envelope-from nobody) Message-Id: <201309010952.r819qR5G016511@oldred.freebsd.org> Date: Sun, 1 Sep 2013 09:52:27 GMT From: Chie Taguchi To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/181718: threads caused hung on ARM/RPI X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 10:00:00 -0000 >Number: 181718 >Category: arm >Synopsis: threads caused hung on ARM/RPI >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Sep 01 10:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Chie Taguchi >Release: FreeBSD 10.0-CURRENT >Organization: >Environment: FreeBSD RPI-1 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r255089: Sat Aug 31 17:13:40 JST 2013 user@arty:/usr/home/user/crochet-freebsd/work/obj/arm.armv6/usr/src.arm/sys/RPI-B-DBG arm >Description: i am trying to remove BROKEN on arm at devel/nspr. i had made two patches, attached, as reference OpenBSD and NetBSD. and build had succeeded. so i ran "make test" in devel/nspr. almost tests-suite were PASS. but, after running tests/cvar2 and tests/threads, RPI hunged without any core. in addition to this, there is another issue of tests/nbconn, but i will make a other PR about it. i done unit test of cvar2 and threads. these results were following: tests/cvar2: # ./cvar2 5 Thread tests Condvar simple test shared UU: 140.00 usec Condvar simple test shared UK: 110.00 usec Condvar simple test priv UU: 350.00 usec Condvar simple test priv UK: 350.00 usec Condvar simple test All: 370.00 usec Condvar timeout test: 770.00 usec 10 Thread tests Condvar simple test shared UU: 180.00 usec Condvar simple test shared UK: 170.00 usec Condvar simple test priv UU: 650.00 usec Condvar simple test priv UK: 640.00 usec Condvar simple test All: 760.00 usec Condvar timeout test: 950.00 usec 15 Thread tests Condvar simple test shared UU: 230.00 usec Condvar simple test shared UK: 240.00 usec Condvar simple test priv UU: 950.00 usec Condvar simple test priv UK: 940.00 usec Condvar simple test All: 1060.00 usec Condvar timeout test: 1120.00 usec 20 Thread tests Condvar simple test shared UU: 290.00 usec Condvar simple test shared UK: 280.00 usec Condvar simple test priv UU: 1270.00 usec Condvar simple test priv UK: 1250.00 usec Condvar simple test All: 1460.00 usec Condvar timeout test: 1320.00 usec PASS # ./cvar2 -v (debug mode) ..skipping... PrivateCondVarThread: thread 0x2085b320 notified exitcvar = 0x2080d2c0 cnt = 779 PrivateCondVarThread: thread 0x2085b320 notified exitcvar = 0x2080d2c0 cnt = 779 PrivateCondVarThread: thread 0x2085b320 notified exitcvar = 0x2080d2c0 cnt = 779 PrivateCondVarThread: thread 0x2085b320 notified exitcvar = 0x2080d2c0 cnt = 779 PrivateCondVarThread: thread 0x2085b320 notified exitcvar = 0x2080d2c0 cnt = 779 PrivateCondVarThread: thread 0x2085b320 notified exitcvar = 0x2080d2c0 cnt = 779 PrivateCondVarThread: thread 0x2085b320 notified exitcvar = 0x2080d2c0 cnt = 779 PrivateCondVarThread: thread 0x2085b320 notified exitcvar = 0x2080d2c0 cnt = 779 PrivateCondVarThread: thread 0x2085b320 notified exitcvar = 0x2080d2c0 cnt = 779 PrivateCondVarThread: thread 0x2085b320 notified exitcvar = 0x2080d2c0 cnt = 779 PrivateCondVarThread: thread 0x2085b320 notified exitcvar = 0x2080d2c0 cnt = 780 Condvar timeout test: 12840.00 usec PASS tests/threads: # ./threads -d (debug mode) ** Tests lots of thread creations. ** Create 10 native threads 50 times. ** Create 10 user threads 50 times. Create user/user threads: 3000.00 usec Create user/native threads: 2180.00 usec Create native/user threads: 2040.00 usec Create native/native threads: 2160.00 usec Create user/user threads: 2000.00 usec Create user/native threads: 1960.00 usec Create native/user threads: 2060.00 usec Create native/native threads: 2120.00 usec Create user/user threads: 2080.00 usec Create user/native threads: 2080.00 usec Create native/user threads: 2060.00 usec Create native/native threads: 1940.00 usec Create user/user threads: 2080.00 usec Create user/native threads: 1920.00 usec Create native/user threads: 2060.00 usec Create native/native threads: 2040.00 usec Create user/user threads: 2240.00 usec Create user/native threads: 2160.00 usec Create native/user threads: 2060.00 usec Create native/native threads: 1980.00 usec Create user/user threads: 1940.00 usec Create user/native threads: 2180.00 usec Create native/user threads: 1980.00 usec Create native/native threads: 1920.00 usec Create user/user threads: 2120.00 usec Create user/native threads: 2000.00 usec Create native/user threads: 2140.00 usec Create native/native threads: 1980.00 usec Create user/user threads: 1940.00 usec Create user/native threads: 2100.00 usec Create native/user threads: 2140.00 usec Create native/native threads: 1940.00 usec Create user/user threads: 2040.00 usec Create user/native threads: 1980.00 usec Create native/user threads: 2040.00 usec Create native/native threads: 1980.00 usec Create user/user threads: 1960.00 usec Create user/native threads: 2120.00 usec Create native/user threads: 2160.00 usec Create native/native threads: 1880.00 usec Now switch to recycling threads Create user/user threads: 2040.00 usec Create user/native threads: 1920.00 usec Create native/user threads: 2080.00 usec Create native/native threads: 2020.00 usec Create user/user threads: 2020.00 usec Create user/native threads: 1980.00 usec Create native/user threads: 2200.00 usec Create native/native threads: 2000.00 usec Create user/user threads: 2060.00 usec Create user/native threads: 2280.00 usec Create native/user threads: 2080.00 usec Create native/native threads: 1960.00 usec Create user/user threads: 2200.00 usec Create user/native threads: 1980.00 usec Create native/user threads: 2060.00 usec Create native/native threads: 2060.00 usec Create user/user threads: 2000.00 usec Create user/native threads: 2080.00 usec Create native/user threads: 2080.00 usec Create native/native threads: 2040.00 usec Create user/user threads: 2220.00 usec Create user/native threads: 2020.00 usec Create native/user threads: 2000.00 usec Create native/native threads: 2100.00 usec Create user/user threads: 2000.00 usec Create user/native threads: 2060.00 usec Create native/user threads: 1940.00 usec Create native/native threads: 2140.00 usec Create user/user threads: 2200.00 usec Create user/native threads: 2000.00 usec Create native/user threads: 2220.00 usec Create native/native threads: 2000.00 usec Create user/user threads: 2280.00 usec Create user/native threads: 2160.00 usec Create native/user threads: 2140.00 usec Create native/native threads: 1980.00 usec Create user/user threads: 2160.00 usec Create user/native threads: 2280.00 usec Create native/user threads: 2080.00 usec Create native/native threads: 2100.00 usec PASS ----test.log.ended--- these example of test-log were seemed to hung after test ended. but, sometimes hunged on the way, or finished nomally in rare cases. once hunged, RPI did not accept any key, perfect freeze. also /var/crash was empty. and i can not get any clue. >How-To-Repeat: # cd /usr/ports/devel/nspr # make install # make test # cd /usr/ports/devel/nspr/work/nspr-4.10/nspr/build/pr/tests # ./cvar2 # ./cvar2 -v # ./threads -d >Fix: Patch attached with submission follows: --- ../pr/include/md/_freebsd.h.orig 2013-08-28 13:16:35.000000000 +0900 +++ ../pr/include/md/_freebsd.h 2013-08-28 00:36:04.000000000 +0900 @@ -29,6 +29,8 @@ #define _PR_SI_ARCHITECTURE "powerpc64" #elif defined(__powerpc__) #define _PR_SI_ARCHITECTURE "powerpc" +#elif defined(__arm__) +#define _PR_SI_ARCHITECTURE "arm" #else #error "Unknown CPU architecture" #endif >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 10:13:47 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75D74CA4 for ; Sun, 1 Sep 2013 10:13:47 +0000 (UTC) (envelope-from fabiodive@gmail.com) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A1172416 for ; Sun, 1 Sep 2013 10:13:46 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id d41so1751007eek.36 for ; Sun, 01 Sep 2013 03:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=vaRZ7o85bZRxR9OsEZ9IS06oRvrFHm+pXQkEQyFKJAQ=; b=hXWcviD7sAucTx6P1fyjF3vqZjDidG/it0H/8nuSyoHRKNEKnCr1f3/C4Qq4J79xMT zUgO9f26mG573SMbOLS3xwON1lA5JxwpQCQuHGXwBCt0KhpA8heMflOHDLKF9AmQ4sDs BHrcKn/JOD0zUeliLIO3Bz8xtRFoa7qzfv+Jb7Z5LhGFk5AT4W6OqQQfJLidELvBv3dT EfDArRCC6NGR4E2Lx4E0Mu34VNxACui56yjKwsqfHQiaYhg77/4oBOwqsr7Oibvsr+1J NRKz+oR27FOlikDyGhOcaY+6c+VCzbcklUfdEDIL8nQWDz5fjESetfkXZbw2z/83SuLE +MDQ== X-Received: by 10.15.33.132 with SMTP id c4mr27702675eev.2.1378030425327; Sun, 01 Sep 2013 03:13:45 -0700 (PDT) Received: from [192.168.113.40] (135.Red-80-24-42.staticIP.rima-tde.net. [80.24.42.135]) by mx.google.com with ESMTPSA id p5sm12121437eeg.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Sep 2013 03:13:44 -0700 (PDT) From: fabiodive Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RASPBERRY PI: VFP, error during compilation of freebsd-head Message-Id: <9609F3A1-0CF9-49B0-B720-BDF1373E48C8@gmail.com> Date: Sun, 1 Sep 2013 11:13:43 +0100 To: "freebsd-arm@FreeBSD.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 10:13:47 -0000 Hello all, I tried few times to compile an updated freebsd-head with crochet but I = receive an error. I had one success few weeks ago, now I am trying to use VFP and = hardflot. FreeBSD-head Revision: 255108 My custom make.conf: CPUTYPE?=3D core2 CC=3Dclang CXX=3Dclang++ CPP=3Dclang-cpp WITH_CLANG=3Dyes WITH_CLANG_IS_CC=3Dyes # This setting to build world without -Werror: NO_WERROR=3D # # This setting to build kernel without -Werror: WERROR=3D=20 # # CFLAGS?=3D -Ofast -fno-strict-aliasing -pipe -march=3Darmv6zk -mfpu=3Dvfp = -mtune=3Darm1176jzf-s -mfloat-abi=3Dhard COPTFLAGS?=3D -Ofast -fno-strict-aliasing -pipe -march=3Darmv6zk = -mfpu=3Dvfp -mtune=3Darm1176jzf-s -mfloat-abi=3Dhard OPTIMIZED_CFLAGS=3D YES BUILD_OPTIMIZED=3D YES WITH_CPUFLAGS=3D YES WITHOUT_DEBUG=3D YES WITH_OPTIMIZED_CFLAGS=3D YES NO_PROFILE=3D YES #BUILD_STATIC=3D NO NO_INET6=3D YES WITH_IPV6=3D NO WITHOUT_IPV6=3D YES WITHOUT_X11=3D YES WITH_PKGNG=3D YES The exported environment variable: TARGET_ARCH=3Darmv6 This is the end of the log of the output of crochet: .. = MAKE=3D/tank/projects/boreview_freebsd/crochet-freebsd/work/obj/tank/proje= cts/boreview_freebsd/head/make.amd64/bmake sh = /tank/projects/boreview_freebsd/head/sys/conf/newvers.sh RPI-B clang -c -Ofast -fno-strict-aliasing -pipe -march=3Darmv6zk -mfpu=3Dvfp = -mtune=3Darm1176jzf-s -mfloat-abi=3Dhard -std=3Dc99 -Wall = -Wredundant-decls -Wnested-externs -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef = -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs = -fdiagnostics-show-option -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. = -I/tank/projects/boreview_freebsd/head/sys = -I/tank/projects/boreview_freebsd/head/sys/contrib/altq = -I/tank/projects/boreview_freebsd/head/sys/contrib/libfdt -D_KERNEL = -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -funwind-tables = -mllvm -arm-enable-ehabi -ffreestanding vers.c linking kernel objcopy --strip-debug kernel text data bss dec hex filename 4720280 225248 291788 5237316 4fea44 kernel ld: ERROR: hack.So uses VFP register arguments, kernel.noheader does not ld: failed to merge target specific data of file hack.So *** [kernel] Error code 1 bmake[1]: stopped in = /tank/projects/boreview_freebsd/crochet-freebsd/work/obj/arm.armv6/tank/pr= ojects/boreview_freebsd/head/sys/RPI-B 1 error bmake[1]: stopped in = /tank/projects/boreview_freebsd/crochet-freebsd/work/obj/arm.armv6/tank/pr= ojects/boreview_freebsd/head/sys/RPI-B *** [buildkernel] Error code 2 bmake: stopped in /tank/projects/boreview_freebsd/head 1 error bmake: stopped in /tank/projects/boreview_freebsd/head *** [buildkernel] Error code 2 1 error If somebody has got any idea I'll really appreciate it. thank you again, have a nice day, f. From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 10:18:11 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C6507D07; Sun, 1 Sep 2013 10:18:11 +0000 (UTC) (envelope-from taguchi.ch@gmail.com) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 962612428; Sun, 1 Sep 2013 10:18:11 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md4so3585972pbc.30 for ; Sun, 01 Sep 2013 03:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=i3frBn5Pm0bc+7WYTL6Bd3l9MpxAiCsDhffQLjDP9go=; b=Ut1ENiSrI/S1rLuvbBVzYPIjXyV5SF5wRvScFCJxx3tvOb3sOt0QQbpYkW9c/04I6b 30u5iTv+jdIEEbTSXjaV3EX2Dy00iBkQqgTqy5sDVoaWzMkiKPjS+n3doQgKPOOEXlEd cmqZABarYuYb7s0SHwVrmNQr97YkAIrDge2qxlLEenhMIHd0MW5VsgKAJTBWhnPbpLw5 lxbrwB3Vw4hzhz7Ze8QxxYPVNLrXYjUxsf9RrunlevBkyXO3c9JmoTFpLm5ibVW77Yz7 HtzxcpQmhqjgvbmtP/xAnaTMFqqEZ6mdQoojLOyA2fBdIiLWuZ2qjfBQaA0eByuEkU+P aJ4A== X-Received: by 10.66.182.229 with SMTP id eh5mr1458076pac.139.1378030690416; Sun, 01 Sep 2013 03:18:10 -0700 (PDT) Received: from arty (48.178.30.125.dy.iij4u.or.jp. [125.30.178.48]) by mx.google.com with ESMTPSA id bt1sm9045822pbb.2.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Sep 2013 03:18:09 -0700 (PDT) Date: Sun, 1 Sep 2013 19:18:07 +0900 From: Chie Taguchi To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-arm@FreeBSD.org Subject: Re: arm/181718: threads caused hung on ARM/RPI Message-Id: <20130901191807.aa3854586f3d7e6514fb09d8@gmail.com> In-Reply-To: <201309011000.r81A00Dh096364@freefall.freebsd.org> References: <201309010952.r819qR5G016511@oldred.freebsd.org> <201309011000.r81A00Dh096364@freefall.freebsd.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__1_Sep_2013_19_18_07_+0900_TsjHl4gNLICNWh//" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 10:18:11 -0000 This is a multi-part message in MIME format. --Multipart=_Sun__1_Sep_2013_19_18_07_+0900_TsjHl4gNLICNWh// Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit it is looks like missing one of my patches. and i will reattach it. thanks. C.Taguchi On Sun, 1 Sep 2013 10:00:00 GMT FreeBSD-gnats-submit@FreeBSD.org wrote: > Thank you very much for your problem report. > It has the internal identification `arm/181718'. > The individual assigned to look at your > report is: freebsd-arm. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=181718 > > >Category: arm > >Responsible: freebsd-arm > >Synopsis: threads caused hung on ARM/RPI > >Arrival-Date: Sun Sep 01 10:00:00 UTC 2013 -- Chie Taguchi --Multipart=_Sun__1_Sep_2013_19_18_07_+0900_TsjHl4gNLICNWh// Content-Type: text/plain; name="patch-nspr-pr-include-md-_freebsd_cfg.txt" Content-Disposition: attachment; filename="patch-nspr-pr-include-md-_freebsd_cfg.txt" Content-Transfer-Encoding: 7bit --- ../pr/include/md/_freebsd.cfg.orig 2013-08-28 13:17:50.000000000 +0900 +++ ../pr/include/md/_freebsd.cfg 2013-08-28 00:35:07.000000000 +0900 @@ -20,7 +20,7 @@ #define HAVE_LONG_LONG #endif -#if defined(__i386__) +#if defined(__i386__) || defined(__arm__) #define IS_LITTLE_ENDIAN 1 #undef IS_BIG_ENDIAN --Multipart=_Sun__1_Sep_2013_19_18_07_+0900_TsjHl4gNLICNWh//-- From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 10:20:01 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF89ED66 for ; Sun, 1 Sep 2013 10:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD453243F for ; Sun, 1 Sep 2013 10:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r81AK12j001202 for ; Sun, 1 Sep 2013 10:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r81AK1Rh001201; Sun, 1 Sep 2013 10:20:01 GMT (envelope-from gnats) Date: Sun, 1 Sep 2013 10:20:01 GMT Message-Id: <201309011020.r81AK1Rh001201@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Chie Taguchi Subject: Re: arm/181718: threads caused hung on ARM/RPI X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Chie Taguchi List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 10:20:01 -0000 The following reply was made to PR arm/181718; it has been noted by GNATS. From: Chie Taguchi To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-arm@FreeBSD.org Cc: taguchi.ch@gmail.com Subject: Re: arm/181718: threads caused hung on ARM/RPI Date: Sun, 1 Sep 2013 19:18:07 +0900 This is a multi-part message in MIME format. --Multipart=_Sun__1_Sep_2013_19_18_07_+0900_TsjHl4gNLICNWh// Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit it is looks like missing one of my patches. and i will reattach it. thanks. C.Taguchi On Sun, 1 Sep 2013 10:00:00 GMT FreeBSD-gnats-submit@FreeBSD.org wrote: > Thank you very much for your problem report. > It has the internal identification `arm/181718'. > The individual assigned to look at your > report is: freebsd-arm. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=181718 > > >Category: arm > >Responsible: freebsd-arm > >Synopsis: threads caused hung on ARM/RPI > >Arrival-Date: Sun Sep 01 10:00:00 UTC 2013 -- Chie Taguchi --Multipart=_Sun__1_Sep_2013_19_18_07_+0900_TsjHl4gNLICNWh// Content-Type: text/plain; name="patch-nspr-pr-include-md-_freebsd_cfg.txt" Content-Disposition: attachment; filename="patch-nspr-pr-include-md-_freebsd_cfg.txt" Content-Transfer-Encoding: 7bit --- ../pr/include/md/_freebsd.cfg.orig 2013-08-28 13:17:50.000000000 +0900 +++ ../pr/include/md/_freebsd.cfg 2013-08-28 00:35:07.000000000 +0900 @@ -20,7 +20,7 @@ #define HAVE_LONG_LONG #endif -#if defined(__i386__) +#if defined(__i386__) || defined(__arm__) #define IS_LITTLE_ENDIAN 1 #undef IS_BIG_ENDIAN --Multipart=_Sun__1_Sep_2013_19_18_07_+0900_TsjHl4gNLICNWh//-- From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 11:00:00 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BC7D72CD for ; Sun, 1 Sep 2013 11:00:00 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9767C25B9 for ; Sun, 1 Sep 2013 11:00:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r81B00pb008114 for ; Sun, 1 Sep 2013 11:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r81B00T2008112; Sun, 1 Sep 2013 11:00:00 GMT (envelope-from gnats) Resent-Date: Sun, 1 Sep 2013 11:00:00 GMT Resent-Message-Id: <201309011100.r81B00T2008112@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Peter Jeremy Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 67C0F18C for ; Sun, 1 Sep 2013 10:52:40 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B4A02258A for ; Sun, 1 Sep 2013 10:52:38 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r81AqSwp096591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 1 Sep 2013 20:52:29 +1000 (EST) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.7/8.14.7) with ESMTP id r81AqNMZ096350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Sep 2013 20:52:23 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.7/8.14.7/Submit) id r81AqNiV096349; Sun, 1 Sep 2013 20:52:23 +1000 (EST) (envelope-from peter) Message-Id: <201309011052.r81AqNiV096349@server.rulingia.com> Date: Sun, 1 Sep 2013 20:52:23 +1000 (EST) From: Peter Jeremy To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.114 Subject: arm/181722: gdb on ARM unable to sensibly debug core file from assert(3) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Peter Jeremy List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 11:00:00 -0000 >Number: 181722 >Category: arm >Synopsis: gdb on ARM unable to sensibly debug core file from assert(3) >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Sep 01 11:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Peter Jeremy >Release: FreeBSD 10.0-CURRENT arm >Organization: n/a >Environment: System: FreeBSD rpi1.rulingia.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Mon Jul 8 19:45:57 UTC 2013 root@rpi1.rulingia.com:/usr/obj/usr/src/sys/RPI-PJ arm >Description: Whilst trying to build head r254986 with clang on my Raspberry Pi, I consistently get an assertion failure and core file. Attempting to examine the core file with gdb gives a truncated backtrace (see below). If clang is run under gdb, setting a breakpoint at __assert, correct backtraces are shown. root@rpi1:/a # gdb /a/obj/usr/src/tmp/usr/bin/cc cc.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "armv6-marcel-freebsd"... Core was generated by `cc'. Program terminated with signal 6, Aborted. #0 0x01f92094 in kill () (gdb) where #0 0x01f92094 in kill () #1 0x01f92038 in raise () #2 0x01f901a0 in abort () #3 0x01f7b55c in __assert () #4 0x01f7b55c in __assert () (gdb) ... (gdb) up #4 0x01f7b55c in __assert () (gdb) info regi r0 0x0 0 r1 0x0 0 r2 0x0 0 r3 0xffffffdf -33 r4 0x0 0 r5 0xbfffcb74 -1073755276 r6 0x3 3 r7 0x57 87 r8 0x228152b8 578900664 r9 0x2284fb00 579140352 r10 0x22876000 579297280 r11 0xbfffcba8 -1073755224 r12 0xbfffcb94 -1073755244 sp *value not available* lr 0x1f7b55c 33011036 pc 0x1f7b55c 33011036 fps 0x0 0 cpsr 0x80000010 -2147483632 (gdb) disas 0x1f7b55c Dump of assembler code for function $d: 0x01f7b55c <$d+0>: eorseq r8, r11, #12845056 ; 0xc40000 0x01f7b560 <$d+4>: eorseq r3, r10, #16515072 ; 0xfc0000 0x01f7b564 <$d+8>: eorseq r3, r10, #655360 ; 0xa0000 End of assembler dump. (gdb) disas __assert Dump of assembler code for function __assert: 0x01f7b4fc <__assert+0>: mov r12, sp 0x01f7b500 <__assert+4>: push {r11, r12, lr, pc} 0x01f7b504 <__assert+8>: sub r11, r12, #4 ; 0x4 0x01f7b508 <__assert+12>: sub sp, sp, #8 ; 0x8 0x01f7b50c <__assert+16>: mov lr, r1 0x01f7b510 <__assert+20>: mov r4, r3 0x01f7b514 <__assert+24>: subs r12, r0, #0 ; 0x0 0x01f7b518 <__assert+28>: bne 0x1f7b53c <__assert+64> 0x01f7b51c <__assert+32>: ldr r3, [pc, #56] ; 0x1f7b55c <$d> 0x01f7b520 <__assert+36>: ldr r0, [r3] 0x01f7b524 <__assert+40>: str r2, [sp] 0x01f7b528 <__assert+44>: ldr r1, [pc, #48] ; 0x1f7b560 <$d+4> 0x01f7b52c <__assert+48>: mov r2, r4 0x01f7b530 <__assert+52>: mov r3, lr 0x01f7b534 <__assert+56>: bl 0x1f7b6c0 0x01f7b538 <__assert+60>: b 0x1f7b558 <__assert+92> 0x01f7b53c <__assert+64>: ldr r3, [pc, #24] ; 0x1f7b55c <$d> 0x01f7b540 <__assert+68>: ldr r0, [r3] 0x01f7b544 <__assert+72>: stm sp, {r1, r2} 0x01f7b548 <__assert+76>: ldr r1, [pc, #20] ; 0x1f7b564 <$d+8> 0x01f7b54c <__assert+80>: mov r2, r4 0x01f7b550 <__assert+84>: mov r3, r12 0x01f7b554 <__assert+88>: bl 0x1f7b6c0 0x01f7b558 <__assert+92>: bl 0x1f90104 End of assembler dump. (gdb) x/20x $r12 0xbfffcb94: Cannot access memory at address 0xbfffcb94 (gdb) >How-To-Repeat: $ cat < /tmp/test.i extern void __stack_chk_fail (void); void __attribute__((visibility ("hidden"))) __stack_chk_fail_local (void) { __stack_chk_fail (); } E*O*F $ clang -cc1 -triple armv6--freebsd10.0-gnueabi -S -disable-free -main-file-name ssp-local.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -mconstructor-aliases -target-abi aapcs-linux -target-cpu arm1136jf-s -msoft-float -mfloat-abi soft -target-feature +soft-float -target-feature +soft-float-abi -target-feature -neon -g -coverage-file /tmp/test.s -O2 -std=gnu99 -fno-dwarf-directory-asm -fdebug-compilation-dir /usr/obj/usr/src/gnu/lib/libssp/libssp_nonshared -ferror-limit 19 -fmessage-length 168 -fvisibility hidden -mstackrealign -fno-signed-char -fobjc-runtime=gnustep -fobjc-default-synthesize-properties -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -o /tmp/test.s -x c /tmp/test.i $ gdb clang clang.core (gdb) where >Fix: Unknown. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 11:07:26 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CDAC3446 for ; Sun, 1 Sep 2013 11:07:26 +0000 (UTC) (envelope-from taguchi949@gmail.com) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A80402610 for ; Sun, 1 Sep 2013 11:07:26 +0000 (UTC) Received: by mail-pb0-f42.google.com with SMTP id un15so3651916pbc.15 for ; Sun, 01 Sep 2013 04:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=oZwT4JFJCnPnmurUB1RtY4ufBZnAf4GJ7T8jXclw/Ik=; b=NhtDj/1VARmMRsC9cxVuPSVlcZ9tSRzH+WxcYc8a6RN29xcQhpTOO4K/aWY8vN+qV5 cRI548yP7+7fbIT/htorEne5wz9DkI0j6WqES8pgtJrwoeZDHSfWacrcyOpoSi7y3ki+ 8ZGid79Oylcq00dA2i1v5zQMONHp/hPKdYN4uyJfJXNL1F+ZGIMMNT9vn84TJZkzz0I6 QqAqIMx/2vqz5VL9ZFND4em+l7zTwCg2g7FJyNOUlNTvVsL5j/zC7jgOqOYLOi3m4suB TQah/dBGiflhuOnoCmxsE/JOxnuu2Zyag23zg/EJsspHgEg8Sa46ZIzoSU8poLoqzOc0 AC1g== X-Received: by 10.68.238.196 with SMTP id vm4mr19892980pbc.11.1378033646188; Sun, 01 Sep 2013 04:07:26 -0700 (PDT) Received: from BL-212 (48.178.30.125.dy.iij4u.or.jp. [125.30.178.48]) by mx.google.com with ESMTPSA id in2sm9209937pbc.37.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 01 Sep 2013 04:07:25 -0700 (PDT) Date: Sun, 1 Sep 2013 20:07:26 +0900 From: Takeshi Taguchi To: freebsd-arm@freebsd.org Subject: Re: What's the recipe? Message-Id: <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> In-Reply-To: <522229C0.5030504@m5p.com> References: <522229C0.5030504@m5p.com> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 11:07:26 -0000 On Sat, 31 Aug 2013 13:37:04 -0400 George Mitchell wrote: > Have you built a working Raspberry Pi image recently? If so, for the > benefit of the rest of us, could you share a few secrets? there are no secrets ;-) > 1. What system did you do the build on? If it was an i386 or amd64, > what svn version was it built with? amd64 on virtualbox. # uname -a FreeBSD amd64-01 10.0-CURRENT FreeBSD 10.0-CURRENT #10 r255093M: Sat Aug 31 21:41:10 JST 2013 root@amd64-01:/usr/obj/usr/src/sys/VIRTUALBOX amd64 > > 2. What did you have in /etc/src.conf and /etc/make.conf, both for > building the build system itself and for building the RPi? i use same make|src.conf for pi and amd64. % egrep -v ^# /etc/make.conf COPTFLAGS= -O -pipe TOP_TABLE_SIZE= 101 WITH_PKGNG=YES NO_WERROR= WERROR= PERL_VERSION=5.14.4 WITH_NEW_XORG=yes % egrep -v ^# /etc/src.conf MALLOC_PRODUCTION=YES i think we stil need MALLOC_PRODUCTION. because jemalloc issue does not fixed yet. > > 3. What svn version of /usr/src did you use in building the RPi image? % uname -a FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r255093M: Sun Sep 1 02:25:56 JST 2013 root@amd64-01:/usr/home/armdevel/crochet-freebsd/work/obj /arm.armv6/usr/src/sys/RPI-B arm i applied 2 patch: a. 'working console on manut prompt' patch. i found it this ml. b. enabling mount_smbfs on arm patch. kern/180438. and i disabled any debugging options on my KERNCONF. > 4. Did you use crochet? If so, what was the last commit in your git > log? Yes. % git log commit b154a2f1252eaa5f4d821439d0d9005cea94e580 Merge: a6f4cc5 8d03c23 Author: Tim Kientzle Date: Sat Aug 17 12:00:52 2013 -0700 ... Merge branch 'skibo-master' Thanks. -- Takeshi Taguchi From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 12:34:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D2C1FFBF for ; Sun, 1 Sep 2013 12:34:01 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id B5C0E295C for ; Sun, 1 Sep 2013 12:34:01 +0000 (UTC) Received: from bender.Home (97e5e46b.skybroadband.com [151.229.228.107]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id F00CA5DFF7; Sun, 1 Sep 2013 12:33:54 +0000 (UTC) Date: Sun, 1 Sep 2013 13:33:46 +0100 From: Andrew Turner To: fabiodive Subject: Re: RASPBERRY PI: VFP, error during compilation of freebsd-head Message-ID: <20130901133346.4768238d@bender.Home> In-Reply-To: <9609F3A1-0CF9-49B0-B720-BDF1373E48C8@gmail.com> References: <9609F3A1-0CF9-49B0-B720-BDF1373E48C8@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@FreeBSD.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 12:34:01 -0000 On Sun, 1 Sep 2013 11:13:43 +0100 fabiodive wrote: > Hello all, > > I tried few times to compile an updated freebsd-head with crochet but > I receive an error. I had one success few weeks ago, now I am trying > to use VFP and hardflot. This is not yet supported in FreeBSD. I'm working on it, but it will take a little more work than just adding -mfloat-abi=hard to CFLAGS. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 13:48:34 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AA53341E for ; Sun, 1 Sep 2013 13:48:34 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 62FB62C5A for ; Sun, 1 Sep 2013 13:48:34 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r81Dm9nH050374; Sun, 1 Sep 2013 09:48:31 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <52234599.2020609@m5p.com> Date: Sun, 01 Sep 2013 09:48:09 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org, taguchi949@gmail.com Subject: Re: What's the recipe? References: <522229C0.5030504@m5p.com> <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> In-Reply-To: <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 01 Sep 2013 09:48:31 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 13:48:34 -0000 On 09/01/13 07:07, Takeshi Taguchi wrote: > On Sat, 31 Aug 2013 13:37:04 -0400 > George Mitchell wrote: > >[...] >> >> 2. What did you have in /etc/src.conf and /etc/make.conf, both for >> building the build system itself and for building the RPi? > i use same make|src.conf for pi and amd64. > % egrep -v ^# /etc/make.conf > COPTFLAGS= -O -pipe > TOP_TABLE_SIZE= 101 > > WITH_PKGNG=YES > NO_WERROR= > WERROR= > PERL_VERSION=5.14.4 > WITH_NEW_XORG=yes > > [...] So you got a working system using clang? Very interesting! Thanks for the feedback. -- George From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 13:50:51 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1C715479 for ; Sun, 1 Sep 2013 13:50:51 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C898C2C6F for ; Sun, 1 Sep 2013 13:50:50 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r81DoiG2050397; Sun, 1 Sep 2013 09:50:49 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <52234634.4090609@m5p.com> Date: Sun, 01 Sep 2013 09:50:44 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org, taguchi949@gmail.com Subject: Re: What's the recipe? References: <522229C0.5030504@m5p.com> <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> <52234599.2020609@m5p.com> In-Reply-To: <52234599.2020609@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 01 Sep 2013 09:50:49 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 13:50:51 -0000 On 09/01/13 09:48, George Mitchell wrote: > On 09/01/13 07:07, Takeshi Taguchi wrote: >> On Sat, 31 Aug 2013 13:37:04 -0400 >> George Mitchell wrote: >> >> [...] >>> >>> 2. What did you have in /etc/src.conf and /etc/make.conf, both for >>> building the build system itself and for building the RPi? >> i use same make|src.conf for pi and amd64. >> % egrep -v ^# /etc/make.conf >> COPTFLAGS= -O -pipe >> TOP_TABLE_SIZE= 101 >> >> WITH_PKGNG=YES >> NO_WERROR= >> WERROR= >> PERL_VERSION=5.14.4 >> WITH_NEW_XORG=yes >> >> [...] Sorry, I didn't mean to trim this part of your message: > % egrep -v ^# /etc/src.conf > MALLOC_PRODUCTION=YES > > i think we stil need MALLOC_PRODUCTION. because jemalloc issue > does not fixed yet. From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 13:50:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 609E847A for ; Sun, 1 Sep 2013 13:50:56 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E17A2C70 for ; Sun, 1 Sep 2013 13:50:55 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r81Domgu071782; Sun, 1 Sep 2013 13:50:48 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id asvkbz6yhkg4dmvrnxenab9kfn; Sun, 01 Sep 2013 13:50:48 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: What's the recipe? From: Tim Kientzle In-Reply-To: <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> Date: Sun, 1 Sep 2013 06:50:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <522229C0.5030504@m5p.com> <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> To: Takeshi Taguchi X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 13:50:56 -0000 On Sep 1, 2013, at 4:07 AM, Takeshi Taguchi wrote: > On Sat, 31 Aug 2013 13:37:04 -0400 > George Mitchell wrote: > >> Have you built a working Raspberry Pi image recently? If so, for the >> benefit of the rest of us, could you share a few secrets? > there are no secrets ;-) > >> 1. What system did you do the build on? If it was an i386 or amd64, >> what svn version was it built with? > amd64 on virtualbox. > # uname -a > FreeBSD amd64-01 10.0-CURRENT FreeBSD 10.0-CURRENT #10 r255093M: Sat Aug 31 > 21:41:10 JST 2013 root@amd64-01:/usr/obj/usr/src/sys/VIRTUALBOX amd64 > >> >> 2. What did you have in /etc/src.conf and /etc/make.conf, both for >> building the build system itself and for building the RPi? > i use same make|src.conf for pi and amd64. > % egrep -v ^# /etc/make.conf > COPTFLAGS= -O -pipe > TOP_TABLE_SIZE= 101 > > WITH_PKGNG=YES > NO_WERROR= > WERROR= > PERL_VERSION=5.14.4 > WITH_NEW_XORG=yes > > % egrep -v ^# /etc/src.conf > MALLOC_PRODUCTION=YES > > i think we stil need MALLOC_PRODUCTION. because jemalloc issue > does not fixed yet. Note that Crochet has SRCCONF=/dev/null __MAKE_CONF=/dev/null by default. You can override those in your Crochet configuration file if you wish. From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 13:58:38 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4E0C95B3 for ; Sun, 1 Sep 2013 13:58:38 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 241FE2CE0 for ; Sun, 1 Sep 2013 13:58:37 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VG8Ag-000PSy-S9; Sun, 01 Sep 2013 13:58:31 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r81DwROc066786; Sun, 1 Sep 2013 07:58:27 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Wc8od9FtXr9G7ZUC7uyEf Subject: Re: What's the recipe? From: Ian Lepore To: Takeshi Taguchi In-Reply-To: <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> References: <522229C0.5030504@m5p.com> <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Sep 2013 07:58:27 -0600 Message-ID: <1378043907.1111.351.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 13:58:38 -0000 On Sun, 2013-09-01 at 20:07 +0900, Takeshi Taguchi wrote: > % egrep -v ^# /etc/src.conf > MALLOC_PRODUCTION=YES > > i think we stil need MALLOC_PRODUCTION. because jemalloc issue > does not fixed yet. > This is not correct. There is no longer a need to set MALLOC_PRODUCTION, the performance problem that required it was fixed months ago. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 14:40:23 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 12B8C1DB for ; Sun, 1 Sep 2013 14:40:23 +0000 (UTC) (envelope-from taguchi949@gmail.com) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E011F2FCB for ; Sun, 1 Sep 2013 14:40:22 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id uo5so3755977pbc.37 for ; Sun, 01 Sep 2013 07:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=GaKMcwrYMNNPC9cFhOy0HPDEVWD0PbPzhuijdFA2JP0=; b=EmFTDOBian5/ESa3/TIXMDbpUNQNSi1Qg4uHVczE3Jyi+BoNqiiIC4KXwZ3oz2YQFL y357s5LENLRyLUv0+VE3PSwC9LExCAZWpSQYYOP0kLN0HvCM5cDD57NGoGMksyXCdm1A wx547JWoHAPGZxCQkL0mbwnjCU/EjPgoL8wfp4GJOQTqNiLz5py88E6Fy9hPWzOwXUPd y8Ank8wGRsNdg+lUQ415MrBRnKA90qfgqNVCBrZg0+bGqhFKUPOHteEHXjSN4EcGZIrv 8w62FFD3SHchYjWNHQZ5eW6flk5AYslwtJoKyrKX7OgJowbikxGHbl6mKfQb45Or5Npv 3oqw== X-Received: by 10.66.25.232 with SMTP id f8mr21795437pag.25.1378046422579; Sun, 01 Sep 2013 07:40:22 -0700 (PDT) Received: from BL-212 (48.178.30.125.dy.iij4u.or.jp. [125.30.178.48]) by mx.google.com with ESMTPSA id tg7sm10079803pbc.36.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 01 Sep 2013 07:40:22 -0700 (PDT) Date: Sun, 1 Sep 2013 23:40:23 +0900 From: Takeshi Taguchi To: freebsd-arm@freebsd.org Subject: Re: What's the recipe? Message-Id: <20130901234023.ff8c398e2c9cba515b7470ef@gmail.com> In-Reply-To: <1378043907.1111.351.camel@revolution.hippie.lan> References: <522229C0.5030504@m5p.com> <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> <1378043907.1111.351.camel@revolution.hippie.lan> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 14:40:23 -0000 Hi, Ian. not performance issue. it's sshd crash probrem. sshd and some programs crash with following mesg: : jemalloc_arena.c:380: Failed assertion: "p[i] == 0" MALLOC_PRODUCTION suppress this crash. YES. this is NOT good way. but it's seem work fine. Thanks. On Sun, 01 Sep 2013 07:58:27 -0600 Ian Lepore wrote: > On Sun, 2013-09-01 at 20:07 +0900, Takeshi Taguchi wrote: > > % egrep -v ^# /etc/src.conf > > MALLOC_PRODUCTION=YES > > > > i think we stil need MALLOC_PRODUCTION. because jemalloc issue > > does not fixed yet. > > > This is not correct. There is no longer a need to set MALLOC_PRODUCTION, > the performance problem that required it was fixed months ago. > > -- Ian > > -- Takeshi Taguchi From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 14:42:48 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9A9513F7 for ; Sun, 1 Sep 2013 14:42:48 +0000 (UTC) (envelope-from army.of.root@gmail.com) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2FBD92FF8 for ; Sun, 1 Sep 2013 14:42:48 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id c50so1841066eek.18 for ; Sun, 01 Sep 2013 07:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=liU0rJmdQ5hrLrOHDnqVkHoLOF6KpgmL87EDEC8rDns=; b=eb9i1lQELzkzGEIaWRqCGnWQ887cgouqVGkikGXhlPkMAvGbDyat1DO6ObWLIs9rla Z+jqoKRHjf/Uhe/4LSHUXR3umCjrebOW1wUU4VTACaWOQ/R4MPyerBeStENbi/JqiGIF 7aVTUjXdz55iLaLibdTTD5Mr/rTJw+JN8arShCdj62VqJ/lpZ8EwG98nK+BPjMSDNaaW emh8DEn9wBKLDltLt5ti+Q+0rfnGmWnDcm777oB4jqwcbgRjV4zTMaakKTGpdx1I04g1 zegHBbbglRobNJESgmtRUPBItoKHjabXguEDFrdXnJRyKBQHRs+9MXp7TshuNlwx+XoZ SuAA== X-Received: by 10.15.83.2 with SMTP id b2mr29436055eez.28.1378046566555; Sun, 01 Sep 2013 07:42:46 -0700 (PDT) Received: from titanium-3.local (ip-176-199-214-162.unitymediagroup.de. [176.199.214.162]) by mx.google.com with ESMTPSA id h52sm13868261eez.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Sep 2013 07:42:45 -0700 (PDT) Message-ID: <52235263.5080503@googlemail.com> Date: Sun, 01 Sep 2013 16:42:43 +0200 From: "army.of.root" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: dockstar (kirkwood) EHCI needs "usb start" in u-boot or it will hang Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 14:42:48 -0000 Hi, I just spent an hour trying to get my dockstar to boot a head kernel. I switched from putting the kernel on a usb drive to booting it via tftp from u-boot for convienience purposes. The usb drive boot script in u-boot obviously starts up the usb subsystem, but I left it out for the tftp routine. This resulted in a hanging Kernel on this output: > ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 > usbus0: EHCI version 1.0 > usbus0: stop timeout > usbus0: set host controller mode > usbus0 on ehci0 > After having a joyful moment of clarity and adding the command "usb start" to my tftp uboot script, the issue was resolved. Is this expected behavior? Or am I missing a kernel option (various combinations did not help including the default DOCKSTAR config)? Thank you for your efforts & Kind regards From owner-freebsd-arm@FreeBSD.ORG Sun Sep 1 18:45:03 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 365704E3 for ; Sun, 1 Sep 2013 18:45:03 +0000 (UTC) (envelope-from hippie@damnhippie.dyndns.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0C88E2F05 for ; Sun, 1 Sep 2013 18:45:02 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VGCds-000Kfx-Gx; Sun, 01 Sep 2013 18:44:56 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r81Iirnc066930; Sun, 1 Sep 2013 12:44:53 -0600 (MDT) (envelope-from hippie@damnhippie.dyndns.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19tun8DIuGQJqpd2511Xl+w Subject: Re: dockstar (kirkwood) EHCI needs "usb start" in u-boot or it will hang From: Ian To: "army.of.root" In-Reply-To: <52235263.5080503@googlemail.com> References: <52235263.5080503@googlemail.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Sep 2013 12:44:53 -0600 Message-ID: <1378061093.1111.358.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 18:45:03 -0000 On Sun, 2013-09-01 at 16:42 +0200, army.of.root wrote: > Hi, > > I just spent an hour trying to get my dockstar to boot a head kernel. > > I switched from putting the kernel on a usb drive to booting it via tftp from > u-boot for convienience purposes. > The usb drive boot script in u-boot obviously starts up the usb subsystem, but > I left it out for the tftp routine. > > This resulted in a hanging Kernel on this output: > > > ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 > > usbus0: EHCI version 1.0 > > usbus0: stop timeout > > usbus0: set host controller mode > > usbus0 on ehci0 > > > > After having a joyful moment of clarity and adding the command "usb start" to > my tftp uboot script, the issue was resolved. > > > Is this expected behavior? > > Or am I missing a kernel option (various combinations did not help including > the default DOCKSTAR config)? Strange, it's not like that on my similar DreamPlug system... Marvell>> usb info USB is stopped. Please issue 'usb start' first. Marvell>> run netboot BOOTP broadcast 1 ... FreeBSD 10.0-CURRENT #7 r254449M: Thu Aug 29 12:19:59 MDT 2013 root@revolution.hippie.lan:/local/build/staging/freebsd/dp10/obj/arm.arm/local/build/staging/freebsd/dp10/src/sys/DP-NFSROOT arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Feroceon 88FR131 rev 1 (Marvell core) Little-endian DC enabled IC enabled WA disabled DC streaming enabled BTB disabled L2 enabled L2 prefetch enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 536870912 (512 MB) avail memory = 515407872 (491 MB) SOC: Marvell 88F6281 rev A1, TClock 200MHz Instruction cache prefetch disabled, data cache prefetch disabled 256KB 4-way set-associative write-through unified L2 cache ... ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0: stop timeout usbus0: set host controller mode usbus0 on ehci0 mvs0: mem 0xf1080000-0xf1085fff irq 21 on simplebus0 It boots fine from there until it runs into the initrandom and tmpfs problems we've been having on armv5 platforms. If I ^C may through those things and get logged on, I can run usbconfig and see devices. I looked at the u-boot code for marvell ehci and it just initializes the decode window registers before calling the stock ehci code. That's also what happens in the kernel, in arm/mv/common.c. The thing I can't quite figure out about the kernel code is the strange power management stuff for marvell. But I don't see the u-boot code doing any power management stuff at all (maybe I just missed it). -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Sep 2 05:27:10 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0FB4F2A for ; Mon, 2 Sep 2013 05:27:10 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay01.alfahosting-server.de (relay01.alfahosting-server.de [109.237.142.236]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B4C12EA6 for ; Mon, 2 Sep 2013 05:27:10 +0000 (UTC) Received: by relay01.alfahosting-server.de (Postfix, from userid 1001) id BAC3C32DCC02; Mon, 2 Sep 2013 07:27:01 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay01.alfahosting-server.de (Postfix) with ESMTPS id 6D29132DCC07 for ; Mon, 2 Sep 2013 07:27:00 +0200 (CEST) Received: from laabs.hf.ifn.et.tu-dresden.de (hfsync.ifn.et.tu-dresden.de [141.30.128.60]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id 5781B515DE9A for ; Mon, 2 Sep 2013 07:27:00 +0200 (CEST) Message-ID: <522421A3.4040704@martinlaabs.de> Date: Mon, 02 Sep 2013 07:26:59 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: What's the recipe? References: <522229C0.5030504@m5p.com> <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> <1378043907.1111.351.camel@revolution.hippie.lan> <20130901234023.ff8c398e2c9cba515b7470ef@gmail.com> In-Reply-To: <20130901234023.ff8c398e2c9cba515b7470ef@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17789/Mon Sep 2 04:50:42 2013 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 05:27:10 -0000 Hi, > not performance issue. > it's sshd crash probrem. > > sshd and some programs crash with following mesg: > : jemalloc_arena.c:380: Failed assertion: "p[i] == 0" Well - I compiled r254984 with crochet with (if I remember correct) has an empty src.conf and I have no problem with the sshd at all. But I will check the config to ensure that I do not have the MALLOC_PRODUCTION inside of the config. Best regards, Martin Laabs From owner-freebsd-arm@FreeBSD.ORG Mon Sep 2 06:42:09 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 04589425; Mon, 2 Sep 2013 06:42:09 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay04.alfahosting-server.de (relay04.alfahosting-server.de [109.237.142.240]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B43EE21B6; Mon, 2 Sep 2013 06:42:08 +0000 (UTC) Received: by relay04.alfahosting-server.de (Postfix, from userid 1001) id 8384932D176F; Mon, 2 Sep 2013 08:42:06 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay04.alfahosting-server.de (Postfix) with ESMTPS id 9CB4E32D0CC9; Mon, 2 Sep 2013 08:42:04 +0200 (CEST) Received: from laabs.hf.ifn.et.tu-dresden.de (hfsync.ifn.et.tu-dresden.de [141.30.128.60]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id 84615515DE98; Mon, 2 Sep 2013 08:42:04 +0200 (CEST) Message-ID: <5224333C.8070305@martinlaabs.de> Date: Mon, 02 Sep 2013 08:42:04 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: No UDP/TCP IPv6 connectivity (only) to router using gif interface - maybe ARM related Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17790/Mon Sep 2 06:48:29 2013 Cc: freebsd-arm , freebsd-current@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 06:42:09 -0000 Hi, I tried to set up my raspberry PI as an ipv6 router. As a tunnel broker I use sixxs. Now I observed an interesting behavior: Every host from my network can reach the ipv6 world. The ipv6 world can also reach every host in my network. However - the router itself is unable to make udp or tcp connection to the "world" and is also unable to accept connections form the "world" ICMP however works properly. I had a look to the tcpdump and when trying to connect i.e. to www.kame.net the rasperry router sends a syn packet and get a syn/ack packet back. The rest of the handshake is missing. I tried also some udp with netcat (nc -6 -u -l 5555 on the server and nc -6 -u 5555 on the client) This works great for internal (ethernet) traffic but when the data should go through the tunnel if fails. The last test is maybe the most significant to describe the bug: Start netcat to listen for UDP packages on an external host: nc -6 -u -l 5555 Connect from the RPI-Router to that host nc -6 -u 2001:4dd0:xxxx:xxxx::2 5555 Now it is possible to send data from the RPI router to the external host but the opposite direction does not work. Tcpdump however shows that the udp package arrives but it is not "forwarded" to the application. So for me it seems to be a problem with the handling of the receiving data in the gif interface. This behavior is independent from net.inet6.ip6.forwarding or net.inet6.ip6.redirect status. The router system: FreeBSD raspberry-pi.xxx 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r254984 Best regards, Martin Laabs From owner-freebsd-arm@FreeBSD.ORG Mon Sep 2 07:30:10 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3D27ABF5 for ; Mon, 2 Sep 2013 07:30:10 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0192923D9 for ; Mon, 2 Sep 2013 07:30:10 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VGOaI-000PyB-C2; Mon, 02 Sep 2013 08:30:05 +0100 Subject: Re: What's the recipe? Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_70005E20-7A8A-4353-B326-A23895915EEE"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: Date: Mon, 2 Sep 2013 08:30:01 +0100 Message-Id: <0AC24F9A-7AE0-4E98-BC21-273FA097AE0F@grondar.org> References: <522229C0.5030504@m5p.com> <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: Takeshi Taguchi , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 07:30:10 -0000 --Apple-Mail=_70005E20-7A8A-4353-B326-A23895915EEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1 Sep 2013, at 14:50, Tim Kientzle wrote: >=20 > On Sep 1, 2013, at 4:07 AM, Takeshi Taguchi = wrote: >=20 >> On Sat, 31 Aug 2013 13:37:04 -0400 >> George Mitchell wrote: >>=20 >>> Have you built a working Raspberry Pi image recently? If so, for = the >>> benefit of the rest of us, could you share a few secrets? >> there are no secrets ;-) >>=20 >>> 1. What system did you do the build on? If it was an i386 or amd64, >>> what svn version was it built with? >> amd64 on virtualbox. >> # uname -a >> FreeBSD amd64-01 10.0-CURRENT FreeBSD 10.0-CURRENT #10 r255093M: Sat = Aug 31 >> 21:41:10 JST 2013 root@amd64-01:/usr/obj/usr/src/sys/VIRTUALBOX = amd64 >>=20 >>>=20 >>> 2. What did you have in /etc/src.conf and /etc/make.conf, both for >>> building the build system itself and for building the RPi? >> i use same make|src.conf for pi and amd64. >> % egrep -v ^# /etc/make.conf >> COPTFLAGS=3D -O -pipe >> TOP_TABLE_SIZE=3D 101 >>=20 >> WITH_PKGNG=3DYES >> NO_WERROR=3D >> WERROR=3D >> PERL_VERSION=3D5.14.4 >> WITH_NEW_XORG=3Dyes >>=20 >> % egrep -v ^# /etc/src.conf >> MALLOC_PRODUCTION=3DYES >>=20 >> i think we stil need MALLOC_PRODUCTION. because jemalloc issue >> does not fixed yet. >=20 > Note that Crochet has >=20 > SRCCONF=3D/dev/null > __MAKE_CONF=3D/dev/null >=20 > by default. You can override those in your Crochet configuration file > if you wish. Thanks! I've spent the weekend trying to get a crochet build for Raspberry Pi = going by various means. My build box is CURRENT as of Sept 1 2013, and = is an AMD86. The only things in /etc/(make|src).conf are to remove stuff = like CTM, LPR and other things of little relevance. CURRENT + crochet cannot build u-boot because it looks like the antique = CURRENT/GCC-xdev can't handle a couple of command-line options that = u-boot wants (-fstack-usage, the other is hiding), but if I remove those = it eventually fails with redefinitions of things like __packed, __pure = and so on (this is GCC "armv6-freebsd-gcc", not CLANG). I tried to hack up a u-boot port using the Beaglebone Black u-boot port = as an example; that needs devel/arm-eabi-gcc which fails because of = redefinition of some functions during the build. I'm pretty stuck here without going on a major debugging mission - has = anyone got a reliable build going, please? M --=20 Mark R V Murray --Apple-Mail=_70005E20-7A8A-4353-B326-A23895915EEE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUiQ+ed58vKOKE6LNAQqQAQP/W0mWB46/27ycuCkTFP04vg0T1dnQA8bE aZ+qt200hta4rf4Rq6u4eLuVrRgFt8M/ayZ9+eORCsl/P47BT38vVKgrsQ4YJakM V0Ip2+80NpfA+rGk19OnzJYVzoknREyb2CwyH4sz2GeqwLw5Hq0PWdlJAdg63og4 JffhoixVmfA= =wTRr -----END PGP SIGNATURE----- --Apple-Mail=_70005E20-7A8A-4353-B326-A23895915EEE-- From owner-freebsd-arm@FreeBSD.ORG Mon Sep 2 08:52:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EDCF5F00; Mon, 2 Sep 2013 08:52:09 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews02.kpnxchange.com (cpsmtpb-ews02.kpnxchange.com [213.75.39.5]) by mx1.freebsd.org (Postfix) with ESMTP id 88C2C28BE; Mon, 2 Sep 2013 08:52:08 +0000 (UTC) Received: from cpsps-ews26.kpnxchange.com ([10.94.84.192]) by cpsmtpb-ews02.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 2 Sep 2013 10:52:02 +0200 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews26.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 2 Sep 2013 10:52:02 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Mon, 2 Sep 2013 10:52:01 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 6157CCA3E; Mon, 2 Sep 2013 10:52:01 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: mattia.rossi.mate@gmail.com, "Ian Lepore" Subject: Re: Alignment Fault 1 - still/again References: <5221BA13.5040309@gmail.com> <1377959570.1111.345.camel@revolution.hippie.lan> <52220126.8010607@gmail.com> <1377960460.1111.347.camel@revolution.hippie.lan> Date: Mon, 02 Sep 2013 10:52:01 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <1377960460.1111.347.camel@revolution.hippie.lan> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 02 Sep 2013 08:52:01.0816 (UTC) FILETIME=[B0D99180:01CEA7B9] X-RcptDomain: freebsd.org Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 08:52:10 -0000 On Sat, 31 Aug 2013 16:47:40 +0200, Ian Lepore wrote: > On Sat, 2013-08-31 at 16:43 +0200, Mattia Rossi wrote: >> > That LOR is harmless (at least, I've been seeing it for a while). >> Ah, good... didn't even think i could simply continue... >> Well.. back being stuck at "entropy harvesting interrupts ethernet >> point_to_point" without being able to ^C >> > >> > It's not correct that EABI only changes things for userspace -- quite >> > the opposite, you can't run a mismatched kernel and userspace (as the >> > init failure points out). >> Sorry, what I meant was: for me it only gets stuck when running >> userspace tools. >> With or without EABI the kernel (now) loads fine) >> > >> > I still can't get EABI to work on my dreamplug, every time I try I get >> > more confusing symptoms (the latest -- trying to view a manpage gave >> a >> > "too many symbols" error trying to launch man). >> > >> > >> I never get beyond "entropy harvesting: interrupts ethernet >> point_to_point" >> >> :( > > That's a bit strange, that everyone can ^C out of that hang except you. > You can get past it by editing /etc/rc.d/initrandom and commenting out > the df and ps commands (just comment out all the initrandom kickstart > stuff, it doesn't generate any real entropy anyway). > > -- Ian I can't ^C out of it either. I can only continue booting by commenting out the call to better_than_nothing(). Only after a boot to multi-user magically works (ones in a thousand times) I can ^C hanging programs. Ronald. From owner-freebsd-arm@FreeBSD.ORG Mon Sep 2 08:59:32 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9396825C; Mon, 2 Sep 2013 08:59:32 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EBD5B2966; Mon, 2 Sep 2013 08:59:31 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id e11so1474561bkh.11 for ; Mon, 02 Sep 2013 01:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5UxisP0adwLJp6R7Uxwx1XxnDzDGKVSyGwrm4QKIbOs=; b=wihssWyzE0u9ouIoaENRLB/XyzNGJcuujDc8bCmR8z+KO8I2bKbZnTTNQPaBPeQsag n6AfKm2+AbruAonWeMz0or9LpbvXI5vg5DxZ8pTvstAWGFHrdSo+nObqvm+iXR3dfys0 DHqcShtKyPd/w04QztbeWZv8TDthKLPquxbHkKgLkUjYA2kjeFOXSAhGTo2VfRrPUPGO oar+5VjNz1DhkGg9kXZSId8SOPikTtRwNko/BISXsiz2r4Ed3oqOBv6gdNvDuTn8CGRL 3UcvddFQFRLmfMN7UaYyO6lHgN7fptihUY4f3AgjOlawm3IT/2I5CExpeRumec+/8tgN YQGw== X-Received: by 10.204.234.5 with SMTP id ka5mr4773499bkb.5.1378112370094; Mon, 02 Sep 2013 01:59:30 -0700 (PDT) Received: from [192.168.0.108] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPSA id nv4sm1944756bkb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Sep 2013 01:59:29 -0700 (PDT) Message-ID: <5224536E.20801@gmail.com> Date: Mon, 02 Sep 2013 10:59:26 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ronald Klop Subject: Re: Alignment Fault 1 - still/again References: <5221BA13.5040309@gmail.com> <1377959570.1111.345.camel@revolution.hippie.lan> <52220126.8010607@gmail.com> <1377960460.1111.347.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 08:59:32 -0000 Am 02.09.2013 10:52, schrieb Ronald Klop: > On Sat, 31 Aug 2013 16:47:40 +0200, Ian Lepore wrote: > >> On Sat, 2013-08-31 at 16:43 +0200, Mattia Rossi wrote: >>> > That LOR is harmless (at least, I've been seeing it for a while). >>> Ah, good... didn't even think i could simply continue... >>> Well.. back being stuck at "entropy harvesting interrupts ethernet >>> point_to_point" without being able to ^C >>> > >>> > It's not correct that EABI only changes things for userspace -- quite >>> > the opposite, you can't run a mismatched kernel and userspace (as the >>> > init failure points out). >>> Sorry, what I meant was: for me it only gets stuck when running >>> userspace tools. >>> With or without EABI the kernel (now) loads fine) >>> > >>> > I still can't get EABI to work on my dreamplug, every time I try I >>> get >>> > more confusing symptoms (the latest -- trying to view a manpage >>> gave a >>> > "too many symbols" error trying to launch man). >>> > >>> > >>> I never get beyond "entropy harvesting: interrupts ethernet >>> point_to_point" >>> >>> :( >> >> That's a bit strange, that everyone can ^C out of that hang except you. >> You can get past it by editing /etc/rc.d/initrandom and commenting out >> the df and ps commands (just comment out all the initrandom kickstart >> stuff, it doesn't generate any real entropy anyway). >> >> -- Ian > > I can't ^C out of it either. I can only continue booting by commenting > out the call to better_than_nothing(). > Only after a boot to multi-user magically works (ones in a thousand > times) I can ^C hanging programs. > Well, that gives me hope that I might actually be able to boot into multi-user if I try often enough :-) Next step will be trying to debug df and ps if possible with some good old printf's. Maybe that gives us some clue about what's happening here. Cheers, Mat From owner-freebsd-arm@FreeBSD.ORG Mon Sep 2 11:06:42 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 00679FBB for ; Mon, 2 Sep 2013 11:06:41 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C87862398 for ; Mon, 2 Sep 2013 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r82B6fDG015955 for ; Mon, 2 Sep 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r82B6fdL015953 for freebsd-arm@FreeBSD.org; Mon, 2 Sep 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Sep 2013 11:06:41 GMT Message-Id: <201309021106.r82B6fdL015953@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 11:06:42 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/181220 arm make xdev for arm installation fails o arm/180080 arm Unmapped buffers on ARMv7 big-RAM boards o arm/179688 arm [patch] [rpi] serial console eats some characters at m o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177685 arm [kernel] [patch] Correct return type and usage of at91 o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/176424 arm Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODU o arm/175803 arm building xdev for arm failing o arm/175605 arm please fix build binutils-2.23.1 in raspberry pi o arm/174461 arm [patch] Fix off-by-one in arm9/arm10 cache maintenance o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on p arm/134338 arm [patch] Lock GPIO accesses on ixp425 30 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Sep 2 13:20:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D3D52999 for ; Mon, 2 Sep 2013 13:20:02 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D1502FCF for ; Mon, 2 Sep 2013 13:20:02 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r82DJQXF060664 for ; Mon, 2 Sep 2013 09:20:00 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <5224905E.8070701@m5p.com> Date: Mon, 02 Sep 2013 09:19:26 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: What's the recipe? References: <522229C0.5030504@m5p.com> <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Mon, 02 Sep 2013 09:20:00 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 13:20:02 -0000 On 09/01/13 09:50, Tim Kientzle wrote: > [...] > > Note that Crochet has > > SRCCONF=/dev/null > __MAKE_CONF=/dev/null > > by default. You can override those in your Crochet configuration file > if you wish. This was the missing piece of the puzzle for me. I now have an image that is in the process of compiling ports-mgmt/pkg, hopefully on the way to building CUPS, and that recognizes my Lexmark printer. Many, many thanks to all the people who got us this far! Even though it's documented right there in config.sh.sample, it was easy for me to skip this step, and of course I ended up with a clang build instead of a gcc build, and it wasn't close to being stable at all. I sincerely hope clang can catch up soon on the ARM. -- George From owner-freebsd-arm@FreeBSD.ORG Mon Sep 2 18:18:30 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 92FE82DB for ; Mon, 2 Sep 2013 18:18:30 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F0692839 for ; Mon, 2 Sep 2013 18:18:29 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r82IINv6080055; Mon, 2 Sep 2013 18:18:23 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id wcm8fp59gxqbpsg4kj9mferyws; Mon, 02 Sep 2013 18:18:22 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: What's the recipe? From: Tim Kientzle In-Reply-To: <0AC24F9A-7AE0-4E98-BC21-273FA097AE0F@grondar.org> Date: Mon, 2 Sep 2013 11:18:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <522229C0.5030504@m5p.com> <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> <0AC24F9A-7AE0-4E98-BC21-273FA097AE0F@grondar.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1508) Cc: Takeshi Taguchi , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 18:18:30 -0000 On Sep 2, 2013, at 12:30 AM, Mark R V Murray wrote: >=20 > CURRENT + crochet cannot build u-boot because it looks like the = antique CURRENT/GCC-xdev can't handle a couple of command-line options = that u-boot wants (-fstack-usage, the other is hiding), but if I remove = those it eventually fails with redefinitions of things like __packed, = __pure and so on (this is GCC "armv6-freebsd-gcc", not CLANG). This is very odd. I've been occupied elsewhere, so I haven't done any RPi builds recently, but I don't think anything has changed (in either the U-boot version used there or in CURRENT/GCC) since the last time I built. > I tried to hack up a u-boot port using the Beaglebone Black u-boot = port as an example; that needs devel/arm-eabi-gcc which fails because of = redefinition of some functions during the build. The BBB U-Boot port is badly broken for some reason and I have no idea why. (Seems to break at the point ubldr first calls into U-Boot.) I've been digging through it a little this weekend but have yet to isolate the issue. Hmmm=85 I haven't rebuilt devel/arm-eabi-gcc in a while; I wonder what broke that? Tim From owner-freebsd-arm@FreeBSD.ORG Tue Sep 3 07:49:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7621EB06 for ; Tue, 3 Sep 2013 07:49:01 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 39C4B2E96 for ; Tue, 3 Sep 2013 07:49:01 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VGlM7-0002MK-AS; Tue, 03 Sep 2013 08:48:57 +0100 Subject: Re: What's the recipe? Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6F954EB6-C49C-46B4-8626-E8B190BF9688"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: Date: Tue, 3 Sep 2013 08:48:46 +0100 Message-Id: <3FBA7FC0-D7AB-40CA-B003-88768CB1B70A@grondar.org> References: <522229C0.5030504@m5p.com> <20130901200726.ac7317a5f0ddfddcbed34484@gmail.com> <0AC24F9A-7AE0-4E98-BC21-273FA097AE0F@grondar.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: Takeshi Taguchi , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 07:49:01 -0000 --Apple-Mail=_6F954EB6-C49C-46B4-8626-E8B190BF9688 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 On 2 Sep 2013, at 19:18, Tim Kientzle wrote: > :-) M -- Mark R V Murray --Apple-Mail=_6F954EB6-C49C-46B4-8626-E8B190BF9688 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUiWUZd58vKOKE6LNAQpDXwQAnleCJw8BzNFrI7rKL2lSr5Yr6RTKEUhP skwROP/4SB7sIvITggCPOc8Yttn1HOjcI1DMyQYGXQHvheg5ilrvF16dT0T+dUBS oxf6PCF2ov/lr8n4j7VlR0O4KHGsvyj/3msjtyPoTXwMXXWAbPwwzIa66P6rSJvp 9eH/687Bi2U= =8HgK -----END PGP SIGNATURE----- --Apple-Mail=_6F954EB6-C49C-46B4-8626-E8B190BF9688-- From owner-freebsd-arm@FreeBSD.ORG Tue Sep 3 12:31:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7343DA3D for ; Tue, 3 Sep 2013 12:31:14 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B5E321F5 for ; Tue, 3 Sep 2013 12:31:14 +0000 (UTC) Received: from [192.168.1.6] (p5481B468.dip0.t-ipconnect.de [84.129.180.104]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 943E11C0C0BD8 for ; Tue, 3 Sep 2013 14:31:11 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: A simple question about C... Message-Id: Date: Tue, 3 Sep 2013 14:31:11 +0200 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 12:31:14 -0000 Dear all, I'm trying to get a C program (packetdrill) running FreeBSD r254973 on a Raspberry Pi. Since tests are failing, I wrote the little C program: #include #include #include int main(void) { uint8_t byte[] =3D {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b}; uint32_t i, n, *p; for (i =3D 0; i <=3D 8; i++) { p =3D (uint32_t *)(byte + i); memcpy(&n, byte + i, sizeof(uint32_t)); printf("p =3D %p, *p =3D %08x, n =3D %08x.\n", (void = *)p, *p, n); } return (0); } It produces the following output: p =3D 0xbfffec48, *p =3D 03020100, n =3D 03020100. p =3D 0xbfffec49, *p =3D 00030201, n =3D 04030201. p =3D 0xbfffec4a, *p =3D 01000302, n =3D 05040302. p =3D 0xbfffec4b, *p =3D 02010003, n =3D 06050403. p =3D 0xbfffec4c, *p =3D 07060504, n =3D 07060504. p =3D 0xbfffec4d, *p =3D 04070605, n =3D 08070605. p =3D 0xbfffec4e, *p =3D 05040706, n =3D 09080706. p =3D 0xbfffec4f, *p =3D 06050407, n =3D 0a090807. p =3D 0xbfffec50, *p =3D 0b0a0908, n =3D 0b0a0908. So everything is fine when reading the 4 byte long uint32_t on a 4-byte = aligned address. Results are strange (at least for me), when the address is not = 4-byte aligned. There is no difference between clang and gcc. Can I only = dereference properly aligned pointers? Is the above expected or is it a bug in the = compiler? Best regards Michael= From owner-freebsd-arm@FreeBSD.ORG Tue Sep 3 12:51:29 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 577942F8; Tue, 3 Sep 2013 12:51:29 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2D9352416; Tue, 3 Sep 2013 12:51:28 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VGq4o-000FCz-MW; Tue, 03 Sep 2013 12:51:22 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r83CpJxt068579; Tue, 3 Sep 2013 06:51:19 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+ZckPwHiJFgEEoUFJwSyeo Subject: Re: A simple question about C... From: Ian Lepore To: Michael Tuexen In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Sep 2013 06:51:19 -0600 Message-ID: <1378212679.1111.366.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 12:51:29 -0000 On Tue, 2013-09-03 at 14:31 +0200, Michael Tuexen wrote: > Dear all, > > I'm trying to get a C program (packetdrill) running FreeBSD r254973 > on a Raspberry Pi. > Since tests are failing, I wrote the little C program: > > #include > #include > #include > > int > main(void) > { > uint8_t byte[] = {0x00, 0x01, 0x02, 0x03, > 0x04, 0x05, 0x06, 0x07, > 0x08, 0x09, 0x0a, 0x0b}; > uint32_t i, n, *p; > > for (i = 0; i <= 8; i++) { > p = (uint32_t *)(byte + i); > memcpy(&n, byte + i, sizeof(uint32_t)); > printf("p = %p, *p = %08x, n = %08x.\n", (void *)p, *p, n); > } > return (0); > } > > It produces the following output: > > p = 0xbfffec48, *p = 03020100, n = 03020100. > p = 0xbfffec49, *p = 00030201, n = 04030201. > p = 0xbfffec4a, *p = 01000302, n = 05040302. > p = 0xbfffec4b, *p = 02010003, n = 06050403. > p = 0xbfffec4c, *p = 07060504, n = 07060504. > p = 0xbfffec4d, *p = 04070605, n = 08070605. > p = 0xbfffec4e, *p = 05040706, n = 09080706. > p = 0xbfffec4f, *p = 06050407, n = 0a090807. > p = 0xbfffec50, *p = 0b0a0908, n = 0b0a0908. > > So everything is fine when reading the 4 byte long uint32_t on a 4-byte aligned > address. Results are strange (at least for me), when the address is not 4-byte > aligned. There is no difference between clang and gcc. Can I only dereference > properly aligned pointers? Is the above expected or is it a bug in the compiler? > > Best regards > Michael Yes, you can only safely dereference pointers aligned to the size of the dereference (2, 4, 8 bytes). On some ARM platforms a misaligned reference leads to alignment fault, on others the data is rotated in some predefined way, and on some it's just "undefined behavior." There are functions in endian.h to help with the alignment, in particular the leNNdec() and leNNenc() functions are designed to be alignment-agnostic. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Sep 3 13:37:30 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 06328185; Tue, 3 Sep 2013 13:37:30 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E6252CC4; Tue, 3 Sep 2013 13:37:29 +0000 (UTC) Received: from [192.168.1.6] (p5481ADA8.dip0.t-ipconnect.de [84.129.173.168]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B99361C0C0BF8; Tue, 3 Sep 2013 15:37:27 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: A simple question about C... From: Michael Tuexen In-Reply-To: <1378212679.1111.366.camel@revolution.hippie.lan> Date: Tue, 3 Sep 2013 15:37:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1378212679.1111.366.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 13:37:30 -0000 On Sep 3, 2013, at 2:51 PM, Ian Lepore wrote: > On Tue, 2013-09-03 at 14:31 +0200, Michael Tuexen wrote: >> Dear all, >>=20 >> I'm trying to get a C program (packetdrill) running FreeBSD r254973 >> on a Raspberry Pi. >> Since tests are failing, I wrote the little C program: >>=20 >> #include >> #include >> #include >>=20 >> int >> main(void) >> { >> uint8_t byte[] =3D {0x00, 0x01, 0x02, 0x03, >> 0x04, 0x05, 0x06, 0x07, >> 0x08, 0x09, 0x0a, 0x0b}; >> uint32_t i, n, *p; >>=20 >> for (i =3D 0; i <=3D 8; i++) { >> p =3D (uint32_t *)(byte + i); >> memcpy(&n, byte + i, sizeof(uint32_t)); >> printf("p =3D %p, *p =3D %08x, n =3D %08x.\n", (void = *)p, *p, n); >> } >> return (0); >> } >>=20 >> It produces the following output: >>=20 >> p =3D 0xbfffec48, *p =3D 03020100, n =3D 03020100. >> p =3D 0xbfffec49, *p =3D 00030201, n =3D 04030201. >> p =3D 0xbfffec4a, *p =3D 01000302, n =3D 05040302. >> p =3D 0xbfffec4b, *p =3D 02010003, n =3D 06050403. >> p =3D 0xbfffec4c, *p =3D 07060504, n =3D 07060504. >> p =3D 0xbfffec4d, *p =3D 04070605, n =3D 08070605. >> p =3D 0xbfffec4e, *p =3D 05040706, n =3D 09080706. >> p =3D 0xbfffec4f, *p =3D 06050407, n =3D 0a090807. >> p =3D 0xbfffec50, *p =3D 0b0a0908, n =3D 0b0a0908. >>=20 >> So everything is fine when reading the 4 byte long uint32_t on a = 4-byte aligned >> address. Results are strange (at least for me), when the address is = not 4-byte >> aligned. There is no difference between clang and gcc. Can I only = dereference >> properly aligned pointers? Is the above expected or is it a bug in = the compiler? >>=20 >> Best regards >> Michael >=20 > Yes, you can only safely dereference pointers aligned to the size of = the > dereference (2, 4, 8 bytes). On some ARM platforms a misaligned > reference leads to alignment fault, on others the data is rotated in > some predefined way, and on some it's just "undefined behavior." >=20 > There are functions in endian.h to help with the alignment, in > particular the leNNdec() and leNNenc() functions are designed to be > alignment-agnostic. OK. Thanks for the information. This means the packetdrill source code has to be patched to work correctly on ARM... Need to find all the = places where they access stuff in a non-aligned way. Best regards Michael >=20 > -- Ian >=20 >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Tue Sep 3 14:19:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 35E46A22; Tue, 3 Sep 2013 14:19:09 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C1C5B201C; Tue, 3 Sep 2013 14:19:08 +0000 (UTC) Received: by mail-vb0-f52.google.com with SMTP id f12so3840164vbg.39 for ; Tue, 03 Sep 2013 07:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8gPdn8i94IJ+H9vwn/kY6bNenX/Rf0MoGQyMWuRmaew=; b=Jd7qMSwwpI+Ri462oPC8X8arKMFMtsvXvz/7M9YhcjMFYyuVCYBbmqRyheDUUKPm3x Z1oN5nStJqyFlv0AkKyKQkM+rAARVAjiiFU5oYzz6J85dyhjgVDB0rQNSyccin3r1Kd3 XEIitrPabe//5lsK04L/OfhlazXDB80ydEz4G52EWyUwqPCYdtxgAnttbqdHD6eTCN7N Zm1VXIGjnmNozNiF0IENo18oN3aWwkXOYst1MTgF7MBSATF1HyDR6pQiHwVoIbwaxJi0 G+TVt7vGXxqUkIH1pJUL+asV5Kw0ojCEhcUxHh1v5VdqdP6Jpnj4gQNE350f2icmjNq3 aEfQ== MIME-Version: 1.0 X-Received: by 10.58.235.69 with SMTP id uk5mr28776563vec.17.1378217947776; Tue, 03 Sep 2013 07:19:07 -0700 (PDT) Received: by 10.220.122.1 with HTTP; Tue, 3 Sep 2013 07:19:07 -0700 (PDT) In-Reply-To: <5224333C.8070305@martinlaabs.de> References: <5224333C.8070305@martinlaabs.de> Date: Tue, 3 Sep 2013 10:19:07 -0400 Message-ID: Subject: Re: No UDP/TCP IPv6 connectivity (only) to router using gif interface - maybe ARM related From: Zaphod Beeblebrox To: Martin Laabs Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , freebsd-arm , freebsd-current X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 14:19:09 -0000 Whether you feel it right, or not, net.inet.ip.forwarding must be 1 for gif to work (even for IPv6). On Mon, Sep 2, 2013 at 2:42 AM, Martin Laabs wrote: > Hi, > > I tried to set up my raspberry PI as an ipv6 router. As a tunnel broker I > use sixxs. Now I observed an interesting behavior: > > Every host from my network can reach the ipv6 world. The ipv6 world can > also reach every host in my network. However - the router itself is unable > to make udp or tcp connection to the "world" and is also unable to accept > connections form the "world" > ICMP however works properly. > I had a look to the tcpdump and when trying to connect i.e. to > www.kame.net > the rasperry router sends a syn packet and get a syn/ack packet back. The > rest of the handshake is missing. > I tried also some udp with netcat (nc -6 -u -l 5555 on the server and nc -6 > -u 5555 on the client) > This works great for internal (ethernet) traffic but when the data should > go through the tunnel if fails. > > The last test is maybe the most significant to describe the bug: > > Start netcat to listen for UDP packages on an external host: > > nc -6 -u -l 5555 > > Connect from the RPI-Router to that host > > nc -6 -u 2001:4dd0:xxxx:xxxx::2 5555 > > Now it is possible to send data from the RPI router to the external host > but the opposite direction does not work. Tcpdump however shows that the > udp package arrives but it is not "forwarded" to the application. > So for me it seems to be a problem with the handling of the receiving data > in the gif interface. > > This behavior is independent from net.inet6.ip6.forwarding or > net.inet6.ip6.redirect status. > > The router system: FreeBSD raspberry-pi.xxx 10.0-CURRENT FreeBSD > 10.0-CURRENT #2 r254984 > > Best regards, > Martin Laabs > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Tue Sep 3 18:07:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B7369B4B; Tue, 3 Sep 2013 18:07:56 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay03.alfahosting-server.de (relay03.alfahosting-server.de [109.237.142.239]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 712952734; Tue, 3 Sep 2013 18:07:56 +0000 (UTC) Received: by relay03.alfahosting-server.de (Postfix, from userid 1001) id 4D4B932C0B96; Tue, 3 Sep 2013 20:07:48 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay03.alfahosting-server.de (Postfix) with ESMTPS id 141A232C0BB1; Tue, 3 Sep 2013 20:07:33 +0200 (CEST) Received: from desktop-01.martinlaabs.de (p54B30B56.dip0.t-ipconnect.de [84.179.11.86]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id AF108515C050; Tue, 3 Sep 2013 20:07:32 +0200 (CEST) Message-ID: <52262563.6020407@martinlaabs.de> Date: Tue, 03 Sep 2013 20:07:31 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: FreeBSD Net Subject: Re: No UDP/TCP IPv6 connectivity (only) to router using gif interface - maybe ARM related References: <5224333C.8070305@martinlaabs.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17800/Tue Sep 3 18:37:24 2013 Cc: freebsd-arm , freebsd-current X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 18:07:56 -0000 Hi , > Whether you feel it right, or not, net.inet.ip.forwarding must be 1 for gif > to work (even for IPv6). This is a unintuitive behavior. But fortunately this solve this problem. I suggest adding setting this sysctl if ipv6_gateway_enable is enabled in the rc.conf. Best regards, Martin Laabs From owner-freebsd-arm@FreeBSD.ORG Tue Sep 3 19:39:38 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A41D12E8 for ; Tue, 3 Sep 2013 19:39:38 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7FA2822E8 for ; Tue, 3 Sep 2013 19:39:38 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id lj1so6891807pab.15 for ; Tue, 03 Sep 2013 12:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=K4yoWKuAZqRdp57xWmVdqGKOkKB3lnlDH7QmddlUNdE=; b=ovkUVwsVnqwCOYanGYEaD5Xdisi16UFcjryHfdfo7V7iiH62UeJkxpAOYPG9Iy7oaP qwjJ59U7W7ils6dS8xG9a2EmaCm5rVi4kXiykEbefSDpVpBOvm80CaSvUlkLMzdCGhxi ZgJxm3/E+GmVClKT3jVClMI7JJN8cZLtKNpvQv9hOIzGcgzAk9DnHdZUSGB+BSUAiJb0 rqMumWTHAsDzeJy+q1PkdSyJxiZSA83R8WSXhrUJALsX1OcI24Z+l0s+p30nagfQATQ2 0VWtvtUn/BKSR04Yuvbd1RU9fmhWMd3HazSDav01f9NxRBGz7R1tKm9muFcmUWkevR7t ZO9g== MIME-Version: 1.0 X-Received: by 10.66.156.199 with SMTP id wg7mr33480194pab.81.1378237177925; Tue, 03 Sep 2013 12:39:37 -0700 (PDT) Received: by 10.70.81.97 with HTTP; Tue, 3 Sep 2013 12:39:37 -0700 (PDT) Date: Tue, 3 Sep 2013 23:39:37 +0400 Message-ID: Subject: recend freebsd-current doesn't boot in RPi with "Translation Fault" error From: Subbsd To: freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 19:39:38 -0000 Hello, I decided to upgrade my Raspberry Pi with running on FreeBSD-current on the July version to latest version of FreeBSD and got error after going to multiuser mode. FreeBSD revision: r255183 Here is screenshot: http://prntscr.com/1p5sab (sorry for quality) Looks like this error on fsck stage (ive use default rc.conf without any personal fsck-related params) and last message: [ thread pid 11 tid 100019 ] Stopped at bcm_sdhci_dma_intr+0x44: ldr r0, [r0, #0x024] can i help with something more to find the problems? From owner-freebsd-arm@FreeBSD.ORG Tue Sep 3 21:25:31 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5DF862F5 for ; Tue, 3 Sep 2013 21:25:31 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3295D2B3B for ; Tue, 3 Sep 2013 21:25:31 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VGy6G-000Hrk-0G; Tue, 03 Sep 2013 21:25:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r83LPL0I068960; Tue, 3 Sep 2013 15:25:21 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18ChPZcHMXZTUNSi6QuKcxK Subject: Re: recend freebsd-current doesn't boot in RPi with "Translation Fault" error From: Ian Lepore To: Subbsd In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Sep 2013 15:25:20 -0600 Message-ID: <1378243520.1111.376.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 21:25:31 -0000 On Tue, 2013-09-03 at 23:39 +0400, Subbsd wrote: > Hello, > > I decided to upgrade my Raspberry Pi with running on FreeBSD-current on the > July version to latest version of FreeBSD and got error after going to > multiuser mode. > > FreeBSD revision: r255183 > Here is screenshot: http://prntscr.com/1p5sab (sorry for quality) > > Looks like this error on fsck stage (ive use default rc.conf without any > personal fsck-related params) and last message: > > [ thread pid 11 tid 100019 ] > Stopped at bcm_sdhci_dma_intr+0x44: ldr r0, [r0, #0x024] > > can i help with something more to find the problems? > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" The abort location seems to be within bcm_sdhci_dma_intr(), and appears to have happened because a DMA interrupt occurred when there was no active sdcard command. It's hard to see how that could happen just from looking at the code. Does this happen repeatedly, or was it a one-time thing? -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Sep 4 10:19:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B98FB142; Wed, 4 Sep 2013 10:19:02 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8F0DB25E0; Wed, 4 Sep 2013 10:19:02 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id rq2so101677pbb.19 for ; Wed, 04 Sep 2013 03:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/Pnou5NkpN0CHS+cabci6alCXUrZGsdupInOQ9ZexHE=; b=pf9jSTmMruiLAl+a+0krtdc2vDCbIfaHKzqzdWkDhekBp4Uiy4GKh3Tm5IqLEjNcQX 9/ACzli4JOekNDLneSHSGXKteiSv5FKkL63nuwR8II8q5uDCPQinLl1X7JRKTeLpzlAU qGF67bDYnBfViEdSXbII1PE07Njn/HdQ+a8Sy/q+LqmffA1A+pmCblqodsfKXrRmmTFr LXbS+xjPiD6R47G92yejbg8uvHLuFUn/vc/prvIuXDXI5RRoBV356sTN03gdhhAp5m3G XkKDXbeAoStkbz/76B7693dMTaUDZMVv9xUduFfhnUrlBRbzPfiLdzlORsbwT5ILOwLy I1+Q== MIME-Version: 1.0 X-Received: by 10.68.130.131 with SMTP id oe3mr1205324pbb.186.1378289942175; Wed, 04 Sep 2013 03:19:02 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Wed, 4 Sep 2013 03:19:02 -0700 (PDT) In-Reply-To: <1378243520.1111.376.camel@revolution.hippie.lan> References: <1378243520.1111.376.camel@revolution.hippie.lan> Date: Wed, 4 Sep 2013 14:19:02 +0400 Message-ID: Subject: Re: recend freebsd-current doesn't boot in RPi with "Translation Fault" error From: Subbsd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 10:19:02 -0000 Its repeatedly error. Image was created by https://github.com/kientzle/crochet-freebsd.git ( previous working build was made by him ) On Wed, Sep 4, 2013 at 1:25 AM, Ian Lepore wrote: > On Tue, 2013-09-03 at 23:39 +0400, Subbsd wrote: > > Hello, > > > > I decided to upgrade my Raspberry Pi with running on FreeBSD-current on > the > > July version to latest version of FreeBSD and got error after going to > > multiuser mode. > > > > FreeBSD revision: r255183 > > Here is screenshot: http://prntscr.com/1p5sab (sorry for quality) > > > > Looks like this error on fsck stage (ive use default rc.conf without any > > personal fsck-related params) and last message: > > > > [ thread pid 11 tid 100019 ] > > Stopped at bcm_sdhci_dma_intr+0x44: ldr r0, [r0, #0x024] > > > > can i help with something more to find the problems? > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > The abort location seems to be within bcm_sdhci_dma_intr(), and appears > to have happened because a DMA interrupt occurred when there was no > active sdcard command. It's hard to see how that could happen just from > looking at the code. > > Does this happen repeatedly, or was it a one-time thing? > > -- Ian > > > From owner-freebsd-arm@FreeBSD.ORG Wed Sep 4 12:51:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 267A9AF7 for ; Wed, 4 Sep 2013 12:51:56 +0000 (UTC) (envelope-from taguchi.ch@gmail.com) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ECAB32107 for ; Wed, 4 Sep 2013 12:51:55 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id mc17so251798pbc.18 for ; Wed, 04 Sep 2013 05:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=qk5VV6BZ/kz3RBBnLOHjhpQFqqneoecmqZ2zLtr2f3U=; b=LZLDr04a3C7CX7Krfb/LSoHZsMrNZURjK4wHqCOPNrXf/0x16DYohr4fw0iC4WEk7L dT4hDDpLDCBb7tvWYkcaz/leW+b3Nj5UUGGv3dwD3v/p4Ce6Vpls3tgZG6/r8r1m797e uexM60ZCCvY/7YE0TjIPylohc0hY/Ei3UPNuwP1bXRPLp0tbyTx4k34mIhGdvjnSmtgo 9+TrxSXlqDciKf2g6hffNLCg2vDOT7+sQXfHrwuV3bUB7YA5zr/Sfvsb72WcakZq+SN3 b2PpJ8fs5kopyrhCkwQZ29Pvf9dQWrRpK2Go3yWl2rsDzRKg5dcyMxARv9/TNveA1ZGI CjhQ== X-Received: by 10.66.234.131 with SMTP id ue3mr3103161pac.35.1378299115604; Wed, 04 Sep 2013 05:51:55 -0700 (PDT) Received: from arty (48.178.30.125.dy.iij4u.or.jp. [125.30.178.48]) by mx.google.com with ESMTPSA id zi1sm28657995pbb.28.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Sep 2013 05:51:54 -0700 (PDT) Date: Wed, 4 Sep 2013 21:51:52 +0900 From: Chie Taguchi To: Tim Kientzle Subject: Re: building document of Xorg Message-Id: <20130904215152.13dbc6edba2cef363779a3e9@gmail.com> In-Reply-To: <3D90F8CB-14A3-4E9F-AE5A-E970E76AEA5F@gmail.com> References: <20130818101242.b3801b1b97dbe42cb905653c@gmail.com> <0D701E6E-8DE0-45DE-854B-133FCCC35C79@iaelu.net> <20130818212508.beddbf0e04a2f5f9a3a699a1@gmail.com> <20130819220401.11acd306a94e60a87d6424c9@gmail.com> <3D90F8CB-14A3-4E9F-AE5A-E970E76AEA5F@gmail.com> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Wed__4_Sep_2013_21_51_52_+0900_kNe/DZIFXrepPVZU" Cc: Guillaume Bibaut , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 12:51:56 -0000 This is a multi-part message in MIME format. --Multipart=_Wed__4_Sep_2013_21_51_52_+0900_kNe/DZIFXrepPVZU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit i make another patch for libgcrypt, fix inline assembler error at clang. it seems a little faster than gcc.:) i will send PR this patch. thanks. C.Taguchi --Multipart=_Wed__4_Sep_2013_21_51_52_+0900_kNe/DZIFXrepPVZU Content-Type: text/plain; name="patch-libgcrypt.txt" Content-Disposition: attachment; filename="patch-libgcrypt.txt" Content-Transfer-Encoding: 7bit diff -urN libgcrypt.orig/Makefile libgcrypt/Makefile --- libgcrypt.orig/Makefile 2013-09-03 21:38:02.000000000 +0900 +++ libgcrypt/Makefile 2013-09-03 21:39:46.000000000 +0900 @@ -36,9 +36,6 @@ BROKEN= will not compile. See pr ports/166388 .endif -.elif ${ARCH} == "armv6" -USE_GCC=4.2+ - .elif ${ARCH} == "i386" .if (${OSVERSION} < 900033) CONFIGURE_ARGS+= --disable-aesni-support diff -urN libgcrypt.orig/files/patch-mpi-longlong.h libgcrypt/files/patch-mpi-longlong.h --- libgcrypt.orig/files/patch-mpi-longlong.h 2013-09-03 21:35:50.000000000 +0900 +++ libgcrypt/files/patch-mpi-longlong.h 2013-09-03 20:51:48.000000000 +0900 @@ -1,5 +1,42 @@ ---- ./mpi/longlong.h.orig 2010-02-22 19:04:43.000000000 +0900 -+++ ./mpi/longlong.h 2010-11-01 18:25:34.000000000 +0900 +--- ./mpi/longlong.h.orig 2013-09-03 18:52:04.000000000 +0900 ++++ ./mpi/longlong.h 2013-09-03 20:46:40.000000000 +0900 +@@ -188,8 +188,8 @@ + #define add_ssaaaa(sh, sl, ah, al, bh, bl) \ + __asm__ ("adds %1, %4, %5\n" \ + "adc %0, %2, %3" \ +- : "=r" ((USItype)(sh)), \ +- "=&r" ((USItype)(sl)) \ ++ : "=r" (sh), \ ++ "=&r" (sl) \ + : "%r" ((USItype)(ah)), \ + "rI" ((USItype)(bh)), \ + "%r" ((USItype)(al)), \ +@@ -197,8 +197,8 @@ + #define sub_ddmmss(sh, sl, ah, al, bh, bl) \ + __asm__ ("subs %1, %4, %5\n" \ + "sbc %0, %2, %3" \ +- : "=r" ((USItype)(sh)), \ +- "=&r" ((USItype)(sl)) \ ++ : "=r" (sh), \ ++ "=&r" (sl) \ + : "r" ((USItype)(ah)), \ + "rI" ((USItype)(bh)), \ + "r" ((USItype)(al)), \ +@@ -225,10 +225,10 @@ + : "r0", "r1", "r2") + #else + #define umul_ppmm(xh, xl, a, b) \ +- __asm__ ("%@ Inlined umul_ppmm\n" \ +- "umull %r1, %r0, %r2, %r3" \ +- : "=&r" ((USItype)(xh)), \ +- "=r" ((USItype)(xl)) \ ++ __asm__ ("@ Inlined umul_ppmm\n" \ ++ "umull %1, %0, %2, %3" \ ++ : "=&r" (xh), \ ++ "=r" (xl) \ + : "r" ((USItype)(a)), \ + "r" ((USItype)(b)) \ + : "r0", "r1") @@ -437,8 +437,8 @@ #define add_ssaaaa(sh, sl, ah, al, bh, bl) \ __asm__ ("addl %5,%1\n" \ --Multipart=_Wed__4_Sep_2013_21_51_52_+0900_kNe/DZIFXrepPVZU Content-Type: text/plain; name="libgcrypt-benchmark-clang-asm.txt" Content-Disposition: attachment; filename="libgcrypt-benchmark-clang-asm.txt" Content-Transfer-Encoding: 7bit MD5 234375ms 546875ms 3046875ms 468750ms 234375ms SHA1 468750ms 703125ms 3359375ms 703125ms 468750ms RIPEMD160 390625ms 703125ms 3281250ms 703125ms 390625ms TIGER192 703125ms 1171875ms 3828125ms 937500ms 859375ms SHA256 781250ms 1328125ms 4062500ms 1015625ms 859375ms SHA384 1328125ms 2109375ms 4687500ms 1562500ms 1250000ms SHA512 1328125ms 2109375ms 4687500ms 1562500ms 1328125ms SHA224 781250ms 1328125ms 4062500ms 1015625ms 859375ms MD4 78125ms 468750ms 2968750ms 468750ms 234375ms CRC32 156250ms 156250ms 2500000ms 390625ms 156250ms CRC32RFC1510 156250ms 156250ms 2500000ms 390625ms 234375ms CRC24RFC2440 625000ms 546875ms 2890625ms 781250ms 703125ms WHIRLPOOL 5937500ms 6328125ms 9453125ms 6250000ms 6093750ms TIGER 781250ms 1093750ms 3828125ms 1015625ms 781250ms TIGER2 781250ms 1093750ms 3828125ms 1015625ms 859375ms ECB/Stream CBC CFB OFB CTR --------------- --------------- --------------- --------------- --------------- IDEA 2109375ms 2187500ms 2421875ms 2500000ms 2265625ms 2265625ms 2343750ms 2343750ms 4062500ms 3984375ms 3DES 5000000ms 5000000ms 5312500ms 5390625ms 5156250ms 5156250ms 5234375ms 5156250ms 6953125ms 6953125ms CAST5 1562500ms 1562500ms 1796875ms 2031250ms 1640625ms 1718750ms 1875000ms 1718750ms 3437500ms 3515625ms BLOWFISH 1718750ms 1718750ms 2031250ms 2109375ms 1875000ms 1875000ms 2031250ms 1953125ms 3671875ms 3671875ms AES 1406250ms 1328125ms 1250000ms 1250000ms 1250000ms 1250000ms 1640625ms 1562500ms 1250000ms 1250000ms AES192 1640625ms 1484375ms 1562500ms 1406250ms 1406250ms 1484375ms 1796875ms 1796875ms 1484375ms 1406250ms AES256 1796875ms 1640625ms 1718750ms 1640625ms 1562500ms 1640625ms 2031250ms 2031250ms 1640625ms 1640625ms TWOFISH 1328125ms 1328125ms 1562500ms 1562500ms 1484375ms 1484375ms 1562500ms 1562500ms 3125000ms 3046875ms ARCFOUR 390625ms 468750ms DES 2265625ms 2187500ms 2578125ms 2578125ms 2421875ms 2421875ms 2500000ms 2421875ms 4140625ms 4140625ms TWOFISH128 1406250ms 1328125ms 1562500ms 1640625ms 1484375ms 1484375ms 1562500ms 1562500ms 3125000ms 3046875ms SERPENT128 1718750ms 1562500ms 1875000ms 1875000ms 1718750ms 1796875ms 1875000ms 1796875ms 3437500ms 3437500ms SERPENT192 1562500ms 1562500ms 1875000ms 1875000ms 1796875ms 1796875ms 1875000ms 1875000ms 3437500ms 3437500ms SERPENT256 1640625ms 1562500ms 1875000ms 1875000ms 1796875ms 1796875ms 1875000ms 1875000ms 3437500ms 3437500ms RFC2268_40 1718750ms 2187500ms 2031250ms 2500000ms 1875000ms 1796875ms 2031250ms 1875000ms 3593750ms 3593750ms SEED 1328125ms 1406250ms 1562500ms 1718750ms 1484375ms 1484375ms 1562500ms 1406250ms 3203125ms 3125000ms CAMELLIA128 2734375ms 2812500ms 3046875ms 3203125ms 2812500ms 2968750ms 2968750ms 2968750ms 4531250ms 4687500ms CAMELLIA192 3046875ms 3125000ms 3281250ms 3359375ms 3203125ms 3203125ms 3203125ms 3203125ms 4843750ms 4843750ms CAMELLIA256 3046875ms 3125000ms 3281250ms 3359375ms 3203125ms 3125000ms 3203125ms 3203125ms 4843750ms 4843750ms Algorithm generate 100*sign 100*verify ------------------------------------------------ RSA 1024 bit 7421875ms 77968750ms 2343750ms RSA 2048 bit 29296875ms 426250000ms 5781250ms RSA 3072 bit 949531250ms 1191640625ms 10781250ms RSA 4096 bit 926093750ms 2526015625ms 17343750ms DSA 1024/160 - 38203125ms 40546875ms DSA 2048/224 - 143593750ms 139453125ms DSA 3072/256 - 314218750ms 283593750ms ECDSA 192 bit 3671875ms 95000000ms 171718750ms ECDSA 224 bit 4296875ms 112187500ms 205546875ms ECDSA 256 bit 5234375ms 132109375ms 246718750ms ECDSA 384 bit 10625000ms 262343750ms 488046875ms ECDSA 521 bit 24062500ms 612812500ms 1183984375ms powm 2968750ms 7890625ms 21484375ms random 468750ms 312500ms --Multipart=_Wed__4_Sep_2013_21_51_52_+0900_kNe/DZIFXrepPVZU-- From owner-freebsd-arm@FreeBSD.ORG Wed Sep 4 16:59:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ECF1CBD4; Wed, 4 Sep 2013 16:59:14 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C15C422FE; Wed, 4 Sep 2013 16:59:14 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id xb4so554411pbc.8 for ; Wed, 04 Sep 2013 09:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=239e92XdJa78KGEJbMBab4rpB6i2LPVUBDeKsq1lRgE=; b=Vjc+wPZ5AAuipJ7J67qTPTxuS0luclsQiPGiG0Hb5O/iDwQD+pweHeISZYpyuhBTEf hb0Wqyr52NnVotPN7yOoyCdiuVKuAl7GxMGsFwPwnaIAXyteEJTkMYzu4tyGPM22MlWJ rdeIDG9KcNW0ZEv3NfnsjVwgzjwaC88r2alP7gTXGR2MxK3IAL8V26sLjFjw/nhQzkcy sX8x7+B2auB/5Ls0oabKoEk4TsD6q+cWv7/InWQ70dF2si/kqRQvU/Gsf/pKWNXc9ziM RM4DJihznV5YSahZiNqoMTyZ+KKVkM61+9bC/pGRFgqI8BkSwc0Acd6sDCail3Qpvh2D fErQ== MIME-Version: 1.0 X-Received: by 10.68.178.197 with SMTP id da5mr4421066pbc.28.1378313954467; Wed, 04 Sep 2013 09:59:14 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Wed, 4 Sep 2013 09:59:14 -0700 (PDT) In-Reply-To: References: <1378243520.1111.376.camel@revolution.hippie.lan> Date: Wed, 4 Sep 2013 20:59:14 +0400 Message-ID: Subject: Re: recend freebsd-current doesn't boot in RPi with "Translation Fault" error From: Subbsd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 16:59:15 -0000 On Wed, Sep 4, 2013 at 2:19 PM, Subbsd wrote: > Its repeatedly error. Image was created by > https://github.com/kientzle/crochet-freebsd.git ( previous working build > was made by him ) > > > update: this panic arises at the stage of working /etc/rc.d/root. In single mode this panic occurs on any write operation, for example re-mount root in RW, tunefs -j disable/enable and so on.. From owner-freebsd-arm@FreeBSD.ORG Thu Sep 5 10:59:13 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75715E49 for ; Thu, 5 Sep 2013 10:59:13 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews05.kpnxchange.com (cpsmtpb-ews05.kpnxchange.com [213.75.39.8]) by mx1.freebsd.org (Postfix) with ESMTP id D90F123FB for ; Thu, 5 Sep 2013 10:59:12 +0000 (UTC) Received: from cpsps-ews08.kpnxchange.com ([10.94.84.175]) by cpsmtpb-ews05.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 5 Sep 2013 12:59:09 +0200 Received: from CPSMTPM-TLF102.kpnxchange.com ([195.121.3.5]) by cpsps-ews08.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 5 Sep 2013 12:59:09 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF102.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 5 Sep 2013 12:59:09 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id B43041604B for ; Thu, 5 Sep 2013 12:59:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <6046B66D-5F4C-4E8D-923A-3E26DED5DD8F@bsdimp.com> Date: Thu, 05 Sep 2013 12:59:08 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 05 Sep 2013 10:59:09.0200 (UTC) FILETIME=[F25D4100:01CEAA26] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 10:59:13 -0000 On Fri, 30 Aug 2013 14:04:52 +0200, Ronald Klop = wrote: > On Thu, 29 Aug 2013 19:38:44 +0200, Adrian Chadd = = > wrote: > >> On 29 August 2013 10:25, Warner Losh wrote: >> >>> >>> On Aug 29, 2013, at 11:17 AM, Adrian Chadd wrote: >>> >>> > (top posting so one doesn't have to scroll down to the bottom to r= ead >>> > this..) >>> > >>> > ARM people - is this useful? This looks to me like the serial = >>> console IO >>> > path to enter ddb. I guess uart_bus_attach() is the wrong function= = >>> name >>> and >>> > the real function is something inside the uart RX path >>> >>> This stack trace is poo. These routines long ago finished running, a= nd >>> certainly wouldn't be running in the context of df. >> >> >> They'd be running if he hit the magic "please sir, may I enter ddb?" >> routine. The attach function is just ddb getting the symbol lookup = >> wrong - >> you'd have to run (arm) addr2line to get the PC -> symbol. >> >> But the wchan shows its running, not that it's spun in the kernel. So= , >> either it's running and doign ridiculous amounts of syscalls in some = = >> kind >> of loop, or it's actually spinning in userland. >> >> Re jmg - yeah, maybe running it in userland gdb will shed more light.= > > Hi, it is about the df in this line in /etc/rc.d/initrandom. > > ( kenv; dmesg; df -ib; ps -fauxww; date; sysctl -a ) \ > | dd of=3D/dev/random bs=3D8k 2>/dev/null > > If I (only) remove the df it waits on the ps. If I remove the ps it = > waits on sysctl. Maybe interesting information. > > Because it is still running the boot scripts I don't know how to attac= h = > gdb. Any pointer how to do that? > > ... > > Oh wow, for some lucky reason I add rc_info=3D"YES" to rc.conf and whe= n I = > rebooted it did an fsck of all filesystems and it booted into multiuse= r. = > I am now logged in and see the same as Ian. Top does not work. Df hang= s. = > Etc. > I see I don't have debugging symbols compiled in the userland so I nee= d = > to rebuild to make gdb happy. > > Ronald. I have some new data. I compiled world with debug symbols and succeeded = to = boot correctly again (it works if fsck needs to kick in). root@:~ # gdb ps GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you= = are welcome to change it and/or distribute copies of it under certain = conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for detai= ls. This GDB was configured as "arm-marcel-freebsd"... (gdb) run axu Starting program: /bin/ps axu ^C Program received signal SIGINT, Interrupt. 0x201cc108 in __mult_D2A (a=3D, b=3D) at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c:311 311 /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c: No such file or = = director y. in /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c Current language: auto; currently minimal (gdb) bt #0 0x201cc108 in __mult_D2A (a=3D, b=3D) at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c:311 #1 0x201cc2d8 in __pow5mult_D2A (b=3D, k=3D) at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c:409 #2 0x201c2b68 in __dtoa (d0=3D, mode=3D, ndigits=3D1, sign=3D, rve=3D) at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_dtoa.c:533 #3 0x201b8c70 in __vfprintf (fp=3D0xbfffe238, locale=3D0x201ec620, fmt0=3D0xeec8 "%.1f", ap=3D{__ap =3D 0xbfffe378}) at /usr/src/lib/libc/stdio/vfprintf.c:713 #4 0x2015a064 in vasprintf_l (str=3D0xbfffe378, locale=3D0x201ec620, fmt=3D0xeec8 "%.1f") at /usr/src/lib/libc/stdio/vasprintf.c:59 #5 0x2015a130 in vasprintf (str=3D0xbfffe378, fmt=3D0xeec8 "%.1f") at /usr/src/lib/libc/stdio/vasprintf.c:73 #6 0x20158748 in asprintf (s=3D, fmt=3D0x20a26338 = "=C2=BARX=C2=BA=C3=83=C3=A8\037\227=C3=A3\231a=C3=B5Zu\020=C3=AF=C3=A9\0= 31=C3=BD=C3=8B\220\001=C3=B9=C3=AA=C3=86=C3=9B=C2=A9iM\001=C2=BC=C2=B5=C3= =AEJ=C3=8D=C2=B1 = =C3=8F=C3=86=C3=83=C2=A9=C3=93.=C3=90\017$)=C3=B6=C3=A4\005=C3=A3eZX=C2=B1= .Z&\004 \005=C3=97\005") at /usr/src/lib/libc/stdio/asprintf.c:52 #7 0x0000b924 in pmem (k=3D, ve=3D) at /usr/src/bin/ps/print.c:669 #8 0x0000d014 in $a () at /usr/src/bin/ps/ps.c:1134 #9 0x0000d014 in $a () at /usr/src/bin/ps/ps.c:1134 Is it possible this gives an endless loop on armv5? Ronald. From owner-freebsd-arm@FreeBSD.ORG Thu Sep 5 13:32:59 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5AF04B88; Thu, 5 Sep 2013 13:32:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E4872E7E; Thu, 5 Sep 2013 13:32:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r85DWwnI044963; Thu, 5 Sep 2013 09:32:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r85DWwtj044961; Thu, 5 Sep 2013 13:32:58 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 5 Sep 2013 13:32:58 GMT Message-Id: <201309051332.r85DWwtj044961@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 13:32:59 -0000 TB --- 2013-09-05 10:20:32 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-09-05 10:20:32 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-09-05 10:20:32 - starting HEAD tinderbox run for arm/arm TB --- 2013-09-05 10:20:32 - cleaning the object tree TB --- 2013-09-05 10:20:32 - /usr/local/bin/svn stat /src TB --- 2013-09-05 10:20:37 - At svn revision 255238 TB --- 2013-09-05 10:20:38 - building world TB --- 2013-09-05 10:20:38 - CROSS_BUILD_TESTING=YES TB --- 2013-09-05 10:20:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-05 10:20:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-05 10:20:38 - SRCCONF=/dev/null TB --- 2013-09-05 10:20:38 - TARGET=arm TB --- 2013-09-05 10:20:38 - TARGET_ARCH=arm TB --- 2013-09-05 10:20:38 - TZ=UTC TB --- 2013-09-05 10:20:38 - __MAKE_CONF=/dev/null TB --- 2013-09-05 10:20:38 - cd /src TB --- 2013-09-05 10:20:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Sep 5 10:20:45 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 5 13:22:27 UTC 2013 TB --- 2013-09-05 13:22:27 - generating LINT kernel config TB --- 2013-09-05 13:22:27 - cd /src/sys/arm/conf TB --- 2013-09-05 13:22:27 - /usr/bin/make -B LINT TB --- 2013-09-05 13:22:27 - cd /src/sys/arm/conf TB --- 2013-09-05 13:22:27 - /usr/sbin/config -m LINT TB --- 2013-09-05 13:22:27 - building LINT kernel TB --- 2013-09-05 13:22:27 - CROSS_BUILD_TESTING=YES TB --- 2013-09-05 13:22:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-05 13:22:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-05 13:22:27 - SRCCONF=/dev/null TB --- 2013-09-05 13:22:27 - TARGET=arm TB --- 2013-09-05 13:22:27 - TARGET_ARCH=arm TB --- 2013-09-05 13:22:27 - TZ=UTC TB --- 2013-09-05 13:22:27 - __MAKE_CONF=/dev/null TB --- 2013-09-05 13:22:27 - cd /src TB --- 2013-09-05 13:22:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 5 13:22:27 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^ ./machine/counter.h:91:2: note: previous implicit declaration is here counter_exit(); ^ ./machine/counter.h:38:24: note: expanded from macro 'counter_exit' #define counter_exit() critical_exit() ^ 5 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-09-05 13:32:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-09-05 13:32:58 - ERROR: failed to build LINT kernel TB --- 2013-09-05 13:32:58 - 9130.77 user 1647.71 system 11545.59 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Sep 5 20:03:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5F3AFA34 for ; Thu, 5 Sep 2013 20:03:00 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E8142CEB for ; Thu, 5 Sep 2013 20:03:00 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id n12so2926399oag.15 for ; Thu, 05 Sep 2013 13:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=NCloh5mBPwI0ue14ZUk1Xz89wJbvxG/1id+oKScQqcA=; b=O43hD2dcJwSrA5CV7fx6nUmHiLhO0sEliYRyzmOrmqZjabYOKgxnmt5h95BWkTMD/L 1v9p6FO7UjL6YTnL434knVCyDArmleMMGH4ueC11aY2PJcA3fM8uzeaVErp1d2/zFs7P 3onYeJel6+uk+ap4SQIKnKAwt6xAP6HP8hsy01y4zWRfkIazECHBOWwtsHHJfQeCEyze i8/62uzUzrSY/+m9aiqIoLddgfA0tysrjV0cz5twLTX1RI6d0WpsHLVzBS3ZfL3zshOY r47+q33EzH+h2F+AD9NmSagVwU2ZrGavlnKjmyJEXYfs2MDELhh0b7v8xs7VYc4VU+CK 5UNg== X-Received: by 10.182.131.166 with SMTP id on6mr7695858obb.60.1378411379334; Thu, 05 Sep 2013 13:02:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.131.111 with HTTP; Thu, 5 Sep 2013 13:02:29 -0700 (PDT) From: Jia-Shiun Li Date: Fri, 6 Sep 2013 04:02:29 +0800 Message-ID: Subject: stream benchmarking on RPi To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 20:03:00 -0000 Hi all, just did a brief test using stream, the memory bandwidth benchmark, on RPi with Raspbian and FreeBSD. Share these info to see if someone might think of it useful. FreeBSD is faster at copying. I guess that must be attributed to recent VM and/or superpage commits. I remembered it to be under 300MB/s months before. On the other hand, scale, add, and triad are significantly slower. Anyone have clues or any wild guesses? Below the only compiler option given for cc/gcc is -O3. Raspbian 2013-07-26 (lk 3.6, gcc 4.6): ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 257.3 0.062703 0.062189 0.063824 Scale: 205.1 0.079135 0.077993 0.082000 Add: 284.1 0.085253 0.084480 0.088597 Triad: 274.3 0.087799 0.087501 0.087940 ------------------------------------------------------------- FreeBSD 10.0-CURRENT r255120 w/ cc(clang): ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 365.5 0.045321 0.043779 0.052929 Scale: 31.2 0.531028 0.513082 0.550906 Add: 68.5 0.367295 0.350467 0.391310 Triad: 26.9 0.902672 0.893316 0.908908 ------------------------------------------------------------- FreeBSD 10.0-CURRENT r255120 w/ gcc (4.2.1): ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 264.6 0.063977 0.060470 0.081000 Scale: 31.0 0.535830 0.516093 0.551035 Add: 46.7 0.534768 0.514323 0.553834 Triad: 23.1 1.047644 1.038968 1.066887 ------------------------------------------------------------- Jia-Shiun. From owner-freebsd-arm@FreeBSD.ORG Thu Sep 5 20:49:30 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 480DCC0C for ; Thu, 5 Sep 2013 20:49:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 167332F77 for ; Thu, 5 Sep 2013 20:49:30 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id aq17so4916107iec.41 for ; Thu, 05 Sep 2013 13:49:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=EOABt84j3WSageqcWS0FnlTaPrD+7lnWrZ+IcRCFu78=; b=C4MCOdpJjpvdmFtHX95QxG47YZfDprDyK10X0gpz89HN0bvIUN++o/msaSeJ7csdyl Xo5LoqPETy3NLaPRvK5oEtClRPQSoJqGgaefXZC5QcxYQNLs1N9ebEyT6lchrEyYDs0b 6raAl/3LwW3EfVJZZ/5dH35qT7CPKcn1CotAy2Sz4XtJFyhE32FQdyj1gU7VDydQm/qm XFLKz/8C00Dl4x7Ak8aZkZ1dSBCPBIKt76jkqc51vFZpCVjaHX1GvGp50R2uuysxX/Bm CAtV09DNC+4X82fkB5PnaSIZT2EjyYIydiFIQgFWiICcZ1n8F2dv9P44dxhWfhabAsde kreg== X-Gm-Message-State: ALoCoQmlxSaYMN61mXunq1YrQm0bv2UN5eUHrHMAC9xMu1R3B0gs7itT7mdZ9pAeYGD/tpqxak6x X-Received: by 10.50.55.40 with SMTP id o8mr6388039igp.25.1378414163322; Thu, 05 Sep 2013 13:49:23 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id f5sm13496382igc.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Sep 2013 13:49:22 -0700 (PDT) Sender: Warner Losh Subject: Re: stream benchmarking on RPi Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 5 Sep 2013 14:49:19 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: To: Jia-Shiun Li X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 20:49:30 -0000 On Sep 5, 2013, at 2:02 PM, Jia-Shiun Li wrote: > Hi all, > > just did a brief test using stream, the memory bandwidth benchmark, on > RPi with Raspbian and FreeBSD. Share these info to see if someone > might think of it useful. > > FreeBSD is faster at copying. I guess that must be attributed to > recent VM and/or superpage commits. I remembered it to be under > 300MB/s months before. On the other hand, scale, add, and triad are > significantly slower. Anyone have clues or any wild guesses? Soft float? Warner > Below the only compiler option given for cc/gcc is -O3. > > Raspbian 2013-07-26 (lk 3.6, gcc 4.6): > ------------------------------------------------------------- > Function Best Rate MB/s Avg time Min time Max time > Copy: 257.3 0.062703 0.062189 0.063824 > Scale: 205.1 0.079135 0.077993 0.082000 > Add: 284.1 0.085253 0.084480 0.088597 > Triad: 274.3 0.087799 0.087501 0.087940 > ------------------------------------------------------------- > > FreeBSD 10.0-CURRENT r255120 w/ cc(clang): > ------------------------------------------------------------- > Function Best Rate MB/s Avg time Min time Max time > Copy: 365.5 0.045321 0.043779 0.052929 > Scale: 31.2 0.531028 0.513082 0.550906 > Add: 68.5 0.367295 0.350467 0.391310 > Triad: 26.9 0.902672 0.893316 0.908908 > ------------------------------------------------------------- > > FreeBSD 10.0-CURRENT r255120 w/ gcc (4.2.1): > ------------------------------------------------------------- > Function Best Rate MB/s Avg time Min time Max time > Copy: 264.6 0.063977 0.060470 0.081000 > Scale: 31.0 0.535830 0.516093 0.551035 > Add: 46.7 0.534768 0.514323 0.553834 > Triad: 23.1 1.047644 1.038968 1.066887 > ------------------------------------------------------------- > > > Jia-Shiun. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Sep 5 22:37:40 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 220A576B for ; Thu, 5 Sep 2013 22:37:40 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D72682532 for ; Thu, 5 Sep 2013 22:37:39 +0000 (UTC) Received: by mail-qe0-f48.google.com with SMTP id nd7so378150qeb.21 for ; Thu, 05 Sep 2013 15:37:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HGJzmmBVZQdbB8QvhIKe22Mb/O91BrE+g6gDcugJyq8=; b=cbYswKSSg3ZyfWOxezf2qLcZCkok/19dW/0PygZ6eiu6APwlqbipWmN1/YwDnPY8CH 658F75xuK9mqqmeW85hzA7rckvt1yTjUl5hCNhVBrvkk+hKFuiBznXDxmDYw1Huvdb+q trVxqkkPmXDvkABVJXjZ/O5ljrm+0LQ6pD71VSZHB84X+KTZJBhCrNCGpA5T88g3Ly0R 92QsIA86tP1GXfK7liYx39Esipkl+h9WDOwKGve/5OP/pVE5xINUKlSXNxbvDv4cmB5r YSz6YjeZmmBuEJxkcTtmdTCXteLIdSocfm8Uc83XrixlWhtPV1WcWOYORpE0poxynprz CvQA== X-Gm-Message-State: ALoCoQntg1Fj7N7xeg5OxkrQnrObzOuzMO6YKmZH5r150Cnzwspztq+7Ta3Aog7dbOIKFwT7b0U/ MIME-Version: 1.0 X-Received: by 10.49.47.50 with SMTP id a18mr12779799qen.61.1378420653361; Thu, 05 Sep 2013 15:37:33 -0700 (PDT) Received: by 10.49.8.20 with HTTP; Thu, 5 Sep 2013 15:37:33 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Sep 2013 00:37:33 +0200 Message-ID: Subject: Re: stream benchmarking on RPi From: Zbigniew Bodek To: Jia-Shiun Li Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 22:37:40 -0000 2013/9/5 Jia-Shiun Li > Hi all, > > just did a brief test using stream, the memory bandwidth benchmark, on > RPi with Raspbian and FreeBSD. Share these info to see if someone > might think of it useful. > > FreeBSD is faster at copying. I guess that must be attributed to > recent VM and/or superpage commits. I remembered it to be under > 300MB/s months before. On the other hand, scale, add, and triad are > significantly slower. Anyone have clues or any wild guesses? > > > Below the only compiler option given for cc/gcc is -O3. > > Raspbian 2013-07-26 (lk 3.6, gcc 4.6): > ------------------------------------------------------------- > Function Best Rate MB/s Avg time Min time Max time > Copy: 257.3 0.062703 0.062189 0.063824 > Scale: 205.1 0.079135 0.077993 0.082000 > Add: 284.1 0.085253 0.084480 0.088597 > Triad: 274.3 0.087799 0.087501 0.087940 > ------------------------------------------------------------- > > FreeBSD 10.0-CURRENT r255120 w/ cc(clang): > ------------------------------------------------------------- > Function Best Rate MB/s Avg time Min time Max time > Copy: 365.5 0.045321 0.043779 0.052929 > Scale: 31.2 0.531028 0.513082 0.550906 > Add: 68.5 0.367295 0.350467 0.391310 > Triad: 26.9 0.902672 0.893316 0.908908 > ------------------------------------------------------------- > > FreeBSD 10.0-CURRENT r255120 w/ gcc (4.2.1): > ------------------------------------------------------------- > Function Best Rate MB/s Avg time Min time Max time > Copy: 264.6 0.063977 0.060470 0.081000 > Scale: 31.0 0.535830 0.516093 0.551035 > Add: 46.7 0.534768 0.514323 0.553834 > Triad: 23.1 1.047644 1.038968 1.066887 > ------------------------------------------------------------- > > Hello Jia-Shiun. Thanks for your effort in testing. I am actually in the middle of superpages tests and another benchmark and set of results will be very helpful especially for comparison. Just for the record: did you enable superpages for your kernel? SP are not yet enabled by default, therefore one needs to set vm.pmap.sp_enabled to non-zero value in loader.conf (if you are using loader) or set this value in src by editing sys/arm/arm/pmap-v6.c -> sp_enabled. Nevertheless I've made short tests on Armada XP (clang). I used two array sizes (default and 2 x default). I also made few runs to ensure that the results are steady. Please check below (improvement in copy can be seen but from what one can observe via sysctl vm.pmap.section not so many superpages are "requested" during the test): Array size = 10000000 (elements) ================================ sp disabled ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 1311.9 0.124910 0.121956 0.126486 Scale: 64.2 2.546568 2.493977 2.570808 Add: 112.1 2.163666 2.140962 2.205463 Triad: 51.3 4.683770 4.675176 4.689565 sp enabled ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 1368.9 0.119831 0.116878 0.121894 Scale: 64.6 2.527607 2.476270 2.551667 Add: 112.9 2.147966 2.125261 2.189840 Triad: 51.6 4.654865 4.647609 4.662289 Array size = 20000000 (elements) ================================ sp disabled ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 1271.2 0.257928 0.251738 0.260991 Scale: 64.2 5.092455 4.987830 5.139630 Add: 112.0 4.331419 4.287459 4.416701 Triad: 51.3 9.366274 9.349165 9.379344 sp enabled ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 1333.3 0.250755 0.240014 0.253216 Scale: 64.5 5.065569 4.963166 5.114160 Add: 112.4 4.312079 4.268610 4.395812 Triad: 51.6 9.325673 9.309094 9.338787 Best regards Zbigniew Bodek From owner-freebsd-arm@FreeBSD.ORG Fri Sep 6 03:16:05 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1482EB82 for ; Fri, 6 Sep 2013 03:16:05 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C2E0C2127 for ; Fri, 6 Sep 2013 03:16:04 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VHmWg-0005yJ-KH; Fri, 06 Sep 2013 03:16:03 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r863Fxls071783; Thu, 5 Sep 2013 21:15:59 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18nKNIJ8WewsDYKdKnNQVXK Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Ian Lepore To: Ronald Klop In-Reply-To: References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <6046B66D-5F4C-4E8D-923A-3E26DED5DD8F@bsdimp.com> Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 05 Sep 2013 21:15:58 -0600 Message-ID: <1378437358.1111.444.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r863Fxls071783 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 03:16:05 -0000 On Thu, 2013-09-05 at 12:59 +0200, Ronald Klop wrote: > On Fri, 30 Aug 2013 14:04:52 +0200, Ronald Klop =20 > wrote: >=20 > > > > Oh wow, for some lucky reason I add rc_info=3D"YES" to rc.conf and wh= en I =20 > > rebooted it did an fsck of all filesystems and it booted into multius= er. =20 > > I am now logged in and see the same as Ian. Top does not work. Df han= gs. =20 > > Etc. > > I see I don't have debugging symbols compiled in the userland so I ne= ed =20 > > to rebuild to make gdb happy. > > > > Ronald. >=20 > I have some new data. I compiled world with debug symbols and succeeded= to =20 > boot correctly again (it works if fsck needs to kick in). > root@:~ # gdb ps > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and yo= u =20 > are > welcome to change it and/or distribute copies of it under certain =20 > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > This GDB was configured as "arm-marcel-freebsd"... > (gdb) run axu > Starting program: /bin/ps axu >=20 >=20 > ^C > Program received signal SIGINT, Interrupt. > 0x201cc108 in __mult_D2A (a=3D, b=3D) > at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c:311 > 311 /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c: No such file or= =20 > director y. > in /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c > Current language: auto; currently minimal > (gdb) bt > #0 0x201cc108 in __mult_D2A (a=3D, b=3D out>) > at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c:311 > #1 0x201cc2d8 in __pow5mult_D2A (b=3D, > k=3D) > at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c:409 > #2 0x201c2b68 in __dtoa (d0=3D, > mode=3D, ndigits=3D1, sign=3D, > rve=3D) > at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_dtoa.c:533 > #3 0x201b8c70 in __vfprintf (fp=3D0xbfffe238, locale=3D0x201ec620, > fmt0=3D0xeec8 "%.1f", ap=3D{__ap =3D 0xbfffe378}) > at /usr/src/lib/libc/stdio/vfprintf.c:713 > #4 0x2015a064 in vasprintf_l (str=3D0xbfffe378, locale=3D0x201ec620, > fmt=3D0xeec8 "%.1f") at /usr/src/lib/libc/stdio/vasprintf.c:59 > #5 0x2015a130 in vasprintf (str=3D0xbfffe378, fmt=3D0xeec8 "%.1f") > at /usr/src/lib/libc/stdio/vasprintf.c:73 > #6 0x20158748 in asprintf (s=3D, > fmt=3D0x20a26338 =20 > "=BARX=BA=C3=E8\037\227=E3\231a=F5Zu\020=EF=E9\031=FD=CB\220\001=F9=EA=C6= =DB=A9iM\001=BC=B5=EEJ=CD=B1 =20 > =CF=C6=C3=A9=D3.=D0\017$)=F6=E4\005=E3eZX=B1.Z&\004 \005=D7\005") > at /usr/src/lib/libc/stdio/asprintf.c:52 > #7 0x0000b924 in pmem (k=3D, ve=3D) > at /usr/src/bin/ps/print.c:669 > #8 0x0000d014 in $a () at /usr/src/bin/ps/ps.c:1134 > #9 0x0000d014 in $a () at /usr/src/bin/ps/ps.c:1134 >=20 > Is it possible this gives an endless loop on armv5? This is good info, thanks. We've been digging into it a bit more on irc. One thing I determined that I'll mention so it saves you some grief... you were lucky to get that backtrace, because of all the "value optimized out" stuff. If you build the library with -O0 to prevent that, the backtrace will contain floating point numbers. Then because gdb uses the libc code we're trying to debug to format floating point numbers, gdb locks up. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Sep 6 14:30:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 348C7136 for ; Fri, 6 Sep 2013 14:30:16 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01074206C for ; Fri, 6 Sep 2013 14:30:15 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id o17so3906795oag.21 for ; Fri, 06 Sep 2013 07:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q3gJoJVDp35yrqWXkPwnzgRZWaxF7OKNG+Laim/r61w=; b=ru0wFIL6h2Dsfp/2uDLMyhMm/wuQg59VM46QxvgAM5Zug/Z3R/1S5R4N8ncwBTwPWd /NlhoUQr4LLzO1S435hTy5SkX+/nfjk5++LNIa0Kvr1ZSnC5Divq4j/7jzaszntW9aJq jtN4fB6P10kOkwLd3XtSDLdMd5/PKibBvw5MXBI9yfLO3SkdsjoEgYI8nM3XSNSuLbjv wvliIB/Zcqsp0sskVmdj/SroxmaZp1potQqKetki4aS2Ntiv4xCvh4MNjpszaULBVxpw QYXV0yd/b2L4TDzZTk55HT5FiHmhtbuuEQDiBEb/ybM+0MbdDhh157qixC32MFXozVii o9BA== X-Received: by 10.182.81.65 with SMTP id y1mr2027221obx.89.1378477815360; Fri, 06 Sep 2013 07:30:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.131.111 with HTTP; Fri, 6 Sep 2013 07:29:45 -0700 (PDT) In-Reply-To: References: From: Jia-Shiun Li Date: Fri, 6 Sep 2013 22:29:45 +0800 Message-ID: Subject: Re: stream benchmarking on RPi To: Zbigniew Bodek Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 14:30:16 -0000 On Fri, Sep 6, 2013 at 6:37 AM, Zbigniew Bodek wrote: > Hello Jia-Shiun. > > Thanks for your effort in testing. > I am actually in the middle of superpages tests and another benchmark and > set of > results will be very helpful especially for comparison. > > Just for the record: did you enable superpages for your kernel? > SP are not yet enabled by default, therefore one needs to set > vm.pmap.sp_enabled to non-zero value in loader.conf (if you are using > loader) > or set this value in src by editing sys/arm/arm/pmap-v6.c -> sp_enabled. > > Nevertheless I've made short tests on Armada XP (clang). > I used two array sizes (default and 2 x default). I also made few runs to > ensure > that the results are steady. > Please check below (improvement in copy can be seen but from what one can > observe via sysctl vm.pmap.section not so many superpages are "requested" > during the test): Yes I confirmed that superpages was not enabled yet. I thought it was on by default. Should have paid more attention. Then the improvement I've seen can also attribute to someone else. Any nominees? ;) after enabling it in loader.rc ("set vm.pmap.sp_enabled=1"), the benchmark did not see big difference. Like your results, differences are visible, but not big. ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 372.6 0.043278 0.042943 0.043590 Scale: 31.1 0.529411 0.514686 0.545614 Add: 69.2 0.363791 0.346574 0.381367 Triad: 27.4 0.909578 0.875739 0.995989 ------------------------------------------------------------- sp did only have a few activities. I suppose it to be more obvious for usages heavily sporting and fragmenting memory, rather than sequential large block accesses like stream did? After several stream runs: # sysctl vm.pmap.section vm.pmap.section.demotions: 0 vm.pmap.section.mappings: 0 vm.pmap.section.p_failures: 120 vm.pmap.section.promotions: 277 BTW I modified the array size from 10m to 1m, otherwise it will allocate more than 200MB/s and run for several minutes. It should not affect result much on processors having speed like this . I was checking if there is anything can be done to improve performance of RPi. Building world takes days and nights. (But works! Ya!) For stream it looks more like being bound to some OS/compiler/etc. usage rather than hard limit of hardware. Let's see what else can be found. Thanks, Jia-Shiun. From owner-freebsd-arm@FreeBSD.ORG Fri Sep 6 14:49:28 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D7F8915D for ; Fri, 6 Sep 2013 14:49:28 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD5BB22EA for ; Fri, 6 Sep 2013 14:49:28 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VHxLj-000LWU-6Y; Fri, 06 Sep 2013 14:49:27 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r86EnHg0072487; Fri, 6 Sep 2013 08:49:22 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/19xe48XW05x4tuVTV/rjO Subject: Re: stream benchmarking on RPi From: Ian Lepore To: Jia-Shiun Li In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Sep 2013 08:49:02 -0600 Message-ID: <1378478942.1111.448.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 14:49:29 -0000 On Fri, 2013-09-06 at 22:29 +0800, Jia-Shiun Li wrote: > On Fri, Sep 6, 2013 at 6:37 AM, Zbigniew Bodek wrote: > > Hello Jia-Shiun. > > > > Thanks for your effort in testing. > > I am actually in the middle of superpages tests and another benchmark and > > set of > > results will be very helpful especially for comparison. > > > > Just for the record: did you enable superpages for your kernel? > > SP are not yet enabled by default, therefore one needs to set > > vm.pmap.sp_enabled to non-zero value in loader.conf (if you are using > > loader) > > or set this value in src by editing sys/arm/arm/pmap-v6.c -> sp_enabled. > > > > Nevertheless I've made short tests on Armada XP (clang). > > I used two array sizes (default and 2 x default). I also made few runs to > > ensure > > that the results are steady. > > Please check below (improvement in copy can be seen but from what one can > > observe via sysctl vm.pmap.section not so many superpages are "requested" > > during the test): > > Yes I confirmed that superpages was not enabled yet. I thought it was on > by default. Should have paid more attention. Then the improvement I've > seen can also attribute to someone else. Any nominees? ;) > > after enabling it in loader.rc ("set vm.pmap.sp_enabled=1"), the > benchmark did not see big difference. Like your results, > differences are visible, but not big. > ------------------------------------------------------------- > Function Best Rate MB/s Avg time Min time Max time > Copy: 372.6 0.043278 0.042943 0.043590 > Scale: 31.1 0.529411 0.514686 0.545614 > Add: 69.2 0.363791 0.346574 0.381367 > Triad: 27.4 0.909578 0.875739 0.995989 > ------------------------------------------------------------- > > sp did only have a few activities. I suppose it to be more obvious for > usages heavily sporting and fragmenting memory, rather than > sequential large block accesses like stream did? After several > stream runs: > # sysctl vm.pmap.section > vm.pmap.section.demotions: 0 > vm.pmap.section.mappings: 0 > vm.pmap.section.p_failures: 120 > vm.pmap.section.promotions: 277 > > BTW I modified the array size from 10m to 1m, otherwise it will allocate > more than 200MB/s and run for several minutes. It should not affect > result much on processors having speed like this . > I think we might see better performance gains if we supported 64k superpages rather than 1m sections. The odds of an application allocating a whole megabyte at once and getting all contiguous physical pages for it seem fairly small. > I was checking if there is anything can be done to improve performance > of RPi. Building world takes days and nights. (But works! Ya!) > For stream it looks more like being bound to some OS/compiler/etc. > usage rather than hard limit of hardware. Let's see what else can be found. We are still using software floating point. The hardfloat support is being worked on, but not enabled yet. I have no idea what that benchmark is testing, but Scale, Add, and Triad sound like things that would involve floating point. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Sep 6 23:59:28 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 94C54607; Fri, 6 Sep 2013 23:59:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 68A67285C; Fri, 6 Sep 2013 23:59:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r86NxRpw078094; Fri, 6 Sep 2013 19:59:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r86NxRLs078088; Fri, 6 Sep 2013 23:59:27 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 6 Sep 2013 23:59:27 GMT Message-Id: <201309062359.r86NxRLs078088@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 23:59:28 -0000 TB --- 2013-09-06 20:50:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-09-06 20:50:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-09-06 20:50:25 - starting HEAD tinderbox run for arm/arm TB --- 2013-09-06 20:50:25 - cleaning the object tree TB --- 2013-09-06 20:50:25 - /usr/local/bin/svn stat /src TB --- 2013-09-06 20:50:30 - At svn revision 255326 TB --- 2013-09-06 20:50:31 - building world TB --- 2013-09-06 20:50:31 - CROSS_BUILD_TESTING=YES TB --- 2013-09-06 20:50:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-06 20:50:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-06 20:50:31 - SRCCONF=/dev/null TB --- 2013-09-06 20:50:31 - TARGET=arm TB --- 2013-09-06 20:50:31 - TARGET_ARCH=arm TB --- 2013-09-06 20:50:31 - TZ=UTC TB --- 2013-09-06 20:50:31 - __MAKE_CONF=/dev/null TB --- 2013-09-06 20:50:31 - cd /src TB --- 2013-09-06 20:50:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Sep 6 20:50:39 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Sep 6 23:51:40 UTC 2013 TB --- 2013-09-06 23:51:40 - generating LINT kernel config TB --- 2013-09-06 23:51:40 - cd /src/sys/arm/conf TB --- 2013-09-06 23:51:40 - /usr/bin/make -B LINT TB --- 2013-09-06 23:51:40 - cd /src/sys/arm/conf TB --- 2013-09-06 23:51:40 - /usr/sbin/config -m LINT TB --- 2013-09-06 23:51:41 - building LINT kernel TB --- 2013-09-06 23:51:41 - CROSS_BUILD_TESTING=YES TB --- 2013-09-06 23:51:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-06 23:51:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-06 23:51:41 - SRCCONF=/dev/null TB --- 2013-09-06 23:51:41 - TARGET=arm TB --- 2013-09-06 23:51:41 - TARGET_ARCH=arm TB --- 2013-09-06 23:51:41 - TZ=UTC TB --- 2013-09-06 23:51:41 - __MAKE_CONF=/dev/null TB --- 2013-09-06 23:51:41 - cd /src TB --- 2013-09-06 23:51:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 6 23:51:41 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^ /src/sys/dev/md/md.c:460:9: error: implicit declaration of function 'sf_buf_alloc' is invalid in C99 [-Werror,-Wimplicit-function-declaration] sf = sf_buf_alloc(m, SFB_CPUPRIVATE | ^ /src/sys/dev/md/md.c:460:7: error: incompatible integer to pointer conversion assigning to 'struct sf_buf *' from 'int' [-Werror,-Wint-conversion] sf = sf_buf_alloc(m, SFB_CPUPRIVATE | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-09-06 23:59:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-09-06 23:59:27 - ERROR: failed to build LINT kernel TB --- 2013-09-06 23:59:27 - 8900.97 user 1686.52 system 11341.52 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Sep 7 08:29:51 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 291252D9 for ; Sat, 7 Sep 2013 08:29:51 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 0C94A238D for ; Sat, 7 Sep 2013 08:29:50 +0000 (UTC) Received: from bender.Home (97e5e46b.skybroadband.com [151.229.228.107]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 04B365DFF7; Sat, 7 Sep 2013 08:29:43 +0000 (UTC) Date: Sat, 7 Sep 2013 09:29:37 +0100 From: Andrew Turner To: Warner Losh Subject: Re: stream benchmarking on RPi Message-ID: <20130907092937.0aee2245@bender.Home> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 08:29:51 -0000 On Thu, 5 Sep 2013 14:49:19 -0600 Warner Losh wrote: > > On Sep 5, 2013, at 2:02 PM, Jia-Shiun Li wrote: > > > Hi all, > > > > just did a brief test using stream, the memory bandwidth benchmark, > > on RPi with Raspbian and FreeBSD. Share these info to see if someone > > might think of it useful. > > > > FreeBSD is faster at copying. I guess that must be attributed to > > recent VM and/or superpage commits. I remembered it to be under > > 300MB/s months before. On the other hand, scale, add, and triad are > > significantly slower. Anyone have clues or any wild guesses? > > Soft float? This looks to be the case, stream uses floating point arithmetic for the scale, add, and triad tests. The copy test is a straight copy from one array of doubles to another. It looks like most of the speed up in the copy test is from the move from gcc to clang. I am planning on investigating moving to softfp on armv6 for 10.1. I don't expect this to cause any major issues as it is compatible with the current float ABI in that both pass floating point values in ARM registers. I think this will improve the test results, but may not be at the same level as Raspbian appears to use the hard-float ABI. This is also planned, however I am unsure when this will appear. Andrew From owner-freebsd-arm@FreeBSD.ORG Sat Sep 7 10:19:21 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 70DCBB19; Sat, 7 Sep 2013 10:19:21 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay03.alfahosting-server.de (relay03.alfahosting-server.de [109.237.142.239]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E2D827D1; Sat, 7 Sep 2013 10:19:20 +0000 (UTC) Received: by relay03.alfahosting-server.de (Postfix, from userid 1001) id 9E28832C144B; Sat, 7 Sep 2013 12:19:13 +0200 (CEST) X-Spam-DCC: : relay01 1356; Body=1 Fuz1=1 Fuz2=1 X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay03.alfahosting-server.de (Postfix) with ESMTPS id 64F3932C1437; Sat, 7 Sep 2013 12:19:10 +0200 (CEST) Received: from desktop-01.martinlaabs.de (p54B311BD.dip0.t-ipconnect.de [84.179.17.189]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id 23896515DEA1; Sat, 7 Sep 2013 12:19:10 +0200 (CEST) Message-ID: <522AFD9D.9010500@martinlaabs.de> Date: Sat, 07 Sep 2013 12:19:09 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: nfsv4 fails with kerberos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17824/Sat Sep 7 06:37:51 2013 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 10:19:21 -0000 Hi, I set up a nfsv4 server with kerberos but when starting the nfs server on the arm (RBI-B) board I get the following error message and the first (managing part) of the nfs exits: "nfsd: can't register svc name" This error message is produced by the following code in /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c: ==================:<======================= /* An empty string implies AUTH_SYS only. */ if (principal[0] != '\0') { ret2 = rpc_gss_set_svc_name_call(principal, "kerberosv5", GSS_C_INDEFINITE, NFS_PROG, NFS_VER2); ret3 = rpc_gss_set_svc_name_call(principal, "kerberosv5", GSS_C_INDEFINITE, NFS_PROG, NFS_VER3); ret4 = rpc_gss_set_svc_name_call(principal, "kerberosv5", GSS_C_INDEFINITE, NFS_PROG, NFS_VER4); if (!ret2 || !ret3 || !ret4) printf("nfsd: can't register svc name\n"); ==================:<======================= So something went wrong with the principals. Is there a way to get more information or more verbose debugging output from the nfs-server part of the kernel? Thank you, Martin Laabs From owner-freebsd-arm@FreeBSD.ORG Sat Sep 7 11:50:08 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2718FE4E; Sat, 7 Sep 2013 11:50:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id CE1782C03; Sat, 7 Sep 2013 11:50:07 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEAMURK1KDaFve/2dsb2JhbABbgz9Rgyq+VYE8dIIlAQEBAwEBAQEgKyALBRYOCgICDQUBEwIpAQkmBggHBAEcBIdbBgyxFpEhgSmNHoEFATMHEgGCVoE0A5Usg3iQN4M8IDJ8Bxci X-IronPort-AV: E=Sophos;i="4.90,859,1371096000"; d="scan'208";a="49847019" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 07 Sep 2013 07:50:06 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2B985B3F4B; Sat, 7 Sep 2013 07:50:06 -0400 (EDT) Date: Sat, 7 Sep 2013 07:50:06 -0400 (EDT) From: Rick Macklem To: Martin Laabs Message-ID: <955745639.19718288.1378554606139.JavaMail.root@uoguelph.ca> In-Reply-To: <522AFD9D.9010500@martinlaabs.de> Subject: Re: nfsv4 fails with kerberos MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-net@freebsd.org, freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 11:50:08 -0000 Martin Laabs wrote: > Hi, > > I set up a nfsv4 server with kerberos but when starting the nfs > server on > the arm (RBI-B) board I get the following error message and the first > (managing part) of the nfs exits: > > "nfsd: can't register svc name" > > This error message is produced by the following code in > /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c: > > > ==================:<======================= > /* An empty string implies AUTH_SYS only. */ > if (principal[0] != '\0') { > ret2 = rpc_gss_set_svc_name_call(principal, > "kerberosv5", GSS_C_INDEFINITE, NFS_PROG, NFS_VER2); > ret3 = rpc_gss_set_svc_name_call(principal, > "kerberosv5", GSS_C_INDEFINITE, NFS_PROG, NFS_VER3); > ret4 = rpc_gss_set_svc_name_call(principal, > "kerberosv5", GSS_C_INDEFINITE, NFS_PROG, NFS_VER4); > > if (!ret2 || !ret3 || !ret4) > printf("nfsd: can't register svc name\n"); > ==================:<======================= > > So something went wrong with the principals. Is there a way to get > more > information or more verbose debugging output from the nfs-server part > of > the kernel? > The above message normally indicates that the gssd daemon isn't running. Here's a few places you can get info: man nfsv4, gssd http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup - This was done quite a while ago and I should ggo in and update it, but I think it is still mostly correct for server side. (The client in head/10 now does have "host based initiator cred" support.) Feel free to update it. All you should need to do so is a Google login. You need a service principal for "nfs", which means an entry for a principal that looks like: nfs/.@ (Stuff in "<>" needs to be filled in with the answer for your machine.) in /etc/krb5.keytab i the server. rick > Thank you, > Martin Laabs > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Sat Sep 7 12:14:10 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 543788DB; Sat, 7 Sep 2013 12:14:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 002AB2D58; Sat, 7 Sep 2013 12:14:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r87CE9F2063405; Sat, 7 Sep 2013 08:14:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r87CE9wZ063404; Sat, 7 Sep 2013 12:14:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 7 Sep 2013 12:14:09 GMT Message-Id: <201309071214.r87CE9wZ063404@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 12:14:10 -0000 TB --- 2013-09-07 08:00:42 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-09-07 08:00:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-09-07 08:00:42 - starting HEAD tinderbox run for arm/arm TB --- 2013-09-07 08:00:42 - cleaning the object tree TB --- 2013-09-07 08:03:13 - /usr/local/bin/svn stat /src TB --- 2013-09-07 08:03:16 - At svn revision 255353 TB --- 2013-09-07 08:03:17 - building world TB --- 2013-09-07 08:03:17 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 08:03:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 08:03:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 08:03:17 - SRCCONF=/dev/null TB --- 2013-09-07 08:03:17 - TARGET=arm TB --- 2013-09-07 08:03:17 - TARGET_ARCH=arm TB --- 2013-09-07 08:03:17 - TZ=UTC TB --- 2013-09-07 08:03:17 - __MAKE_CONF=/dev/null TB --- 2013-09-07 08:03:17 - cd /src TB --- 2013-09-07 08:03:17 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Sep 7 08:03:24 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Sep 7 11:06:55 UTC 2013 TB --- 2013-09-07 11:06:55 - generating LINT kernel config TB --- 2013-09-07 11:06:55 - cd /src/sys/arm/conf TB --- 2013-09-07 11:06:55 - /usr/bin/make -B LINT TB --- 2013-09-07 11:06:55 - cd /src/sys/arm/conf TB --- 2013-09-07 11:06:55 - /usr/sbin/config -m LINT TB --- 2013-09-07 11:06:55 - building LINT kernel TB --- 2013-09-07 11:06:55 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 11:06:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 11:06:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 11:06:55 - SRCCONF=/dev/null TB --- 2013-09-07 11:06:55 - TARGET=arm TB --- 2013-09-07 11:06:55 - TARGET_ARCH=arm TB --- 2013-09-07 11:06:55 - TZ=UTC TB --- 2013-09-07 11:06:55 - __MAKE_CONF=/dev/null TB --- 2013-09-07 11:06:55 - cd /src TB --- 2013-09-07 11:06:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 7 11:06:55 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Sep 7 11:31:28 UTC 2013 TB --- 2013-09-07 11:31:28 - cd /src/sys/arm/conf TB --- 2013-09-07 11:31:28 - /usr/sbin/config -m AC100 TB --- 2013-09-07 11:31:28 - skipping AC100 kernel TB --- 2013-09-07 11:31:28 - cd /src/sys/arm/conf TB --- 2013-09-07 11:31:28 - /usr/sbin/config -m ARMADAXP TB --- 2013-09-07 11:31:28 - skipping ARMADAXP kernel TB --- 2013-09-07 11:31:28 - cd /src/sys/arm/conf TB --- 2013-09-07 11:31:28 - /usr/sbin/config -m ARNDALE TB --- 2013-09-07 11:31:28 - skipping ARNDALE kernel TB --- 2013-09-07 11:31:28 - cd /src/sys/arm/conf TB --- 2013-09-07 11:31:28 - /usr/sbin/config -m ATMEL TB --- 2013-09-07 11:31:28 - building ATMEL kernel TB --- 2013-09-07 11:31:28 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 11:31:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 11:31:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 11:31:28 - SRCCONF=/dev/null TB --- 2013-09-07 11:31:28 - TARGET=arm TB --- 2013-09-07 11:31:28 - TARGET_ARCH=arm TB --- 2013-09-07 11:31:28 - TZ=UTC TB --- 2013-09-07 11:31:28 - __MAKE_CONF=/dev/null TB --- 2013-09-07 11:31:28 - cd /src TB --- 2013-09-07 11:31:28 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Sat Sep 7 11:31:28 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Sat Sep 7 11:35:18 UTC 2013 TB --- 2013-09-07 11:35:18 - cd /src/sys/arm/conf TB --- 2013-09-07 11:35:18 - /usr/sbin/config -m AVILA TB --- 2013-09-07 11:35:18 - skipping AVILA kernel TB --- 2013-09-07 11:35:18 - cd /src/sys/arm/conf TB --- 2013-09-07 11:35:18 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-09-07 11:35:18 - skipping BEAGLEBONE kernel TB --- 2013-09-07 11:35:18 - cd /src/sys/arm/conf TB --- 2013-09-07 11:35:18 - /usr/sbin/config -m BWCT TB --- 2013-09-07 11:35:18 - building BWCT kernel TB --- 2013-09-07 11:35:18 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 11:35:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 11:35:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 11:35:18 - SRCCONF=/dev/null TB --- 2013-09-07 11:35:18 - TARGET=arm TB --- 2013-09-07 11:35:18 - TARGET_ARCH=arm TB --- 2013-09-07 11:35:18 - TZ=UTC TB --- 2013-09-07 11:35:18 - __MAKE_CONF=/dev/null TB --- 2013-09-07 11:35:18 - cd /src TB --- 2013-09-07 11:35:18 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Sep 7 11:35:18 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Sat Sep 7 11:37:56 UTC 2013 TB --- 2013-09-07 11:37:56 - cd /src/sys/arm/conf TB --- 2013-09-07 11:37:56 - /usr/sbin/config -m CAMBRIA TB --- 2013-09-07 11:37:56 - skipping CAMBRIA kernel TB --- 2013-09-07 11:37:56 - cd /src/sys/arm/conf TB --- 2013-09-07 11:37:56 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-09-07 11:37:56 - building CNS11XXNAS kernel TB --- 2013-09-07 11:37:56 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 11:37:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 11:37:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 11:37:56 - SRCCONF=/dev/null TB --- 2013-09-07 11:37:56 - TARGET=arm TB --- 2013-09-07 11:37:56 - TARGET_ARCH=arm TB --- 2013-09-07 11:37:56 - TZ=UTC TB --- 2013-09-07 11:37:56 - __MAKE_CONF=/dev/null TB --- 2013-09-07 11:37:56 - cd /src TB --- 2013-09-07 11:37:56 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sat Sep 7 11:37:56 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Sat Sep 7 11:41:41 UTC 2013 TB --- 2013-09-07 11:41:41 - cd /src/sys/arm/conf TB --- 2013-09-07 11:41:41 - /usr/sbin/config -m CRB TB --- 2013-09-07 11:41:41 - skipping CRB kernel TB --- 2013-09-07 11:41:41 - cd /src/sys/arm/conf TB --- 2013-09-07 11:41:41 - /usr/sbin/config -m CUBIEBOARD TB --- 2013-09-07 11:41:41 - skipping CUBIEBOARD kernel TB --- 2013-09-07 11:41:41 - cd /src/sys/arm/conf TB --- 2013-09-07 11:41:41 - /usr/sbin/config -m CUBIEBOARD2 TB --- 2013-09-07 11:41:41 - skipping CUBIEBOARD2 kernel TB --- 2013-09-07 11:41:41 - cd /src/sys/arm/conf TB --- 2013-09-07 11:41:41 - /usr/sbin/config -m DB-78XXX TB --- 2013-09-07 11:41:41 - building DB-78XXX kernel TB --- 2013-09-07 11:41:41 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 11:41:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 11:41:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 11:41:41 - SRCCONF=/dev/null TB --- 2013-09-07 11:41:41 - TARGET=arm TB --- 2013-09-07 11:41:41 - TARGET_ARCH=arm TB --- 2013-09-07 11:41:41 - TZ=UTC TB --- 2013-09-07 11:41:41 - __MAKE_CONF=/dev/null TB --- 2013-09-07 11:41:41 - cd /src TB --- 2013-09-07 11:41:41 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sat Sep 7 11:41:41 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Sat Sep 7 11:44:59 UTC 2013 TB --- 2013-09-07 11:44:59 - cd /src/sys/arm/conf TB --- 2013-09-07 11:44:59 - /usr/sbin/config -m DB-88F5XXX TB --- 2013-09-07 11:44:59 - building DB-88F5XXX kernel TB --- 2013-09-07 11:44:59 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 11:44:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 11:44:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 11:44:59 - SRCCONF=/dev/null TB --- 2013-09-07 11:44:59 - TARGET=arm TB --- 2013-09-07 11:44:59 - TARGET_ARCH=arm TB --- 2013-09-07 11:44:59 - TZ=UTC TB --- 2013-09-07 11:44:59 - __MAKE_CONF=/dev/null TB --- 2013-09-07 11:44:59 - cd /src TB --- 2013-09-07 11:44:59 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sat Sep 7 11:44:59 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Sat Sep 7 11:48:10 UTC 2013 TB --- 2013-09-07 11:48:10 - cd /src/sys/arm/conf TB --- 2013-09-07 11:48:10 - /usr/sbin/config -m DB-88F6XXX TB --- 2013-09-07 11:48:10 - building DB-88F6XXX kernel TB --- 2013-09-07 11:48:10 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 11:48:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 11:48:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 11:48:10 - SRCCONF=/dev/null TB --- 2013-09-07 11:48:10 - TARGET=arm TB --- 2013-09-07 11:48:10 - TARGET_ARCH=arm TB --- 2013-09-07 11:48:10 - TZ=UTC TB --- 2013-09-07 11:48:10 - __MAKE_CONF=/dev/null TB --- 2013-09-07 11:48:10 - cd /src TB --- 2013-09-07 11:48:10 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sat Sep 7 11:48:10 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Sat Sep 7 11:51:30 UTC 2013 TB --- 2013-09-07 11:51:30 - cd /src/sys/arm/conf TB --- 2013-09-07 11:51:30 - /usr/sbin/config -m DIGI-CCWMX53 TB --- 2013-09-07 11:51:30 - skipping DIGI-CCWMX53 kernel TB --- 2013-09-07 11:51:30 - cd /src/sys/arm/conf TB --- 2013-09-07 11:51:30 - /usr/sbin/config -m DOCKSTAR TB --- 2013-09-07 11:51:30 - building DOCKSTAR kernel TB --- 2013-09-07 11:51:30 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 11:51:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 11:51:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 11:51:30 - SRCCONF=/dev/null TB --- 2013-09-07 11:51:30 - TARGET=arm TB --- 2013-09-07 11:51:30 - TARGET_ARCH=arm TB --- 2013-09-07 11:51:30 - TZ=UTC TB --- 2013-09-07 11:51:30 - __MAKE_CONF=/dev/null TB --- 2013-09-07 11:51:30 - cd /src TB --- 2013-09-07 11:51:30 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sat Sep 7 11:51:30 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Sat Sep 7 11:54:31 UTC 2013 TB --- 2013-09-07 11:54:31 - cd /src/sys/arm/conf TB --- 2013-09-07 11:54:31 - /usr/sbin/config -m DREAMPLUG-1001 TB --- 2013-09-07 11:54:31 - building DREAMPLUG-1001 kernel TB --- 2013-09-07 11:54:31 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 11:54:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 11:54:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 11:54:31 - SRCCONF=/dev/null TB --- 2013-09-07 11:54:31 - TARGET=arm TB --- 2013-09-07 11:54:31 - TARGET_ARCH=arm TB --- 2013-09-07 11:54:31 - TZ=UTC TB --- 2013-09-07 11:54:31 - __MAKE_CONF=/dev/null TB --- 2013-09-07 11:54:31 - cd /src TB --- 2013-09-07 11:54:31 - /usr/bin/make -B buildkernel KERNCONF=DREAMPLUG-1001 >>> Kernel build for DREAMPLUG-1001 started on Sat Sep 7 11:54:31 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DREAMPLUG-1001 completed on Sat Sep 7 12:00:11 UTC 2013 TB --- 2013-09-07 12:00:11 - cd /src/sys/arm/conf TB --- 2013-09-07 12:00:11 - /usr/sbin/config -m EA3250 TB --- 2013-09-07 12:00:11 - building EA3250 kernel TB --- 2013-09-07 12:00:11 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 12:00:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 12:00:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 12:00:11 - SRCCONF=/dev/null TB --- 2013-09-07 12:00:11 - TARGET=arm TB --- 2013-09-07 12:00:11 - TARGET_ARCH=arm TB --- 2013-09-07 12:00:11 - TZ=UTC TB --- 2013-09-07 12:00:11 - __MAKE_CONF=/dev/null TB --- 2013-09-07 12:00:11 - cd /src TB --- 2013-09-07 12:00:11 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Sat Sep 7 12:00:11 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EA3250 completed on Sat Sep 7 12:03:16 UTC 2013 TB --- 2013-09-07 12:03:16 - cd /src/sys/arm/conf TB --- 2013-09-07 12:03:16 - /usr/sbin/config -m EB9200 TB --- 2013-09-07 12:03:16 - building EB9200 kernel TB --- 2013-09-07 12:03:16 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 12:03:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 12:03:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 12:03:16 - SRCCONF=/dev/null TB --- 2013-09-07 12:03:16 - TARGET=arm TB --- 2013-09-07 12:03:16 - TARGET_ARCH=arm TB --- 2013-09-07 12:03:16 - TZ=UTC TB --- 2013-09-07 12:03:16 - __MAKE_CONF=/dev/null TB --- 2013-09-07 12:03:16 - cd /src TB --- 2013-09-07 12:03:16 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Sat Sep 7 12:03:16 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EB9200 completed on Sat Sep 7 12:06:48 UTC 2013 TB --- 2013-09-07 12:06:48 - cd /src/sys/arm/conf TB --- 2013-09-07 12:06:48 - /usr/sbin/config -m EFIKA_MX TB --- 2013-09-07 12:06:48 - skipping EFIKA_MX kernel TB --- 2013-09-07 12:06:48 - cd /src/sys/arm/conf TB --- 2013-09-07 12:06:48 - /usr/sbin/config -m EP80219 TB --- 2013-09-07 12:06:48 - skipping EP80219 kernel TB --- 2013-09-07 12:06:48 - cd /src/sys/arm/conf TB --- 2013-09-07 12:06:48 - /usr/sbin/config -m ETHERNUT5 TB --- 2013-09-07 12:06:48 - building ETHERNUT5 kernel TB --- 2013-09-07 12:06:48 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 12:06:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 12:06:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 12:06:48 - SRCCONF=/dev/null TB --- 2013-09-07 12:06:48 - TARGET=arm TB --- 2013-09-07 12:06:48 - TARGET_ARCH=arm TB --- 2013-09-07 12:06:48 - TZ=UTC TB --- 2013-09-07 12:06:48 - __MAKE_CONF=/dev/null TB --- 2013-09-07 12:06:48 - cd /src TB --- 2013-09-07 12:06:48 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Sat Sep 7 12:06:48 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ipf_rb_ht_init(head) ^ ; /src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/fil.c:9998:20: error: a parameter list without types is only allowed in a function definition ipf_rb_ht_freenode(node, arg) ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** Error code 1 Stop. bmake[3]: stopped in /src/sys/modules/ipfilter *** Error code 1 Stop. bmake[2]: stopped in /src/sys/modules *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/ETHERNUT5 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-09-07 12:14:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-09-07 12:14:09 - ERROR: failed to build ETHERNUT5 kernel TB --- 2013-09-07 12:14:09 - 11440.38 user 2412.86 system 15206.27 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Sep 7 14:12:08 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 517C289B; Sat, 7 Sep 2013 14:12:08 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 2411F240E; Sat, 7 Sep 2013 14:12:07 +0000 (UTC) Received: from bender.Home (97e5e46b.skybroadband.com [151.229.228.107]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 0B1E25DFF7; Sat, 7 Sep 2013 14:12:05 +0000 (UTC) Date: Sat, 7 Sep 2013 15:11:59 +0100 From: Andrew Turner To: Ian Lepore Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI Message-ID: <20130907151159.35dcf45c@bender.Home> In-Reply-To: <1378437358.1111.444.camel@revolution.hippie.lan> References: <20130820091527.42127170@bender.Home> <6046B66D-5F4C-4E8D-923A-3E26DED5DD8F@bsdimp.com> <1378437358.1111.444.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@FreeBSD.org, Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 14:12:08 -0000 On Thu, 05 Sep 2013 21:15:58 -0600 Ian Lepore wrote: > On Thu, 2013-09-05 at 12:59 +0200, Ronald Klop wrote: > > On Fri, 30 Aug 2013 14:04:52 +0200, Ronald Klop =20 > > wrote: > >=20 > > > > > > Oh wow, for some lucky reason I add rc_info=3D"YES" to rc.conf and > > > when I rebooted it did an fsck of all filesystems and it booted > > > into multiuser. I am now logged in and see the same as Ian. Top > > > does not work. Df hangs. Etc. > > > I see I don't have debugging symbols compiled in the userland so > > > I need to rebuild to make gdb happy. > > > > > > Ronald. > >=20 > > I have some new data. I compiled world with debug symbols and > > succeeded to boot correctly again (it works if fsck needs to kick > > in). root@:~ # gdb ps > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, > > and you are > > welcome to change it and/or distribute copies of it under certain =20 > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > > details. This GDB was configured as "arm-marcel-freebsd"... > > (gdb) run axu > > Starting program: /bin/ps axu > >=20 > >=20 > > ^C > > Program received signal SIGINT, Interrupt. > > 0x201cc108 in __mult_D2A (a=3D, b=3D > optimized out>) > > at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c:311 > > 311 /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c: No such > > file or director y. > > in /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c Current > > language: auto; currently minimal (gdb) bt > > #0 0x201cc108 in __mult_D2A (a=3D, b=3D > optimized =20 > > out>) > > at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c:311 > > #1 0x201cc2d8 in __pow5mult_D2A (b=3D, > > k=3D) > > at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_misc.c:409 > > #2 0x201c2b68 in __dtoa (d0=3D, > > mode=3D, ndigits=3D1, sign=3D > out>, rve=3D) > > at /usr/obj/arm.arm/usr/src/lib/libc/gdtoa_dtoa.c:533 > > #3 0x201b8c70 in __vfprintf (fp=3D0xbfffe238, locale=3D0x201ec620, > > fmt0=3D0xeec8 "%.1f", ap=3D{__ap =3D 0xbfffe378}) > > at /usr/src/lib/libc/stdio/vfprintf.c:713 > > #4 0x2015a064 in vasprintf_l (str=3D0xbfffe378, locale=3D0x201ec620, > > fmt=3D0xeec8 "%.1f") at /usr/src/lib/libc/stdio/vasprintf.c:59 > > #5 0x2015a130 in vasprintf (str=3D0xbfffe378, fmt=3D0xeec8 "%.1f") > > at /usr/src/lib/libc/stdio/vasprintf.c:73 > > #6 0x20158748 in asprintf (s=3D, > > fmt=3D0x20a26338 =20 > > "=BARX=BA=C3=E8\037\227=E3\231a=F5Zu\020=EF=E9\031=FD=CB\220\001=F9=EA= =C6=DB=A9iM\001=BC=B5=EEJ=CD=B1 =20 > > =CF=C6=C3=A9=D3.=D0\017$)=F6=E4\005=E3eZX=B1.Z&\004 \005=D7\005") > > at /usr/src/lib/libc/stdio/asprintf.c:52 > > #7 0x0000b924 in pmem (k=3D, ve=3D > optimized out>) at /usr/src/bin/ps/print.c:669 > > #8 0x0000d014 in $a () at /usr/src/bin/ps/ps.c:1134 > > #9 0x0000d014 in $a () at /usr/src/bin/ps/ps.c:1134 > >=20 > > Is it possible this gives an endless loop on armv5? >=20 > This is good info, thanks. We've been digging into it a bit more on > irc. One thing I determined that I'll mention so it saves you some > grief... you were lucky to get that backtrace, because of all the > "value optimized out" stuff. If you build the library with -O0 to > prevent that, the backtrace will contain floating point numbers. > Then because gdb uses the libc code we're trying to debug to format > floating point numbers, gdb locks up. The issue causing the endless loop is that the layout of double precision floating-point values appears to have changed. I have just committed r255361 which should fix the issue. Andrew From owner-freebsd-arm@FreeBSD.ORG Sat Sep 7 14:19:28 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 85C8BA3E for ; Sat, 7 Sep 2013 14:19:28 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E960242A for ; Sat, 7 Sep 2013 14:19:28 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r87EJLtQ018757 for ; Sat, 7 Sep 2013 10:19:26 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <522B35E9.2000002@m5p.com> Date: Sat, 07 Sep 2013 10:19:21 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: mmcsd on RPi Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sat, 07 Sep 2013 10:19:26 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 14:19:28 -0000 While performing "disk" operations in the process of building ports on my Raspberry Pi, I observe idle times in the 80-98% range, with the processes doing the work in the biowr or biord states in the "top" display. Interrupt time varies from 1-8% with system time in the 1-3% range. Could this be due to my having a crappy SD card, or is it inherent in the current mmcsd driver on ARM? Is there anything I can do to help speed up the driver? My continuing thanks go to the many developers on the ARM project, and especially the ones who have made the Raspberry Pi a viable FreeBSD platform. -- George From owner-freebsd-arm@FreeBSD.ORG Sat Sep 7 14:40:40 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E1E94DE7 for ; Sat, 7 Sep 2013 14:40:40 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B882B2505 for ; Sat, 7 Sep 2013 14:40:40 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VIJgl-000ACh-Cd; Sat, 07 Sep 2013 14:40:39 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r87EeaAt074549; Sat, 7 Sep 2013 08:40:36 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/esfIKcbHkW+nG0ZbG7Gwg Subject: Re: mmcsd on RPi From: Ian Lepore To: George Mitchell In-Reply-To: <522B35E9.2000002@m5p.com> References: <522B35E9.2000002@m5p.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 07 Sep 2013 08:40:36 -0600 Message-ID: <1378564836.1111.506.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 14:40:40 -0000 On Sat, 2013-09-07 at 10:19 -0400, George Mitchell wrote: > While performing "disk" operations in the process of building ports on > my Raspberry Pi, I observe idle times in the 80-98% range, with the > processes doing the work in the biowr or biord states in the "top" > display. Interrupt time varies from 1-8% with system time in the 1-3% > range. Could this be due to my having a crappy SD card, or is it > inherent in the current mmcsd driver on ARM? Is there anything I can > do to help speed up the driver? > > My continuing thanks go to the many developers on the ARM project, and > especially the ones who have made the Raspberry Pi a viable FreeBSD > platform. -- George The sd driver on the rpi is in pretty good shape -- it does multi-block IO and uses DMA. A different card may perform better. Counter- intuitively, an older/smaller card may be better than the very latest. Random small writes are the worst-case scenario for sd cards, it drives them into doing a non-trivial amount of read-modify-write internally (writing anything from 1 sector to a 64k chunk can result in read, erase, rewrite of a much larger block, often in the megabytes). Newer cards tend to be optimized for the way cameras and hd-cams write data to a fat32 filesystem. That optimization doesn't do our ufs filesystems any favors. It's not unusual when running gstat against an sd device to see IO times averaging multiple seconds per write transaction. It's really taking dozens of milliseconds per individual write, and then the system's bio queue is so backed up that it takes 10 seconds or more to retire any given write. Reads also slow down when writes get backlogged, because the sdcard can only do one thing at a time. If you can arrange to have object files written to tmpfs during builds, that'll help a lot. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Sep 7 16:31:49 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6F42DBD2; Sat, 7 Sep 2013 16:31:49 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0CF582928; Sat, 7 Sep 2013 16:31:48 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r87GVfB7019634; Sat, 7 Sep 2013 12:31:46 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <522B54ED.4090902@m5p.com> Date: Sat, 07 Sep 2013 12:31:41 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ian Lepore Subject: Re: mmcsd on RPi References: <522B35E9.2000002@m5p.com> <1378564836.1111.506.camel@revolution.hippie.lan> In-Reply-To: <1378564836.1111.506.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sat, 07 Sep 2013 12:31:47 -0400 (EDT) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 16:31:49 -0000 On 09/07/13 10:40, Ian Lepore wrote: > On Sat, 2013-09-07 at 10:19 -0400, George Mitchell wrote: >> While performing "disk" operations in the process of building ports on >> my Raspberry Pi, I observe idle times in the 80-98% range, with the >> processes doing the work in the biowr or biord states in the "top" >> display. Interrupt time varies from 1-8% with system time in the 1-3% >> range. Could this be due to my having a crappy SD card, or is it >> inherent in the current mmcsd driver on ARM? Is there anything I can >> do to help speed up the driver? >> >> My continuing thanks go to the many developers on the ARM project, and >> especially the ones who have made the Raspberry Pi a viable FreeBSD >> platform. -- George > > The sd driver on the rpi is in pretty good shape -- it does multi-block > IO and uses DMA. A different card may perform better. Counter- > intuitively, an older/smaller card may be better than the very latest. > > Random small writes are the worst-case scenario for sd cards, it drives > them into doing a non-trivial amount of read-modify-write internally > (writing anything from 1 sector to a 64k chunk can result in read, > erase, rewrite of a much larger block, often in the megabytes). Newer > cards tend to be optimized for the way cameras and hd-cams write data to > a fat32 filesystem. That optimization doesn't do our ufs filesystems > any favors. > > It's not unusual when running gstat against an sd device to see IO times > averaging multiple seconds per write transaction. It's really taking > dozens of milliseconds per individual write, and then the system's bio > queue is so backed up that it takes 10 seconds or more to retire any > given write. Reads also slow down when writes get backlogged, because > the sdcard can only do one thing at a time. > > If you can arrange to have object files written to tmpfs during builds, > that'll help a lot. > > -- Ian > Thanks for the explanation and the hint. -- George From owner-freebsd-arm@FreeBSD.ORG Sat Sep 7 20:11:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3AA24EA7 for ; Sat, 7 Sep 2013 20:11:44 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC8F6230D for ; Sat, 7 Sep 2013 20:11:43 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id jy13so2499903veb.33 for ; Sat, 07 Sep 2013 13:11:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UujoVxn3X0nlwa5BFQNuyjOyxoauvUYs3XX8diZQjc4=; b=IgOHvEdR3LpiUCuwMKBABr6QTfrvSHkoCdVhie54mRExJ9izxddbJuSHqToQUij+YM EOhPrppzC0nTqopYxXJv/ApsnxNEkTXVnqI2NKt8snRuqkeHaa4hAbJa4Z9NUicDpZ1C EhJ/4+mqitKxfYWrSH2NEv8o1iSbOTaf40sEhV60SFuaCovt9w2K8ziX+u69cprQrGS0 bau79WkaPRrLSw+p/ccsPerrub/rUEAMGAtPeRfKnkCrBI+VWSu19kinr+78nEJeno8d xlTwPMyVG0+TILhP6+24tIX4oDImEG+RRXem1lshtKQ42DWdtaaCqOAQq3xbrXDbcNJY UNkQ== X-Gm-Message-State: ALoCoQkMdg7omGB6w89M1KMWavn/5TWbuQ5s6BQyiruDRHO/6cqh3F5ELp/GArblxkd6cgBlquGJ MIME-Version: 1.0 X-Received: by 10.221.47.193 with SMTP id ut1mr9045044vcb.8.1378584696380; Sat, 07 Sep 2013 13:11:36 -0700 (PDT) Received: by 10.58.56.195 with HTTP; Sat, 7 Sep 2013 13:11:36 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 Sep 2013 22:11:36 +0200 Message-ID: Subject: Re: stream benchmarking on RPi From: Zbigniew Bodek To: Jia-Shiun Li Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 20:11:44 -0000 2013/9/6 Jia-Shiun Li > On Fri, Sep 6, 2013 at 6:37 AM, Zbigniew Bodek wrote: > > Hello Jia-Shiun. > > > > Thanks for your effort in testing. > > I am actually in the middle of superpages tests and another benchmark and > > set of > > results will be very helpful especially for comparison. > > > > Just for the record: did you enable superpages for your kernel? > > SP are not yet enabled by default, therefore one needs to set > > vm.pmap.sp_enabled to non-zero value in loader.conf (if you are using > > loader) > > or set this value in src by editing sys/arm/arm/pmap-v6.c -> sp_enabled. > > > > Nevertheless I've made short tests on Armada XP (clang). > > I used two array sizes (default and 2 x default). I also made few runs to > > ensure > > that the results are steady. > > Please check below (improvement in copy can be seen but from what one can > > observe via sysctl vm.pmap.section not so many superpages are "requested" > > during the test): > > Yes I confirmed that superpages was not enabled yet. I thought it was on > by default. Should have paid more attention. Then the improvement I've > seen can also attribute to someone else. Any nominees? ;) > > after enabling it in loader.rc ("set vm.pmap.sp_enabled=1"), the > benchmark did not see big difference. Like your results, > differences are visible, but not big. > ------------------------------------------------------------- > Function Best Rate MB/s Avg time Min time Max time > Copy: 372.6 0.043278 0.042943 0.043590 > Scale: 31.1 0.529411 0.514686 0.545614 > Add: 69.2 0.363791 0.346574 0.381367 > Triad: 27.4 0.909578 0.875739 0.995989 > ------------------------------------------------------------- > > sp did only have a few activities. I suppose it to be more obvious for > usages heavily sporting and fragmenting memory, rather than > sequential large block accesses like stream did? After several > stream runs: > # sysctl vm.pmap.section > vm.pmap.section.demotions: 0 > vm.pmap.section.mappings: 0 > vm.pmap.section.p_failures: 120 > vm.pmap.section.promotions: 277 > > BTW I modified the array size from 10m to 1m, otherwise it will allocate > more than 200MB/s and run for several minutes. It should not affect > result much on processors having speed like this . > > I was checking if there is anything can be done to improve performance > of RPi. Building world takes days and nights. (But works! Ya!) > For stream it looks more like being bound to some OS/compiler/etc. > usage rather than hard limit of hardware. Let's see what else can be found. > > Hello Jia-Shiun. I was looking for similar benchmark that will not depend on floating point and I found this: http://alasir.com/software/ramspeed/ The idea seems to be the same as the stream benchmark but you have option to not use FP. I've actually made some tests on my ARM and here are the results (default benchmark settings): ./ramsmp -b3 RAMspeed/SMP (GENERIC) v3.5.0 by Rhett M. Hollander and Paul V. Bolotoff, 2002-09 8Gb per pass mode, 2 processes INTEGER Copy: 1769.56 MB/s INTEGER Scale: 1211.91 MB/s INTEGER Add: 1735.90 MB/s INTEGER Triad: 1468.31 MB/s --- INTEGER AVERAGE: 1546.42 MB/s ./ramsmp -b6 RAMspeed/SMP (GENERIC) v3.5.0 by Rhett M. Hollander and Paul V. Bolotoff, 2002-09 8Gb per pass mode, 2 processes FL-POINT Copy: 2003.85 MB/s FL-POINT Scale: 104.86 MB/s FL-POINT Add: 123.27 MB/s FL-POINT Triad: 68.53 MB/s --- FL-POINT AVERAGE: 575.13 MB/s Best regards Zbigniew Bodek From owner-freebsd-arm@FreeBSD.ORG Sat Sep 7 23:28:30 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DA1E223F; Sat, 7 Sep 2013 23:28:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8EE662ABA; Sat, 7 Sep 2013 23:28:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r87NSNcm000778; Sat, 7 Sep 2013 19:28:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r87NSNHi000766; Sat, 7 Sep 2013 23:28:23 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 7 Sep 2013 23:28:23 GMT Message-Id: <201309072328.r87NSNHi000766@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 23:28:30 -0000 TB --- 2013-09-07 18:20:21 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-09-07 18:20:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-09-07 18:20:21 - starting HEAD tinderbox run for arm/arm TB --- 2013-09-07 18:20:21 - cleaning the object tree TB --- 2013-09-07 18:29:47 - /usr/local/bin/svn stat /src TB --- 2013-09-07 18:29:51 - At svn revision 255367 TB --- 2013-09-07 18:29:52 - building world TB --- 2013-09-07 18:29:52 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 18:29:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 18:29:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 18:29:52 - SRCCONF=/dev/null TB --- 2013-09-07 18:29:52 - TARGET=arm TB --- 2013-09-07 18:29:52 - TARGET_ARCH=arm TB --- 2013-09-07 18:29:52 - TZ=UTC TB --- 2013-09-07 18:29:52 - __MAKE_CONF=/dev/null TB --- 2013-09-07 18:29:52 - cd /src TB --- 2013-09-07 18:29:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Sep 7 18:29:59 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Sep 7 21:31:42 UTC 2013 TB --- 2013-09-07 21:31:42 - generating LINT kernel config TB --- 2013-09-07 21:31:42 - cd /src/sys/arm/conf TB --- 2013-09-07 21:31:42 - /usr/bin/make -B LINT TB --- 2013-09-07 21:31:42 - cd /src/sys/arm/conf TB --- 2013-09-07 21:31:42 - /usr/sbin/config -m LINT TB --- 2013-09-07 21:31:42 - building LINT kernel TB --- 2013-09-07 21:31:42 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 21:31:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 21:31:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 21:31:42 - SRCCONF=/dev/null TB --- 2013-09-07 21:31:42 - TARGET=arm TB --- 2013-09-07 21:31:42 - TARGET_ARCH=arm TB --- 2013-09-07 21:31:42 - TZ=UTC TB --- 2013-09-07 21:31:42 - __MAKE_CONF=/dev/null TB --- 2013-09-07 21:31:42 - cd /src TB --- 2013-09-07 21:31:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 7 21:31:42 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Sep 7 21:55:54 UTC 2013 TB --- 2013-09-07 21:55:54 - cd /src/sys/arm/conf TB --- 2013-09-07 21:55:54 - /usr/sbin/config -m AC100 TB --- 2013-09-07 21:55:54 - skipping AC100 kernel TB --- 2013-09-07 21:55:54 - cd /src/sys/arm/conf TB --- 2013-09-07 21:55:54 - /usr/sbin/config -m ARMADAXP TB --- 2013-09-07 21:55:54 - skipping ARMADAXP kernel TB --- 2013-09-07 21:55:54 - cd /src/sys/arm/conf TB --- 2013-09-07 21:55:54 - /usr/sbin/config -m ARNDALE TB --- 2013-09-07 21:55:54 - skipping ARNDALE kernel TB --- 2013-09-07 21:55:54 - cd /src/sys/arm/conf TB --- 2013-09-07 21:55:54 - /usr/sbin/config -m ATMEL TB --- 2013-09-07 21:55:54 - building ATMEL kernel TB --- 2013-09-07 21:55:54 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 21:55:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 21:55:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 21:55:54 - SRCCONF=/dev/null TB --- 2013-09-07 21:55:54 - TARGET=arm TB --- 2013-09-07 21:55:54 - TARGET_ARCH=arm TB --- 2013-09-07 21:55:54 - TZ=UTC TB --- 2013-09-07 21:55:54 - __MAKE_CONF=/dev/null TB --- 2013-09-07 21:55:54 - cd /src TB --- 2013-09-07 21:55:54 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Sat Sep 7 21:55:54 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Sat Sep 7 21:59:44 UTC 2013 TB --- 2013-09-07 21:59:44 - cd /src/sys/arm/conf TB --- 2013-09-07 21:59:44 - /usr/sbin/config -m AVILA TB --- 2013-09-07 21:59:44 - skipping AVILA kernel TB --- 2013-09-07 21:59:44 - cd /src/sys/arm/conf TB --- 2013-09-07 21:59:44 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-09-07 21:59:44 - skipping BEAGLEBONE kernel TB --- 2013-09-07 21:59:44 - cd /src/sys/arm/conf TB --- 2013-09-07 21:59:44 - /usr/sbin/config -m BWCT TB --- 2013-09-07 21:59:44 - building BWCT kernel TB --- 2013-09-07 21:59:44 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 21:59:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 21:59:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 21:59:44 - SRCCONF=/dev/null TB --- 2013-09-07 21:59:44 - TARGET=arm TB --- 2013-09-07 21:59:44 - TARGET_ARCH=arm TB --- 2013-09-07 21:59:44 - TZ=UTC TB --- 2013-09-07 21:59:44 - __MAKE_CONF=/dev/null TB --- 2013-09-07 21:59:44 - cd /src TB --- 2013-09-07 21:59:44 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Sep 7 21:59:44 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Sat Sep 7 22:02:21 UTC 2013 TB --- 2013-09-07 22:02:21 - cd /src/sys/arm/conf TB --- 2013-09-07 22:02:21 - /usr/sbin/config -m CAMBRIA TB --- 2013-09-07 22:02:21 - skipping CAMBRIA kernel TB --- 2013-09-07 22:02:21 - cd /src/sys/arm/conf TB --- 2013-09-07 22:02:21 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-09-07 22:02:21 - building CNS11XXNAS kernel TB --- 2013-09-07 22:02:21 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:02:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:02:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:02:21 - SRCCONF=/dev/null TB --- 2013-09-07 22:02:21 - TARGET=arm TB --- 2013-09-07 22:02:21 - TARGET_ARCH=arm TB --- 2013-09-07 22:02:21 - TZ=UTC TB --- 2013-09-07 22:02:21 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:02:21 - cd /src TB --- 2013-09-07 22:02:21 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sat Sep 7 22:02:21 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Sat Sep 7 22:06:03 UTC 2013 TB --- 2013-09-07 22:06:03 - cd /src/sys/arm/conf TB --- 2013-09-07 22:06:03 - /usr/sbin/config -m CRB TB --- 2013-09-07 22:06:03 - skipping CRB kernel TB --- 2013-09-07 22:06:03 - cd /src/sys/arm/conf TB --- 2013-09-07 22:06:03 - /usr/sbin/config -m CUBIEBOARD TB --- 2013-09-07 22:06:03 - skipping CUBIEBOARD kernel TB --- 2013-09-07 22:06:03 - cd /src/sys/arm/conf TB --- 2013-09-07 22:06:03 - /usr/sbin/config -m CUBIEBOARD2 TB --- 2013-09-07 22:06:03 - skipping CUBIEBOARD2 kernel TB --- 2013-09-07 22:06:03 - cd /src/sys/arm/conf TB --- 2013-09-07 22:06:03 - /usr/sbin/config -m DB-78XXX TB --- 2013-09-07 22:06:03 - building DB-78XXX kernel TB --- 2013-09-07 22:06:03 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:06:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:06:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:06:03 - SRCCONF=/dev/null TB --- 2013-09-07 22:06:03 - TARGET=arm TB --- 2013-09-07 22:06:03 - TARGET_ARCH=arm TB --- 2013-09-07 22:06:03 - TZ=UTC TB --- 2013-09-07 22:06:03 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:06:03 - cd /src TB --- 2013-09-07 22:06:03 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sat Sep 7 22:06:03 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Sat Sep 7 22:09:26 UTC 2013 TB --- 2013-09-07 22:09:26 - cd /src/sys/arm/conf TB --- 2013-09-07 22:09:26 - /usr/sbin/config -m DB-88F5XXX TB --- 2013-09-07 22:09:26 - building DB-88F5XXX kernel TB --- 2013-09-07 22:09:26 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:09:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:09:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:09:26 - SRCCONF=/dev/null TB --- 2013-09-07 22:09:26 - TARGET=arm TB --- 2013-09-07 22:09:26 - TARGET_ARCH=arm TB --- 2013-09-07 22:09:26 - TZ=UTC TB --- 2013-09-07 22:09:26 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:09:26 - cd /src TB --- 2013-09-07 22:09:26 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sat Sep 7 22:09:26 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Sat Sep 7 22:12:35 UTC 2013 TB --- 2013-09-07 22:12:35 - cd /src/sys/arm/conf TB --- 2013-09-07 22:12:35 - /usr/sbin/config -m DB-88F6XXX TB --- 2013-09-07 22:12:35 - building DB-88F6XXX kernel TB --- 2013-09-07 22:12:35 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:12:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:12:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:12:35 - SRCCONF=/dev/null TB --- 2013-09-07 22:12:35 - TARGET=arm TB --- 2013-09-07 22:12:35 - TARGET_ARCH=arm TB --- 2013-09-07 22:12:35 - TZ=UTC TB --- 2013-09-07 22:12:35 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:12:35 - cd /src TB --- 2013-09-07 22:12:35 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sat Sep 7 22:12:35 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Sat Sep 7 22:15:59 UTC 2013 TB --- 2013-09-07 22:15:59 - cd /src/sys/arm/conf TB --- 2013-09-07 22:15:59 - /usr/sbin/config -m DIGI-CCWMX53 TB --- 2013-09-07 22:15:59 - skipping DIGI-CCWMX53 kernel TB --- 2013-09-07 22:15:59 - cd /src/sys/arm/conf TB --- 2013-09-07 22:15:59 - /usr/sbin/config -m DOCKSTAR TB --- 2013-09-07 22:15:59 - building DOCKSTAR kernel TB --- 2013-09-07 22:15:59 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:15:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:15:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:15:59 - SRCCONF=/dev/null TB --- 2013-09-07 22:15:59 - TARGET=arm TB --- 2013-09-07 22:15:59 - TARGET_ARCH=arm TB --- 2013-09-07 22:15:59 - TZ=UTC TB --- 2013-09-07 22:15:59 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:15:59 - cd /src TB --- 2013-09-07 22:15:59 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sat Sep 7 22:15:59 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Sat Sep 7 22:19:00 UTC 2013 TB --- 2013-09-07 22:19:00 - cd /src/sys/arm/conf TB --- 2013-09-07 22:19:00 - /usr/sbin/config -m DREAMPLUG-1001 TB --- 2013-09-07 22:19:00 - building DREAMPLUG-1001 kernel TB --- 2013-09-07 22:19:00 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:19:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:19:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:19:00 - SRCCONF=/dev/null TB --- 2013-09-07 22:19:00 - TARGET=arm TB --- 2013-09-07 22:19:00 - TARGET_ARCH=arm TB --- 2013-09-07 22:19:00 - TZ=UTC TB --- 2013-09-07 22:19:00 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:19:00 - cd /src TB --- 2013-09-07 22:19:00 - /usr/bin/make -B buildkernel KERNCONF=DREAMPLUG-1001 >>> Kernel build for DREAMPLUG-1001 started on Sat Sep 7 22:19:00 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DREAMPLUG-1001 completed on Sat Sep 7 22:24:21 UTC 2013 TB --- 2013-09-07 22:24:21 - cd /src/sys/arm/conf TB --- 2013-09-07 22:24:21 - /usr/sbin/config -m EA3250 TB --- 2013-09-07 22:24:21 - building EA3250 kernel TB --- 2013-09-07 22:24:21 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:24:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:24:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:24:21 - SRCCONF=/dev/null TB --- 2013-09-07 22:24:21 - TARGET=arm TB --- 2013-09-07 22:24:21 - TARGET_ARCH=arm TB --- 2013-09-07 22:24:21 - TZ=UTC TB --- 2013-09-07 22:24:21 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:24:21 - cd /src TB --- 2013-09-07 22:24:21 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Sat Sep 7 22:24:21 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EA3250 completed on Sat Sep 7 22:27:37 UTC 2013 TB --- 2013-09-07 22:27:37 - cd /src/sys/arm/conf TB --- 2013-09-07 22:27:37 - /usr/sbin/config -m EB9200 TB --- 2013-09-07 22:27:37 - building EB9200 kernel TB --- 2013-09-07 22:27:37 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:27:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:27:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:27:37 - SRCCONF=/dev/null TB --- 2013-09-07 22:27:37 - TARGET=arm TB --- 2013-09-07 22:27:37 - TARGET_ARCH=arm TB --- 2013-09-07 22:27:37 - TZ=UTC TB --- 2013-09-07 22:27:37 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:27:37 - cd /src TB --- 2013-09-07 22:27:37 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Sat Sep 7 22:27:37 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EB9200 completed on Sat Sep 7 22:31:02 UTC 2013 TB --- 2013-09-07 22:31:02 - cd /src/sys/arm/conf TB --- 2013-09-07 22:31:02 - /usr/sbin/config -m EFIKA_MX TB --- 2013-09-07 22:31:02 - skipping EFIKA_MX kernel TB --- 2013-09-07 22:31:02 - cd /src/sys/arm/conf TB --- 2013-09-07 22:31:02 - /usr/sbin/config -m EP80219 TB --- 2013-09-07 22:31:02 - skipping EP80219 kernel TB --- 2013-09-07 22:31:02 - cd /src/sys/arm/conf TB --- 2013-09-07 22:31:02 - /usr/sbin/config -m ETHERNUT5 TB --- 2013-09-07 22:31:02 - building ETHERNUT5 kernel TB --- 2013-09-07 22:31:02 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:31:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:31:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:31:02 - SRCCONF=/dev/null TB --- 2013-09-07 22:31:02 - TARGET=arm TB --- 2013-09-07 22:31:02 - TARGET_ARCH=arm TB --- 2013-09-07 22:31:02 - TZ=UTC TB --- 2013-09-07 22:31:02 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:31:02 - cd /src TB --- 2013-09-07 22:31:02 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Sat Sep 7 22:31:03 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ETHERNUT5 completed on Sat Sep 7 22:41:36 UTC 2013 TB --- 2013-09-07 22:41:36 - cd /src/sys/arm/conf TB --- 2013-09-07 22:41:36 - /usr/sbin/config -m GUMSTIX TB --- 2013-09-07 22:41:36 - building GUMSTIX kernel TB --- 2013-09-07 22:41:36 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:41:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:41:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:41:36 - SRCCONF=/dev/null TB --- 2013-09-07 22:41:36 - TARGET=arm TB --- 2013-09-07 22:41:36 - TARGET_ARCH=arm TB --- 2013-09-07 22:41:36 - TZ=UTC TB --- 2013-09-07 22:41:36 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:41:36 - cd /src TB --- 2013-09-07 22:41:36 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Sat Sep 7 22:41:36 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GUMSTIX completed on Sat Sep 7 22:44:49 UTC 2013 TB --- 2013-09-07 22:44:49 - cd /src/sys/arm/conf TB --- 2013-09-07 22:44:49 - /usr/sbin/config -m GUMSTIX-QEMU TB --- 2013-09-07 22:44:49 - building GUMSTIX-QEMU kernel TB --- 2013-09-07 22:44:49 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:44:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:44:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:44:49 - SRCCONF=/dev/null TB --- 2013-09-07 22:44:49 - TARGET=arm TB --- 2013-09-07 22:44:49 - TARGET_ARCH=arm TB --- 2013-09-07 22:44:49 - TZ=UTC TB --- 2013-09-07 22:44:49 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:44:49 - cd /src TB --- 2013-09-07 22:44:49 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX-QEMU >>> Kernel build for GUMSTIX-QEMU started on Sat Sep 7 22:44:49 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GUMSTIX-QEMU completed on Sat Sep 7 22:47:59 UTC 2013 TB --- 2013-09-07 22:47:59 - cd /src/sys/arm/conf TB --- 2013-09-07 22:47:59 - /usr/sbin/config -m HL200 TB --- 2013-09-07 22:47:59 - building HL200 kernel TB --- 2013-09-07 22:47:59 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:47:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:47:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:47:59 - SRCCONF=/dev/null TB --- 2013-09-07 22:47:59 - TARGET=arm TB --- 2013-09-07 22:47:59 - TARGET_ARCH=arm TB --- 2013-09-07 22:47:59 - TZ=UTC TB --- 2013-09-07 22:47:59 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:47:59 - cd /src TB --- 2013-09-07 22:47:59 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Sat Sep 7 22:47:59 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for HL200 completed on Sat Sep 7 22:51:35 UTC 2013 TB --- 2013-09-07 22:51:35 - cd /src/sys/arm/conf TB --- 2013-09-07 22:51:35 - /usr/sbin/config -m HL201 TB --- 2013-09-07 22:51:35 - building HL201 kernel TB --- 2013-09-07 22:51:35 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:51:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:51:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:51:35 - SRCCONF=/dev/null TB --- 2013-09-07 22:51:35 - TARGET=arm TB --- 2013-09-07 22:51:35 - TARGET_ARCH=arm TB --- 2013-09-07 22:51:35 - TZ=UTC TB --- 2013-09-07 22:51:35 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:51:35 - cd /src TB --- 2013-09-07 22:51:35 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Sat Sep 7 22:51:35 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for HL201 completed on Sat Sep 7 22:54:47 UTC 2013 TB --- 2013-09-07 22:54:47 - cd /src/sys/arm/conf TB --- 2013-09-07 22:54:47 - /usr/sbin/config -m IQ31244 TB --- 2013-09-07 22:54:47 - skipping IQ31244 kernel TB --- 2013-09-07 22:54:47 - cd /src/sys/arm/conf TB --- 2013-09-07 22:54:47 - /usr/sbin/config -m KB920X TB --- 2013-09-07 22:54:47 - building KB920X kernel TB --- 2013-09-07 22:54:47 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:54:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:54:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:54:47 - SRCCONF=/dev/null TB --- 2013-09-07 22:54:47 - TARGET=arm TB --- 2013-09-07 22:54:47 - TARGET_ARCH=arm TB --- 2013-09-07 22:54:47 - TZ=UTC TB --- 2013-09-07 22:54:47 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:54:47 - cd /src TB --- 2013-09-07 22:54:47 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Sat Sep 7 22:54:47 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for KB920X completed on Sat Sep 7 22:58:32 UTC 2013 TB --- 2013-09-07 22:58:32 - cd /src/sys/arm/conf TB --- 2013-09-07 22:58:32 - /usr/sbin/config -m LN2410SBC TB --- 2013-09-07 22:58:32 - building LN2410SBC kernel TB --- 2013-09-07 22:58:32 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 22:58:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 22:58:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 22:58:32 - SRCCONF=/dev/null TB --- 2013-09-07 22:58:32 - TARGET=arm TB --- 2013-09-07 22:58:32 - TARGET_ARCH=arm TB --- 2013-09-07 22:58:32 - TZ=UTC TB --- 2013-09-07 22:58:32 - __MAKE_CONF=/dev/null TB --- 2013-09-07 22:58:32 - cd /src TB --- 2013-09-07 22:58:32 - /usr/bin/make -B buildkernel KERNCONF=LN2410SBC >>> Kernel build for LN2410SBC started on Sat Sep 7 22:58:32 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LN2410SBC completed on Sat Sep 7 23:01:30 UTC 2013 TB --- 2013-09-07 23:01:30 - cd /src/sys/arm/conf TB --- 2013-09-07 23:01:30 - /usr/sbin/config -m NSLU TB --- 2013-09-07 23:01:30 - skipping NSLU kernel TB --- 2013-09-07 23:01:30 - cd /src/sys/arm/conf TB --- 2013-09-07 23:01:30 - /usr/sbin/config -m PANDABOARD TB --- 2013-09-07 23:01:30 - skipping PANDABOARD kernel TB --- 2013-09-07 23:01:30 - cd /src/sys/arm/conf TB --- 2013-09-07 23:01:30 - /usr/sbin/config -m QILA9G20 TB --- 2013-09-07 23:01:30 - building QILA9G20 kernel TB --- 2013-09-07 23:01:30 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 23:01:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 23:01:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 23:01:30 - SRCCONF=/dev/null TB --- 2013-09-07 23:01:30 - TARGET=arm TB --- 2013-09-07 23:01:30 - TARGET_ARCH=arm TB --- 2013-09-07 23:01:30 - TZ=UTC TB --- 2013-09-07 23:01:30 - __MAKE_CONF=/dev/null TB --- 2013-09-07 23:01:30 - cd /src TB --- 2013-09-07 23:01:30 - /usr/bin/make -B buildkernel KERNCONF=QILA9G20 >>> Kernel build for QILA9G20 started on Sat Sep 7 23:01:30 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for QILA9G20 completed on Sat Sep 7 23:04:47 UTC 2013 TB --- 2013-09-07 23:04:47 - cd /src/sys/arm/conf TB --- 2013-09-07 23:04:47 - /usr/sbin/config -m RPI-B TB --- 2013-09-07 23:04:47 - skipping RPI-B kernel TB --- 2013-09-07 23:04:47 - cd /src/sys/arm/conf TB --- 2013-09-07 23:04:47 - /usr/sbin/config -m SAM9260EK TB --- 2013-09-07 23:04:47 - building SAM9260EK kernel TB --- 2013-09-07 23:04:47 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 23:04:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 23:04:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 23:04:47 - SRCCONF=/dev/null TB --- 2013-09-07 23:04:47 - TARGET=arm TB --- 2013-09-07 23:04:47 - TARGET_ARCH=arm TB --- 2013-09-07 23:04:47 - TZ=UTC TB --- 2013-09-07 23:04:47 - __MAKE_CONF=/dev/null TB --- 2013-09-07 23:04:47 - cd /src TB --- 2013-09-07 23:04:47 - /usr/bin/make -B buildkernel KERNCONF=SAM9260EK >>> Kernel build for SAM9260EK started on Sat Sep 7 23:04:47 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for SAM9260EK completed on Sat Sep 7 23:15:47 UTC 2013 TB --- 2013-09-07 23:15:47 - cd /src/sys/arm/conf TB --- 2013-09-07 23:15:47 - /usr/sbin/config -m SAM9G20EK TB --- 2013-09-07 23:15:47 - building SAM9G20EK kernel TB --- 2013-09-07 23:15:47 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 23:15:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 23:15:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 23:15:47 - SRCCONF=/dev/null TB --- 2013-09-07 23:15:47 - TARGET=arm TB --- 2013-09-07 23:15:47 - TARGET_ARCH=arm TB --- 2013-09-07 23:15:47 - TZ=UTC TB --- 2013-09-07 23:15:47 - __MAKE_CONF=/dev/null TB --- 2013-09-07 23:15:47 - cd /src TB --- 2013-09-07 23:15:47 - /usr/bin/make -B buildkernel KERNCONF=SAM9G20EK >>> Kernel build for SAM9G20EK started on Sat Sep 7 23:15:48 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for SAM9G20EK completed on Sat Sep 7 23:18:58 UTC 2013 TB --- 2013-09-07 23:18:58 - cd /src/sys/arm/conf TB --- 2013-09-07 23:18:58 - /usr/sbin/config -m SAM9X25EK TB --- 2013-09-07 23:18:58 - building SAM9X25EK kernel TB --- 2013-09-07 23:18:58 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 23:18:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 23:18:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 23:18:58 - SRCCONF=/dev/null TB --- 2013-09-07 23:18:58 - TARGET=arm TB --- 2013-09-07 23:18:58 - TARGET_ARCH=arm TB --- 2013-09-07 23:18:58 - TZ=UTC TB --- 2013-09-07 23:18:58 - __MAKE_CONF=/dev/null TB --- 2013-09-07 23:18:58 - cd /src TB --- 2013-09-07 23:18:58 - /usr/bin/make -B buildkernel KERNCONF=SAM9X25EK >>> Kernel build for SAM9X25EK started on Sat Sep 7 23:18:58 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for SAM9X25EK completed on Sat Sep 7 23:21:56 UTC 2013 TB --- 2013-09-07 23:21:56 - cd /src/sys/arm/conf TB --- 2013-09-07 23:21:56 - /usr/sbin/config -m SHEEVAPLUG TB --- 2013-09-07 23:21:56 - building SHEEVAPLUG kernel TB --- 2013-09-07 23:21:56 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 23:21:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 23:21:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 23:21:56 - SRCCONF=/dev/null TB --- 2013-09-07 23:21:56 - TARGET=arm TB --- 2013-09-07 23:21:56 - TARGET_ARCH=arm TB --- 2013-09-07 23:21:56 - TZ=UTC TB --- 2013-09-07 23:21:56 - __MAKE_CONF=/dev/null TB --- 2013-09-07 23:21:56 - cd /src TB --- 2013-09-07 23:21:56 - /usr/bin/make -B buildkernel KERNCONF=SHEEVAPLUG >>> Kernel build for SHEEVAPLUG started on Sat Sep 7 23:21:56 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for SHEEVAPLUG completed on Sat Sep 7 23:24:58 UTC 2013 TB --- 2013-09-07 23:24:58 - cd /src/sys/arm/conf TB --- 2013-09-07 23:24:58 - /usr/sbin/config -m SIMICS TB --- 2013-09-07 23:24:58 - building SIMICS kernel TB --- 2013-09-07 23:24:58 - CROSS_BUILD_TESTING=YES TB --- 2013-09-07 23:24:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-09-07 23:24:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-09-07 23:24:58 - SRCCONF=/dev/null TB --- 2013-09-07 23:24:58 - TARGET=arm TB --- 2013-09-07 23:24:58 - TARGET_ARCH=arm TB --- 2013-09-07 23:24:58 - TZ=UTC TB --- 2013-09-07 23:24:58 - __MAKE_CONF=/dev/null TB --- 2013-09-07 23:24:58 - cd /src TB --- 2013-09-07 23:24:58 - /usr/bin/make -B buildkernel KERNCONF=SIMICS >>> Kernel build for SIMICS started on Sat Sep 7 23:24:58 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] pseudo_rng.o:(.data+0x3c): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x44): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x74): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x78): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x84): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x8c): more undefined references to `random_null_func' follow random_adaptors.o: In function `random_sysctl_active_adaptor_handler': /src/sys/dev/random/random_adaptors.c:233: undefined reference to `random_get_active_adaptor' *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/SIMICS *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-09-07 23:28:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-09-07 23:28:23 - ERROR: failed to build SIMICS kernel TB --- 2013-09-07 23:28:23 - 13762.27 user 2777.03 system 18481.66 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full