From owner-freebsd-arm@FreeBSD.ORG Sun Jan 5 03:17:49 2014 Return-Path: Delivered-To: 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 ESMTPS id ECFDFDE1; Sun, 5 Jan 2014 03:17:48 +0000 (UTC) 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 A882F19E5; Sun, 5 Jan 2014 03:17:48 +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 s053Hl1R077550; Sat, 4 Jan 2014 22:17:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s053Hl04077548; Sun, 5 Jan 2014 03:17:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Jan 2014 03:17:47 GMT Message-Id: <201401050317.s053Hl04077548@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 03:17:49 -0000 TB --- 2014-01-05 00:10:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-05 00:10:20 - 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 --- 2014-01-05 00:10:20 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-05 00:10:20 - cleaning the object tree TB --- 2014-01-05 00:12:59 - /usr/local/bin/svn stat /src TB --- 2014-01-05 00:13:02 - At svn revision 260309 TB --- 2014-01-05 00:13:03 - building world TB --- 2014-01-05 00:13:03 - CROSS_BUILD_TESTING=YES TB --- 2014-01-05 00:13:03 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-05 00:13:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-05 00:13:03 - SRCCONF=/dev/null TB --- 2014-01-05 00:13:03 - TARGET=arm TB --- 2014-01-05 00:13:03 - TARGET_ARCH=arm TB --- 2014-01-05 00:13:03 - TZ=UTC TB --- 2014-01-05 00:13:03 - __MAKE_CONF=/dev/null TB --- 2014-01-05 00:13:03 - cd /src TB --- 2014-01-05 00:13:03 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Jan 5 00:13:10 UTC 2014 >>> 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 Sun Jan 5 03:17:16 UTC 2014 TB --- 2014-01-05 03:17:16 - generating LINT kernel config TB --- 2014-01-05 03:17:16 - cd /src/sys/arm/conf TB --- 2014-01-05 03:17:16 - /usr/bin/make -B LINT TB --- 2014-01-05 03:17:16 - cd /src/sys/arm/conf TB --- 2014-01-05 03:17:16 - /usr/sbin/config -m LINT TB --- 2014-01-05 03:17:17 - building LINT kernel TB --- 2014-01-05 03:17:17 - CROSS_BUILD_TESTING=YES TB --- 2014-01-05 03:17:17 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-05 03:17:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-05 03:17:17 - SRCCONF=/dev/null TB --- 2014-01-05 03:17:17 - TARGET=arm TB --- 2014-01-05 03:17:17 - TARGET_ARCH=arm TB --- 2014-01-05 03:17:17 - TZ=UTC TB --- 2014-01-05 03:17:17 - __MAKE_CONF=/dev/null TB --- 2014-01-05 03:17:17 - cd /src TB --- 2014-01-05 03:17:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 5 03:17:17 UTC 2014 >>> 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 [...] machine -> /src/sys/arm/include cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -ffreestanding /src/sys/arm/arm/genassym.c In file included from /src/sys/arm/arm/genassym.c:48: In file included from ./machine/intr.h:71: /src/sys/sys/bus.h:585:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error 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 --- 2014-01-05 03:17:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-05 03:17:47 - ERROR: failed to build LINT kernel TB --- 2014-01-05 03:17:47 - 8693.75 user 1651.91 system 11246.97 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Jan 5 04:17:21 2014 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 ESMTPS id 326E1282 for ; Sun, 5 Jan 2014 04:17:21 +0000 (UTC) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B9D311DCC for ; Sun, 5 Jan 2014 04:17:20 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id c13so7249592eek.2 for ; Sat, 04 Jan 2014 20:17:19 -0800 (PST) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=G0jMdndS1JRr7U/MlK+2gmfxw38Cy6Vi5STSVr8xgGY=; b=WrXp1piwr7aO5btfezOBA1iJvVURtbd7n36mxutZpGS5Irsv6tH69AaVIceiPP4kpB EhJr5EKUVxbxSW66wpwkBteVie8zzM85PFgEdobHYf/fqmNVOWx2u9oRZco/VDlZK+QS Kl2psAzGjw8/vKX0LganUeMXQQpDniUZWTBpKbbgS8Mi8v0eraeaOQLGqoEbHrY8uotq ObvoW62ei0549UAsNNTzbho4FZsD6igF/LFOToUHzcQaAJqwhqrylEObKFGl+ObiWik3 D/6TpS50hmIaxSVvjKZIbJb8PUP3KxU/6xBIXSxo/aClC+cCg2RgraUYBj08yHfSYwAS Eqvw== X-Received: by 10.15.82.136 with SMTP id a8mr9572620eez.81.1388895439028; Sat, 04 Jan 2014 20:17:19 -0800 (PST) Received: from macbook-pro.local (ip-109-91-109-168.unitymediagroup.de. [109.91.109.168]) by mx.google.com with ESMTPSA id 1sm158789538eeg.4.2014.01.04.20.17.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jan 2014 20:17:17 -0800 (PST) Message-ID: <52C8DCCA.9050908@googlemail.com> Date: Sun, 05 Jan 2014 05:17:14 +0100 From: "army.of.root" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Markus Pfeiffer , freebsd-arm@freebsd.org Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) References: <20131231211054.GA90299@moore.morphism.de> In-Reply-To: <20131231211054.GA90299@moore.morphism.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 04:17:21 -0000 Am 31/12/13 22:10, schrieb Markus Pfeiffer: > Hi all, > > I managed "fixing" it by editing the dockstar.dts file and putting for ranges: > > ranges = <0x0 0x2f 0xf9300000 0x00100000> > > Now I just have to figure out why this "fixes" it, and what damage that patch > does. > I also have some pathces for the LED on the dockstar which will tip up in my > github soon. > > Cheers, > markus > Hello there, I ran into the same Problem back in September, though I had no clue how to fix it. But while work on the dockstar.dts file is done, maybe someone could work in this http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/181975 Thanks for fixing the dockstar :D I always wanted to run one of mine with FBSD 10. Best Regards From owner-freebsd-arm@FreeBSD.ORG Sun Jan 5 13:40:56 2014 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 ESMTPS id 0BB6A45D for ; Sun, 5 Jan 2014 13:40:56 +0000 (UTC) Received: from lamora.getmail.no (lamora.getmail.no [84.210.184.7]) by mx1.freebsd.org (Postfix) with ESMTP id AB20410A4 for ; Sun, 5 Jan 2014 13:40:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 373F91B3F6 for ; Sun, 5 Jan 2014 14:40:45 +0100 (CET) X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_KHOP_THREADED=-0.01, T_NICE_REPLY_A=0.01, T_UNKNOWN_ORIGIN=0.01] autolearn=ham Authentication-Results: lamora.get.c.bitbit.net (amavisd-new); dkim=pass (1024-bit key) header.d=getmail.no Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QlRSiVSAB1Yx for ; Sun, 5 Jan 2014 14:40:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 9658D1B3F8 for ; Sun, 5 Jan 2014 14:40:44 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.7.1 lamora.getmail.no 9658D1B3F8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1388929244; bh=eZW5Kj0N7z6zKQJY4/FijzPHo7EYIL0tlyq0brWJ3+I=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=1im1S1md2N8s6REJAxAbJFqiC0d4/xfJ5JJhOnKDiQvEtyA8uqEKh88wxkJORiqYF 26V6BAV5pkhuHs/duzyXbvoddlnKDWk6wCoF0tzSIlfE4ZFUGwHHtXO5k805QSA3e5 CdV51QusazWDJEbItbdMkwBucx1odhXDjqF+bHVA= X-Virus-Scanned: amavisd-new at Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rZf3Hj4lmO8J for ; Sun, 5 Jan 2014 14:40:44 +0100 (CET) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by lamora.getmail.no (Postfix) with ESMTPSA id 70D3B1B3F6 for ; Sun, 5 Jan 2014 14:40:44 +0100 (CET) Date: Sun, 5 Jan 2014 14:40:44 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) Message-Id: <20140105144044.4fe6b8e063a664e4010c4cc4@getmail.no> In-Reply-To: <20140103175914.GC98342@moore.morphism.de> References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd8.4) 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 13:40:56 -0000 On Fri, 3 Jan 2014 17:59:14 +0000 Markus Pfeiffer wrote: > It does indeed work. I am a bit surprised that noone seems to be running > FreeBSD on a dockstar seriously enough to run into these problems. FWIW, my Dockstar still runs FreeBSD 8.2-stable from 2011, due to problems getting anything newer working on it[1]. Another thing, how does one set up a build environment that doesn't clobber source builds on the host? The last time I did this, I just let the Kirkwood build clobber the files on the host and fixed it afterwards. Having a permanent build environment for Kirkwood would be much nicer. > I hacked a bit on the gpio/led driver to make the LED work with gpioled, I'll > post a patch to the mailing list when it's cleaned up if that's ok. Getting the LED controlled would be very nice. References: 1) http://www.freebsd.org/cgi/query-pr.cgi?pr=arm/162159 -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Sun Jan 5 14:07:45 2014 Return-Path: Delivered-To: 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 ESMTPS id 636B86CE; Sun, 5 Jan 2014 14:07:45 +0000 (UTC) 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 2840B1327; Sun, 5 Jan 2014 14:07:45 +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 s05E7i9e059830; Sun, 5 Jan 2014 09:07:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s05E7ink059829; Sun, 5 Jan 2014 14:07:44 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Jan 2014 14:07:44 GMT Message-Id: <201401051407.s05E7ink059829@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 14:07:45 -0000 TB --- 2014-01-05 11:00:22 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-05 11:00:22 - 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 --- 2014-01-05 11:00:22 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-05 11:00:22 - cleaning the object tree TB --- 2014-01-05 11:03:10 - /usr/local/bin/svn stat /src TB --- 2014-01-05 11:03:13 - At svn revision 260317 TB --- 2014-01-05 11:03:14 - building world TB --- 2014-01-05 11:03:14 - CROSS_BUILD_TESTING=YES TB --- 2014-01-05 11:03:14 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-05 11:03:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-05 11:03:14 - SRCCONF=/dev/null TB --- 2014-01-05 11:03:14 - TARGET=arm TB --- 2014-01-05 11:03:14 - TARGET_ARCH=arm TB --- 2014-01-05 11:03:14 - TZ=UTC TB --- 2014-01-05 11:03:14 - __MAKE_CONF=/dev/null TB --- 2014-01-05 11:03:14 - cd /src TB --- 2014-01-05 11:03:14 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Jan 5 11:03:21 UTC 2014 >>> 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 Sun Jan 5 14:07:09 UTC 2014 TB --- 2014-01-05 14:07:09 - generating LINT kernel config TB --- 2014-01-05 14:07:09 - cd /src/sys/arm/conf TB --- 2014-01-05 14:07:09 - /usr/bin/make -B LINT TB --- 2014-01-05 14:07:09 - cd /src/sys/arm/conf TB --- 2014-01-05 14:07:09 - /usr/sbin/config -m LINT TB --- 2014-01-05 14:07:09 - building LINT kernel TB --- 2014-01-05 14:07:09 - CROSS_BUILD_TESTING=YES TB --- 2014-01-05 14:07:09 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-05 14:07:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-05 14:07:09 - SRCCONF=/dev/null TB --- 2014-01-05 14:07:09 - TARGET=arm TB --- 2014-01-05 14:07:09 - TARGET_ARCH=arm TB --- 2014-01-05 14:07:09 - TZ=UTC TB --- 2014-01-05 14:07:09 - __MAKE_CONF=/dev/null TB --- 2014-01-05 14:07:09 - cd /src TB --- 2014-01-05 14:07:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 5 14:07:09 UTC 2014 >>> 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 [...] machine -> /src/sys/arm/include cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -ffreestanding /src/sys/arm/arm/genassym.c In file included from /src/sys/arm/arm/genassym.c:48: In file included from ./machine/intr.h:71: /src/sys/sys/bus.h:585:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error 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 --- 2014-01-05 14:07:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-05 14:07:44 - ERROR: failed to build LINT kernel TB --- 2014-01-05 14:07:44 - 8689.45 user 1644.32 system 11241.59 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Jan 5 17:10:32 2014 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 ESMTPS id 55E523D0 for ; Sun, 5 Jan 2014 17:10:32 +0000 (UTC) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2690E1266 for ; Sun, 5 Jan 2014 17:10:31 +0000 (UTC) Received: by mail-pb0-f42.google.com with SMTP id uo5so17661430pbc.29 for ; Sun, 05 Jan 2014 09:10:25 -0800 (PST) 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=H994Ewyv7R2c47YaEYsSW89syOk24KM/MXM4nF4Pw3E=; b=FO8dgYipMOCWncnfhHBCJGQ2lGOEOc3lKFZuKgqFzxMKgW8fpQjXiqhY0bpbPQD9yp si4XAlzeYp4y6KTkxriXJZiYxfTtPDeJy17p6dPCpjAu3OF+FuBWxfzgRdjZNQlLN8KU 9x2QECd8GVSUt52KRAcG7R5fHVinTXgY71LIkRKQOhEqGFsdH+SuQ3bY5BikV6EF0SUm UQVLFRcExDXSnSVzqowoMA2yOBM58++uIg3S6bCv+m9eq9lGukdF46rvzb5Ewon4fhV5 0og/CXvuJ2plxM4646NDJl7gno6QRkizVIQwLLROHj/9e1nJwv9qmG27PFcLVf5+w2Mo C1mA== X-Gm-Message-State: ALoCoQlGOACAYXHvJVs2xG4KxthTOvzPKBeI2YChVwg+UL4X6K6Sz8El1LKb+X37mokj6W/86FCm X-Received: by 10.68.219.167 with SMTP id pp7mr117089357pbc.125.1388941825764; Sun, 05 Jan 2014 09:10:25 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id sg1sm123091975pbb.16.2014.01.05.09.10.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Jan 2014 09:10:25 -0800 (PST) Sender: Warner Losh Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20140105144044.4fe6b8e063a664e4010c4cc4@getmail.no> Date: Sun, 5 Jan 2014 10:10:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> <20140105144044.4fe6b8e063a664e4010c4cc4@getmail.no> To: Torfinn Ingolfsen X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 17:10:32 -0000 On Jan 5, 2014, at 6:40 AM, Torfinn Ingolfsen wrote: > On Fri, 3 Jan 2014 17:59:14 +0000 > Markus Pfeiffer wrote: >=20 >> It does indeed work. I am a bit surprised that noone seems to be = running >> FreeBSD on a dockstar seriously enough to run into these problems. >=20 > FWIW, my Dockstar still runs FreeBSD 8.2-stable from 2011, due to = problems getting anything newer working on it[1]. >=20 > Another thing, how does one set up a build environment that doesn't = clobber source builds on the host? > The last time I did this, I just let the Kirkwood build clobber the = files on the host and fixed it afterwards. > Having a permanent build environment for Kirkwood would be much nicer. DESTDIR? >> I hacked a bit on the gpio/led driver to make the LED work with = gpioled, I'll >> post a patch to the mailing list when it's cleaned up if that's ok. >=20 > Getting the LED controlled would be very nice. Warner From owner-freebsd-arm@FreeBSD.ORG Sun Jan 5 19:51:37 2014 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 ESMTPS id 8C60BA33 for ; Sun, 5 Jan 2014 19:51:37 +0000 (UTC) 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 5B7FE1E9D for ; Sun, 5 Jan 2014 19:51: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 1VztjT-0001C3-UX; Sun, 05 Jan 2014 19:51:36 +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 s05JpW9x026591; Sun, 5 Jan 2014 12:51:33 -0700 (MST) (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+kbHdHeabFhTaqArWhvmkq Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) From: Ian Lepore To: Torfinn Ingolfsen In-Reply-To: <20140105144044.4fe6b8e063a664e4010c4cc4@getmail.no> References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> <20140105144044.4fe6b8e063a664e4010c4cc4@getmail.no> Date: Sun, 05 Jan 2014 12:51:32 -0700 Message-ID: <1388951492.1158.317.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 19:51:37 -0000 On Sun, 2014-01-05 at 14:40 +0100, Torfinn Ingolfsen wrote: > On Fri, 3 Jan 2014 17:59:14 +0000 > Markus Pfeiffer wrote: > > > It does indeed work. I am a bit surprised that noone seems to be running > > FreeBSD on a dockstar seriously enough to run into these problems. > > FWIW, my Dockstar still runs FreeBSD 8.2-stable from 2011, due to problems getting anything newer working on it[1]. > > Another thing, how does one set up a build environment that doesn't clobber source builds on the host? > The last time I did this, I just let the Kirkwood build clobber the files on the host and fixed it afterwards. > Having a permanent build environment for Kirkwood would be much nicer. A lot of folks use the freebsd-crochet script to create images for arm systems. I've never learned to use it myself (and I usualy don't want a ready-to-flash image). I generally have a dozen or so active development "sandboxes" for different boards. For each board/project I'm working on I create a directory, and within it I have a script named "mk" and these subdirectories: config/ nfsroot/ obj/ src/ In config I put a make.conf and src.conf (even if they're empty), and a custom kernel config file if I'm not using one of the stock files. The src directory is a straight svn checkout of head or a stable branch or whatever. nfsroot is my default DESTDIR for installs; for development I tend to use nfs root. The mk script is attached. It basically sets up the usual defaults for whatever the sandbox is (kernel config name and such), then does a cd into the src directory and fires up make with whatever args I put on the command line. I can just type "mk buildworld" or "mk installkernel" or whatever and the mk script supplies the env vars and make options that never change. If I want to install to an sdcard or usb thumb drive instead of nfsroot/ I can just format and mount it and "mk installworld DESTDIR=/mnt". -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Jan 5 19:55:19 2014 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 ESMTPS id B6A48D28 for ; Sun, 5 Jan 2014 19:55:19 +0000 (UTC) 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 883071EBC for ; Sun, 5 Jan 2014 19:55:19 +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 1Vztn4-0002oR-Cc; Sun, 05 Jan 2014 19:55:18 +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 s05JtGOB026600; Sun, 5 Jan 2014 12:55:16 -0700 (MST) (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/wBiIMlYuuC3eMxOV2Yt7Y Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) From: Ian Lepore To: Torfinn Ingolfsen In-Reply-To: <1388951492.1158.317.camel@revolution.hippie.lan> References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> <20140105144044.4fe6b8e063a664e4010c4cc4@getmail.no> <1388951492.1158.317.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sun, 05 Jan 2014 12:55:16 -0700 Message-ID: <1388951716.1158.319.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 19:55:19 -0000 On Sun, 2014-01-05 at 12:51 -0700, Ian Lepore wrote: > On Sun, 2014-01-05 at 14:40 +0100, Torfinn Ingolfsen wrote: > > On Fri, 3 Jan 2014 17:59:14 +0000 > > Markus Pfeiffer wrote: > > > > > It does indeed work. I am a bit surprised that noone seems to be running > > > FreeBSD on a dockstar seriously enough to run into these problems. > > > > FWIW, my Dockstar still runs FreeBSD 8.2-stable from 2011, due to problems getting anything newer working on it[1]. > > > > Another thing, how does one set up a build environment that doesn't clobber source builds on the host? > > The last time I did this, I just let the Kirkwood build clobber the files on the host and fixed it afterwards. > > Having a permanent build environment for Kirkwood would be much nicer. > > A lot of folks use the freebsd-crochet script to create images for arm > systems. I've never learned to use it myself (and I usualy don't want a > ready-to-flash image). > > I generally have a dozen or so active development "sandboxes" for > different boards. For each board/project I'm working on I create a > directory, and within it I have a script named "mk" and these > subdirectories: > > config/ nfsroot/ obj/ src/ > > In config I put a make.conf and src.conf (even if they're empty), and a > custom kernel config file if I'm not using one of the stock files. The > src directory is a straight svn checkout of head or a stable branch or > whatever. nfsroot is my default DESTDIR for installs; for development I > tend to use nfs root. > > The mk script is attached. It basically sets up the usual defaults for > whatever the sandbox is (kernel config name and such), then does a cd > into the src directory and fires up make with whatever args I put on the > command line. I can just type "mk buildworld" or "mk installkernel" or > whatever and the mk script supplies the env vars and make options that > never change. If I want to install to an sdcard or usb thumb drive > instead of nfsroot/ I can just format and mount it and "mk installworld > DESTDIR=/mnt". > Hrm, the attachment got scrubbed, I'll just paste the mk script here: #!/bin/sh # Build beaglebone from source. case "$*" in *DESTDIR* ) insdir="$DESTDIR" ;; * ) insdir="$(pwd)/nfsroot" esac case "$*" in *installworld* | *installkernel* | *distribution* ) SUDO=sudo;; esac set -x kernel="BB" if [ -r "config/${kernel}" ] ; then ln -fs "../../../../config/${kernel}" "src/sys/arm/conf/${kernel}" fi srcconf="$(pwd)/config/src.conf" makeconf="$(pwd)/config/make.conf" objdir="$(pwd)/obj" tobjdir="${objdir}/arm.armv6/$(pwd)/src" kobjdir="${tobjdir}/sys/${kernel}" export MAKEOBJDIRPREFIX="${objdir}" cd ./src && time nice -15 ${SUDO} make -j ${MAX_JOBS:-1} \ "-DNO_CLEAN" \ "TARGET_ARCH=armv6" \ "DESTDIR=${insdir}" \ "__MAKE_CONF=${makeconf}" \ "SRCCONF=${srcconf}" \ "KERNCONF=${kernel}" \ "$@" -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Jan 5 20:49:18 2014 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 ESMTPS id AEDEC258 for ; Sun, 5 Jan 2014 20:49:18 +0000 (UTC) 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 7D120124D for ; Sun, 5 Jan 2014 20:49:18 +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 1VzudJ-00037L-D1; Sun, 05 Jan 2014 20:49:17 +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 s05KnCK5026634; Sun, 5 Jan 2014 13:49:12 -0700 (MST) (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: U2FsdGVkX19j+ci2NRsRm6pYjMyRjW9n Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) From: Ian Lepore To: "army.of.root" In-Reply-To: <52C8DCCA.9050908@googlemail.com> References: <20131231211054.GA90299@moore.morphism.de> <52C8DCCA.9050908@googlemail.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 05 Jan 2014 13:49:12 -0700 Message-ID: <1388954952.1158.324.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, Markus Pfeiffer X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 20:49:18 -0000 On Sun, 2014-01-05 at 05:17 +0100, army.of.root wrote: > Am 31/12/13 22:10, schrieb Markus Pfeiffer: > > Hi all, > > > > I managed "fixing" it by editing the dockstar.dts file and putting for ranges: > > > > ranges = <0x0 0x2f 0xf9300000 0x00100000> > > > > Now I just have to figure out why this "fixes" it, and what damage that patch > > does. > > I also have some pathces for the LED on the dockstar which will tip up in my > > github soon. > > > > Cheers, > > markus > > > > Hello there, > > I ran into the same Problem back in September, though I had no clue how to fix it. > > But while work on the dockstar.dts file is done, maybe someone could work in > this http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/181975 > > Thanks for fixing the dockstar :D I always wanted to run one of mine with FBSD 10. > > Best Regards I added the crypto config to the DOCKSTAR kernel. In your PR you said "but the state of the DOCKSTAR kernel config is pretty desolate," which I interpretted to mean that there was so little in the config the system wasn't really very useful. I added lots of devices and options to make it similar to the config for other sheeva-based systems. Adding so much stuff may go too far in the other direction, but probably it's better to have lots of stuff by default so it's easy to create a quick image and test with it, and folks can do custom configs that trim down the system if they need to. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Jan 5 20:50:02 2014 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 ESMTPS id EE6B82AD for ; Sun, 5 Jan 2014 20:50:02 +0000 (UTC) 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 CEBBC1257 for ; Sun, 5 Jan 2014 20:50:02 +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 s05Ko20W024988 for ; Sun, 5 Jan 2014 20:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s05Ko2k7024987; Sun, 5 Jan 2014 20:50:02 GMT (envelope-from gnats) Date: Sun, 5 Jan 2014 20:50:02 GMT Message-Id: <201401052050.s05Ko2k7024987@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: arm/162159: commit references a PR X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dfilter service List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 20:50:03 -0000 The following reply was made to PR arm/162159; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/162159: commit references a PR Date: Sun, 5 Jan 2014 20:44:18 +0000 (UTC) Author: ian Date: Sun Jan 5 20:44:10 2014 New Revision: 260333 URL: http://svnweb.freebsd.org/changeset/base/260333 Log: Enable the cesa security/crypto device by providing the required property in the dts source, and adding the right devices to the kernel config. Also generally bring the kernel config into line with what we have for other Marvell/Kirkwood systems (add lots of useful devices and options). One particularly notable addition amongst the kernel config changes is USB_HOST_ALIGN=32, which may help eliminate data corruption on USB drives. PR: kern/181975 arm/162159 Modified: head/sys/arm/conf/DOCKSTAR head/sys/boot/fdt/dts/dockstar.dts Modified: head/sys/arm/conf/DOCKSTAR ============================================================================== --- head/sys/arm/conf/DOCKSTAR Sun Jan 5 20:33:44 2014 (r260332) +++ head/sys/arm/conf/DOCKSTAR Sun Jan 5 20:44:10 2014 (r260333) @@ -3,73 +3,165 @@ # # $FreeBSD$ # +# http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html +# +# The handbook is also available locally in /usr/share/doc/handbook +# if you've installed the doc distribution, otherwise always see the +# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the +# latest information. +# +# An exhaustive list of options and more detailed explanations of the +# device lines is also present in the ../../conf/NOTES and NOTES files. +# If you are in doubt as to the purpose or necessity of a line, check first +# in NOTES. +# +# $FreeBSD$ +# ident DOCKSTAR + include "../mv/kirkwood/std.db88f6xxx" -options SOC_MV_KIRKWOOD +makeoptions FDT_DTS_FILE=dockstar.dts + makeoptions MODULES_OVERRIDE="" -#makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols -makeoptions WERROR="-Werror" +options SOC_MV_KIRKWOOD options SCHED_4BSD #4BSD scheduler options INET #InterNETworking options INET6 #IPv6 communications protocols +options SOFTUPDATES +options CD9660 #ISO 9660 filesystem options FFS #Berkeley Fast Filesystem -options NFSCL #New Network Filesystem Client -options NFSLOCKD #Network Lock Manager -options NFS_ROOT #NFS usable as /, requires NFSCL -options BOOTP -options BOOTP_NFSROOT -options BOOTP_NFSV3 -options BOOTP_COMPAT -options BOOTP_WIRED_TO=mge0 - -# Root fs on USB device -#options ROOTDEVNAME=\"ufs:/dev/da0a\" - +options MSDOSFS #MS DOS File System (FAT, FAT32) +options NULLFS #NULL filesystem +options TMPFS #Efficient memory filesystem options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions -options MUTEX_NOINLINE -options RWLOCK_NOINLINE -options NO_FFS_SNAPSHOT -options NO_SWAPPING +options GEOM_ELI # Disk encryption. +options GEOM_LABEL # Providers labelization. +options GEOM_PART_GPT # GPT partitioning -# Debugging -options ALT_BREAK_TO_DEBUGGER -options DDB -options KDB +# Flattened Device Tree +device fdt +options FDT +options FDT_DTB_STATIC + +# Misc pseudo devices +device bpf #Required for DHCP +device faith #IPv6-to-IPv4 relaying (translation) +device firmware #firmware(9) required for USB wlan +device gif #IPv6 and IPv4 tunneling +device loop #Network loopback +device md #Memory/malloc disk +device pty #BSD-style compatibility pseudo ttys +device random #Entropy device +device tun #Packet tunnel. +device ether #Required for all ethernet devices +device vlan #802.1Q VLAN support +device wlan #802.11 WLAN support -# Pseudo devices -device md -device random -device loop +# cam support for umass and ahci +device scbus +device pass +device da # Serial ports device uart # Networking -device ether device mge # Marvell Gigabit Ethernet controller device mii -device bpf -options HZ=1000 -options DEVICE_POLLING -device vlan +device e1000phy # USB -options USB_DEBUG # enable debug msgs -device usb -device ehci -device umass -device scbus -device pass -device da +options USB_HOST_ALIGN=32 # Align DMA to cacheline +#options USB_DEBUG # Compile in USB debug support +device usb # Basic usb support +device ehci # USB host controller +device umass # Mass storage +device uhid # Human-interface devices +device rum # Ralink Technology RT2501USB wireless NICs +device uath # Atheros AR5523 wireless NICs +device ural # Ralink Technology RT2500USB wireless NICs +device zyd # ZyDAS zb1211/zb1211b wireless NICs +device urtw # Realtek RTL8187B/L USB +device upgt # Conexant/Intersil PrismGT SoftMAC USB +device u3g # USB-based 3G modems (Option, Huawei, Sierra) + +# I2C (TWSI) +device iic +device iicbus + +# Sound +device sound +device snd_uaudio + +#crypto +device cesa # Marvell security engine +device crypto +device cryptodev + +# IPSec +device enc +options IPSEC +options IPSEC_NAT_T +options TCP_SIGNATURE #include support for RFC 2385 + +# IPFW +options IPFIREWALL +options IPFIREWALL_DEFAULT_TO_ACCEPT +options IPFIREWALL_VERBOSE +options IPFIREWALL_VERBOSE_LIMIT=100 +options IPFIREWALL_NAT +options LIBALIAS +options DUMMYNET +options IPDIVERT + +#PF +device pf +device pflog +device pfsync + +# ALTQ, required for PF +options ALTQ # Basic ALTQ support +options ALTQ_CBQ # Class Based Queueing +options ALTQ_RED # Random Early Detection +options ALTQ_RIO # RED In/Out +options ALTQ_HFSC # Hierarchical Packet Scheduler +options ALTQ_CDNR # Traffic conditioner +options ALTQ_PRIQ # Priority Queueing +options ALTQ_NOPCC # Required if the TSC is unusable +#options ALTQ_DEBUG + +# Debugging +makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols +options BREAK_TO_DEBUGGER +options ALT_BREAK_TO_DEBUGGER +options DDB +options KDB +options DIAGNOSTIC +options INVARIANTS #Enable calls of extra sanity checking +options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS +#options WITNESS #Enable checks to detect deadlocks and cycles +#options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed +#options WITNESS_KDB + +# Enable these options for nfs root configured via BOOTP. +options NFSCL #Network Filesystem Client +options NFSLOCKD #Network Lock Manager +#options NFS_ROOT #NFS usable as /, requires NFSCLIENT +#options BOOTP +#options BOOTP_NFSROOT +#options BOOTP_NFSV3 +#options BOOTP_WIRED_TO=mge0 + +# If not using BOOTP, use something like one of these... +#options ROOTDEVNAME=\"ufs:/dev/da0a\" +options ROOTDEVNAME=\"ufs:/dev/da0s1a\" +#options ROOTDEVNAME=\"ufs:/dev/da0p10\" +#options ROOTDEVNAME=\"nfs:192.168.0.254/dreamplug\" -# Flattened Device Tree -options FDT -options FDT_DTB_STATIC -makeoptions FDT_DTS_FILE=dockstar.dts Modified: head/sys/boot/fdt/dts/dockstar.dts ============================================================================== --- head/sys/boot/fdt/dts/dockstar.dts Sun Jan 5 20:33:44 2014 (r260332) +++ head/sys/boot/fdt/dts/dockstar.dts Sun Jan 5 20:44:10 2014 (r260333) @@ -209,6 +209,8 @@ reg = <0x30000 0x10000>; interrupts = <22>; interrupt-parent = <&PIC>; + + sram-handle = <&SRAM>; }; usb@50000 { _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Jan 5 21:04:11 2014 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 ESMTPS id 165CD96F; Sun, 5 Jan 2014 21:04:11 +0000 (UTC) Received: from turing.morphism.de (smtp.morphism.de [IPv6:2001:4178:4:204::25]) by mx1.freebsd.org (Postfix) with ESMTP id CC9DA1392; Sun, 5 Jan 2014 21:04:10 +0000 (UTC) Received: from localhost (moore.morphism.de [IPv6:2001:4178:4:202::136]) by turing.morphism.de (Postfix) with ESMTP id EB8D72FF3C; Sun, 5 Jan 2014 21:04:04 +0000 (UTC) Date: Sun, 5 Jan 2014 21:04:02 +0000 From: Markus Pfeiffer To: Ian Lepore Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) Message-ID: <20140105210402.GG98342@moore.morphism.de> References: <20131231211054.GA90299@moore.morphism.de> <52C8DCCA.9050908@googlemail.com> <1388954952.1158.324.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5UGlQXeG3ziZS81+" Content-Disposition: inline In-Reply-To: <1388954952.1158.324.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-arm@FreeBSD.org, "army.of.root" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Markus Pfeiffer List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 21:04:11 -0000 --5UGlQXeG3ziZS81+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Jan 05, 2014 at 01:49:12PM -0700, Ian Lepore wrote: > On Sun, 2014-01-05 at 05:17 +0100, army.of.root wrote: > > Am 31/12/13 22:10, schrieb Markus Pfeiffer: > >=20 > > Thanks for fixing the dockstar :D I always wanted to run one of mine wi= th FBSD 10. > >=20 >=20 > I added the crypto config to the DOCKSTAR kernel. In your PR you said > "but the state of the DOCKSTAR kernel config is pretty desolate," which > I interpretted to mean that there was so little in the config the system > wasn't really very useful. I added lots of devices and options to make > it similar to the config for other sheeva-based systems. =20 >=20 > Adding so much stuff may go too far in the other direction, but probably > it's better to have lots of stuff by default so it's easy to create a > quick image and test with it, and folks can do custom configs that trim > down the system if they need to. >=20 Thanks! I will test this when I have time (towards the end of the week I guess). I had added the crypto things as well, but then cut back down again= to remove moving parts, and get a minimum to work. markus --5UGlQXeG3ziZS81+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (DragonFly) iQIcBAEBAgAGBQJSycjBAAoJEBRHBRYBD4mPK4EP/1KcRRyPH/c0eQhxM15adicm Xm2rgutBiJpfxewT7dYBxKshs8QIPhk5fMyF8tWaC49QAHJXC3VBySXq7pGB7o8h ItdULH9Wt6js+ZIohqL0vKGGv01neKWaX7F5kkAAauulJjnNmwYRhcbvHLRKyCyf nFNGZk555U5hpeSehQRJICkoElzOsiDDFrZsU5gztkSbUU9PaPyqG6GmfWPcKVT1 CJqTThGPOxmfmWYo/9e3+O4oS7wYgSEesm8U5S3VEObALBPuXcUY6kPhszYS+kia /XdRx7NX2BV+8IhpETaeAyMHW4daQTCIuwTbBqFy8FLVgPXOJ1oPxTtx4FJwfxN/ 1njeJA5++dmLnXrW/sJPgrsxUDhD54coGwXTp3uWtl4TJb+GiANG/tr8zYu9s7eg pw1U81o/3CVs971uwxRoLPGvH+GNSjqw7YivoWQX6j5905goQ7ewz6R1eghQmW09 /eAMlY5jKxodHmc2nTYbEl9RXS1aWeiJHURFxlYXJ+TB/0VZRjrxtpXGmxOgv5Wu bFTGolcPK+o0NItik1SIk/NeEv031ssARYBCxRCHHiLjzYURRdBfA2czg5gIYGAn gP+oV2/GPsCSJApPb3iHQ7UQnVqA/f+tX6TvW0EBmbXcauvBPEMwvgNFsopVcB5Z ZJP7uAEKQfVhNPqYJDxy =96UV -----END PGP SIGNATURE----- --5UGlQXeG3ziZS81+-- From owner-freebsd-arm@FreeBSD.ORG Mon Jan 6 00:47:06 2014 Return-Path: Delivered-To: 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 ESMTPS id 2A43E6C5; Mon, 6 Jan 2014 00:47:06 +0000 (UTC) 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 E43D413CA; Mon, 6 Jan 2014 00:47:05 +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 s060l5mL047021; Sun, 5 Jan 2014 19:47:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s060l5dn047018; Mon, 6 Jan 2014 00:47:05 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 6 Jan 2014 00:47:05 GMT Message-Id: <201401060047.s060l5dn047018@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 00:47:06 -0000 TB --- 2014-01-05 21:40:26 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-05 21:40:26 - 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 --- 2014-01-05 21:40:26 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-05 21:40:26 - cleaning the object tree TB --- 2014-01-05 21:43:20 - /usr/local/bin/svn stat /src TB --- 2014-01-05 21:43:23 - At svn revision 260335 TB --- 2014-01-05 21:43:24 - building world TB --- 2014-01-05 21:43:24 - CROSS_BUILD_TESTING=YES TB --- 2014-01-05 21:43:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-05 21:43:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-05 21:43:24 - SRCCONF=/dev/null TB --- 2014-01-05 21:43:24 - TARGET=arm TB --- 2014-01-05 21:43:24 - TARGET_ARCH=arm TB --- 2014-01-05 21:43:24 - TZ=UTC TB --- 2014-01-05 21:43:24 - __MAKE_CONF=/dev/null TB --- 2014-01-05 21:43:24 - cd /src TB --- 2014-01-05 21:43:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Jan 5 21:43:31 UTC 2014 >>> 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 Mon Jan 6 00:46:31 UTC 2014 TB --- 2014-01-06 00:46:31 - generating LINT kernel config TB --- 2014-01-06 00:46:31 - cd /src/sys/arm/conf TB --- 2014-01-06 00:46:31 - /usr/bin/make -B LINT TB --- 2014-01-06 00:46:31 - cd /src/sys/arm/conf TB --- 2014-01-06 00:46:31 - /usr/sbin/config -m LINT TB --- 2014-01-06 00:46:31 - building LINT kernel TB --- 2014-01-06 00:46:31 - CROSS_BUILD_TESTING=YES TB --- 2014-01-06 00:46:31 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-06 00:46:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-06 00:46:31 - SRCCONF=/dev/null TB --- 2014-01-06 00:46:31 - TARGET=arm TB --- 2014-01-06 00:46:31 - TARGET_ARCH=arm TB --- 2014-01-06 00:46:31 - TZ=UTC TB --- 2014-01-06 00:46:31 - __MAKE_CONF=/dev/null TB --- 2014-01-06 00:46:31 - cd /src TB --- 2014-01-06 00:46:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 6 00:46:32 UTC 2014 >>> 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 [...] machine -> /src/sys/arm/include cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -ffreestanding /src/sys/arm/arm/genassym.c In file included from /src/sys/arm/arm/genassym.c:48: In file included from ./machine/intr.h:71: /src/sys/sys/bus.h:585:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error 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 --- 2014-01-06 00:47:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-06 00:47:05 - ERROR: failed to build LINT kernel TB --- 2014-01-06 00:47:05 - 8684.89 user 1645.23 system 11198.30 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Jan 6 11:06:44 2014 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 ESMTPS id 29191692 for ; Mon, 6 Jan 2014 11:06:44 +0000 (UTC) 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 EF2BD106F for ; Mon, 6 Jan 2014 11:06:43 +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 s06B6hRJ045176 for ; Mon, 6 Jan 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s06B6hYm045174 for freebsd-arm@FreeBSD.org; Mon, 6 Jan 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Jan 2014 11:06:43 GMT Message-Id: <201401061106.s06B6hYm045174@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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 11:06:44 -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/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI 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/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/175803 arm building xdev for arm failing 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 ports/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 32 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Jan 6 11:18:10 2014 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 ESMTPS id 538147AD; Mon, 6 Jan 2014 11:18:10 +0000 (UTC) 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 19548145A; Mon, 6 Jan 2014 11:18:10 +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 s06BI9Zc021070; Mon, 6 Jan 2014 06:18:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s06BI9XY021068; Mon, 6 Jan 2014 11:18:09 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 6 Jan 2014 11:18:09 GMT Message-Id: <201401061118.s06BI9XY021068@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 11:18:10 -0000 TB --- 2014-01-06 08:10:21 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-06 08:10: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 --- 2014-01-06 08:10:21 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-06 08:10:21 - cleaning the object tree TB --- 2014-01-06 08:14:10 - /usr/local/bin/svn stat /src TB --- 2014-01-06 08:14:14 - At svn revision 260365 TB --- 2014-01-06 08:14:15 - building world TB --- 2014-01-06 08:14:15 - CROSS_BUILD_TESTING=YES TB --- 2014-01-06 08:14:15 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-06 08:14:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-06 08:14:15 - SRCCONF=/dev/null TB --- 2014-01-06 08:14:15 - TARGET=arm TB --- 2014-01-06 08:14:15 - TARGET_ARCH=arm TB --- 2014-01-06 08:14:15 - TZ=UTC TB --- 2014-01-06 08:14:15 - __MAKE_CONF=/dev/null TB --- 2014-01-06 08:14:15 - cd /src TB --- 2014-01-06 08:14:15 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jan 6 08:14:21 UTC 2014 >>> 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 Mon Jan 6 11:17:22 UTC 2014 TB --- 2014-01-06 11:17:22 - generating LINT kernel config TB --- 2014-01-06 11:17:22 - cd /src/sys/arm/conf TB --- 2014-01-06 11:17:22 - /usr/bin/make -B LINT TB --- 2014-01-06 11:17:22 - cd /src/sys/arm/conf TB --- 2014-01-06 11:17:22 - /usr/sbin/config -m LINT TB --- 2014-01-06 11:17:22 - building LINT kernel TB --- 2014-01-06 11:17:22 - CROSS_BUILD_TESTING=YES TB --- 2014-01-06 11:17:22 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-06 11:17:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-06 11:17:22 - SRCCONF=/dev/null TB --- 2014-01-06 11:17:22 - TARGET=arm TB --- 2014-01-06 11:17:22 - TARGET_ARCH=arm TB --- 2014-01-06 11:17:22 - TZ=UTC TB --- 2014-01-06 11:17:22 - __MAKE_CONF=/dev/null TB --- 2014-01-06 11:17:22 - cd /src TB --- 2014-01-06 11:17:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 6 11:17:23 UTC 2014 >>> 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 [...] machine -> /src/sys/arm/include cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -ffreestanding /src/sys/arm/arm/genassym.c In file included from /src/sys/arm/arm/genassym.c:48: In file included from ./machine/intr.h:71: /src/sys/sys/bus.h:585:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error 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 --- 2014-01-06 11:18:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-06 11:18:09 - ERROR: failed to build LINT kernel TB --- 2014-01-06 11:18:09 - 8684.26 user 1628.12 system 11268.23 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Jan 6 14:43:45 2014 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 ESMTPS id BE01C207 for ; Mon, 6 Jan 2014 14:43:45 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d: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 80A361708 for ; Mon, 6 Jan 2014 14:43:45 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id w7so17132955qcr.25 for ; Mon, 06 Jan 2014 06:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=TB4Nn2BkbRBrZn1wOhZN/kLfNvz7q8MpKjsiGMocyoY=; b=S1fPy6GZVMas+X6aM+P0qx4yv7gfGKNRySf7OdPr7JkdsRE7/GA9u29+/moTeWuIUb fHV0w8V+tkx7Hcne/B5eDWtYEAy9EUYeVHlg4nUtxGoVVRliajujceAndx42uY69FCDI Lxk5xygOO3bTLOQRE0e7TM7TgmBIfYtH/lg/zc270MBWLUdhaawXqRXW0KVEQX3OvHFk NeCWxf4GHg1rbZ2gXkULHwdSLwB89B+QxU7lmD4AvXqy68rvlu7D9C9C5pmIw3w/WsDx kkbW9zo1aFR9oEwr4QRFK5+0eVmo0hCer51EYEtz8arTe+g7d1YFGWAvvQ9g1XafyT+v UWQQ== MIME-Version: 1.0 X-Received: by 10.229.24.4 with SMTP id t4mr177860112qcb.13.1389019424710; Mon, 06 Jan 2014 06:43:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Mon, 6 Jan 2014 06:43:44 -0800 (PST) Date: Mon, 6 Jan 2014 06:43:44 -0800 X-Google-Sender-Auth: Vo_ktYn3k_4AWE4IiVBJFosLAV0 Message-ID: Subject: Default console output on the raspberry pi? From: Adrian Chadd To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 14:43:45 -0000 Hi, I've built a crochet build of the latest -HEAD for the raspberry pi and I'm not seeing anything on HDMI. Where's the default console output going? And how do I configure it? Thanks, -a From owner-freebsd-arm@FreeBSD.ORG Mon Jan 6 15:00:39 2014 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 ESMTPS id 7F1C47D2 for ; Mon, 6 Jan 2014 15:00:39 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D079188D for ; Mon, 6 Jan 2014 15:00:39 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id cm18so3024450qab.18 for ; Mon, 06 Jan 2014 07:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=PI+RqCennbEGRw4lFK1m4QIIp/LMl32E3mS5NWYTOwk=; b=MQ0aT4xJ/Sy4HCvtFeKgqBwR03qCO9HcIS3HhfaCxCWd0XQzTQkNEqYKC9s+oACqJl IbHrqQmmQFYGp1QIk4uKaJTw8fbJGV2KFVY9Kai/9HdFygYIk9iNYt/XtjzimTPNNqxk Ks4PwGnyR/NzBoXsfJGml33XcRhrynm9/+0yFsc/JLXVQJR8V1NqnwfLE95vb92ks0t/ Lud8mKn7c7/KVkc69gbAA5ckYfz/OeJkSHYvfJ3bstgZp1j+8RoumiCOW0RiQGKQ2Cpw Ftgz1m6jxu9zk2p7A3QvrQjqLqwrlcnqFw/A4GS6tVeexob9Y880hTEXiE179PK7x+Fo +P4w== MIME-Version: 1.0 X-Received: by 10.224.13.203 with SMTP id d11mr4705175qaa.26.1389020438417; Mon, 06 Jan 2014 07:00:38 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Mon, 6 Jan 2014 07:00:38 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Jan 2014 07:00:38 -0800 X-Google-Sender-Auth: _IF8YrltwR9sY2bs4noZTB_oNto Message-ID: Subject: Re: Default console output on the raspberry pi? From: Adrian Chadd To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 15:00:39 -0000 Ignore; PEBKAP. -a On 6 January 2014 06:43, Adrian Chadd wrote: > Hi, > > I've built a crochet build of the latest -HEAD for the raspberry pi > and I'm not seeing anything on HDMI. Where's the default console > output going? And how do I configure it? > > Thanks, > > > -a From owner-freebsd-arm@FreeBSD.ORG Wed Jan 8 03:55:14 2014 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 ESMTPS id E8C2ADB5 for ; Wed, 8 Jan 2014 03:55:14 +0000 (UTC) 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 A89131667 for ; Wed, 8 Jan 2014 03:55:14 +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 1W0kEa-000N72-Ux; Wed, 08 Jan 2014 03:55:13 +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 s083tAQo029910; Tue, 7 Jan 2014 20:55:10 -0700 (MST) (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/M+vSwE3csdVPctIjM4txh Subject: Re: Fwd: Dreamplug stable/10 usb - sd file transfer corruption error - cache related? From: Ian Lepore To: Steven Lee In-Reply-To: References: <1382734990.1170.132.camel@revolution.hippie.lan> <1382738462.1170.153.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Jan 2014 20:55:10 -0700 Message-ID: <1389153310.1158.349.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 03:55:15 -0000 Oddly enough, I never forgot about this, I just never got to it until today. I put a concerted effort into getting data corruption on usb->usb copying of files and even entire filesystems, and couldn't get a glitch. I used the external sdcard (da1) and a thumb drive. I used 'mtree -ck md5' on both source and destination, then diff'd the results, and the files were all identical. I tested with 11-current (@r260393) and 10-stable (@r260394) on my DreamPlug, compiled with clang-eabi in both cases. -- Ian On Fri, 2013-10-25 at 18:40 -0700, Steven Lee wrote: > Ian, thanks for taking a look to see if you can recreate the problem. In > case it makes any difference in behavior, the > command I used for the transfer was: > > (dump -0Lf - /) | (cd /mnt/flash_root ; restore -rf -) > > with /dev/da2s2 mounted at / and /dev/da0s2 mounted at /mnt/flash_root > > Regards, > > Steve > On Fri, Oct 25, 2013 at 3:01 PM, Ian Lepore wrote: > > > That old advice was based on bugs in old code that has been fixed. I've > > just been double-checking that the various fixes are in 10 (some of them > > were things I submitted a PR for before I became a committer). I'm not > > sure about the usb driver, but there have been big changes in the dma > > cache coherency code between 9 and 10, although much of that is the > > fixes I was alluding to. > > > > Basically what you're doing is a usb->usb copy, I'll see if I can > > recreate the corruption on my dreamplug here the same way. > > > > -- Ian > > > > On Fri, 2013-10-25 at 14:38 -0700, Steven Lee wrote: > > > ---------- Forwarded message ---------- > > > From: Steven Lee > > > Date: Fri, Oct 25, 2013 at 2:37 PM > > > Subject: Re: Dreamplug stable/10 usb - sd file transfer corruption error > > - > > > cache related? > > > To: Ian Lepore > > > > > > > > > Ian, thanks for your reply. > > > > > > I am using the DREAMPLUG-1001 stock kernel config, and you are right the > > > internal sd card shows up as a usb device, /dev/da0. > > > > > > As I mentioned, I tried modifying pmap.c as per one of your suggestions > > to > > > an earlier poster / problem, but it didn't seem to help the issue. I > > > changed the pmap_pte_init_arm10() function to look like the > > > pmap_pte_init_arm9() function. > > > > > > Any other thoughts about things to try? Since it seems like this is a > > > regression between 9 and 10, are you aware of any specific cache related > > > changes to the usb driver between the branches? > > > > > > - Steve > > > > > > > > > On Fri, Oct 25, 2013 at 2:03 PM, Ian Lepore wrote: > > > > > > > On Fri, 2013-10-25 at 13:37 -0700, Steven Lee wrote: > > > > > Hello, > > > > > > > > > > In the process of upgrading my Dreamplug from the stable/9 branch to > > the > > > > > stable/10 branch, I have run into a fairly > > > > > significant file corruption problem. The steps that create this > > problem > > > > > are as follows: > > > > > > > > > > 1. Cross-compile the kernel and buildworld from the stable/10 branch > > on a > > > > > separate host. > > > > > 2. Install the kernel and installworld on a usb stick drive > > > > > 3. Boot the Dreamplug from the usb drive > > > > > > > > > > There are no problems that show up to this point, the Dreamplug boots > > > > with > > > > > no errors. > > > > > > > > > > 4. Copy the kernel from the usb drive to the internal sd card > > > > > 5. Copy the root filesystem from the usb drive to the internal sd > > card > > > > > using (dump | restore) > > > > > > > > > > It is at step 5 that the error manifests itself, as I found that > > > > > approximately 20 shell scripts in the /etc/rc.d directory > > > > > had been randomly corrupted with strings of null characters (in > > groups of > > > > > 32). I assume that the rest of the file system > > > > > was compromised in a similar fashion. The bug is repeatable, > > however the > > > > > corruption is somewhat random, so > > > > > each time different files are corrupted in different places. > > > > > > > > > > When I followed the exact same steps from the stable/9 branch, the > > > > problem > > > > > did not occur, so there is clearly some > > > > > type of regression error between the 9 and 10 branches. > > > > > > > > > > After searching through the arm mailing list, I attempted to work > > around > > > > > the problem by: > > > > > - mounting the file systems with -o noclusterr -o noclusterrw > > > > > - mounting the file systems with -o sync > > > > > - as per comments on bug arm/158950, attempted to modify the pmap.c > > > > > functions to change the cache from > > > > > write-back mode to write-through mode > > > > > > > > > > but all of these attempts were ineffective. > > > > > > > > > > Given that I am relatively new to FreeBSD, I was hoping to get any > > > > insights > > > > > as to any next steps that might make > > > > > sense in terms of either working around the problem, narrowing down > > the > > > > > bug, or any obvious rookie mistakes I > > > > > am making before I give up and revert back to the 9 branch. > > > > > > > > > > Thanks for your help! > > > > > > > > > > Regards, > > > > > > > > On my dreamplug (model 1001) both the internal and external sd cards > > are > > > > actually usb devices (they show up as /dev/da0 and da1, not mmcsd0/1). > > > > I'm not sure if that's true on all models or not. > > > > > > > > Are you using the stock kernel config (DREAMPLUG-1001)? If not, have > > > > you got "option USB_HOST_ALIGN=32" in your kernel config? > > > > > > > > Corruption in 32 byte chunks is almost always partial cacheline flush > > > > problems, but I haven't seen that happen on dreamplug for a long time > > > > (and when I did see it, it was with a sata drive). > > > > > > > > -- Ian > > > > > > > > > > > _______________________________________________ > > > 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" > > > > > > > _______________________________________________ > 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 Wed Jan 8 07:16:45 2014 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 ESMTPS id DE2CBDEB; Wed, 8 Jan 2014 07:16:44 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB38E175B; Wed, 8 Jan 2014 07:16:44 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s087Ghr3026120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2014 23:16:43 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s087GhE1026119; Tue, 7 Jan 2014 23:16:43 -0800 (PST) (envelope-from jmg) Date: Tue, 7 Jan 2014 23:16:43 -0800 From: John-Mark Gurney To: Ian Lepore , freebsd-arm@FreeBSD.org Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Message-ID: <20140108071643.GB99167@funkthat.com> Mail-Followup-To: Ian Lepore , freebsd-arm@FreeBSD.org References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131221061048.GC99167@funkthat.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 07 Jan 2014 23:16:43 -0800 (PST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 07:16:45 -0000 John-Mark Gurney wrote this message on Fri, Dec 20, 2013 at 22:10 -0800: > Ian Lepore wrote this message on Thu, Nov 21, 2013 at 01:08 +0000: > > Author: ian > > Date: Thu Nov 21 01:08:10 2013 > > New Revision: 258412 > > URL: http://svnweb.freebsd.org/changeset/base/258412 > > > > Log: > > Call cpu_setup() from the initarm() routine on platforms that don't use > > the common FDT-aware initarm() in arm/machdep.c. > > > > Pointed out by: cognet > > Pointy hat to: ian > > [...] > > > Modified: head/sys/arm/xscale/ixp425/avila_machdep.c > > ============================================================================== > > --- head/sys/arm/xscale/ixp425/avila_machdep.c Thu Nov 21 00:54:26 2013 (r258411) > > +++ head/sys/arm/xscale/ixp425/avila_machdep.c Thu Nov 21 01:08:10 2013 (r258412) > > @@ -405,6 +405,8 @@ initarm(struct arm_boot_params *abp) > > * this problem will not occur after initarm(). > > */ > > cpu_idcache_wbinv_all(); > > + cpu_setup(""); > > + > > /* ready to setup the console (XXX move earlier if possible) */ > > cninit(); > > /* > > > > So, I finally got an AVILA board (thanks Jim@netgate) to do some testing > on what stopped working... > > Turns out this commit break early output on the AVILA board... With > this commit, I get no output when booting the kernel: > RedBoot> load -b 0x200000 kernel.avila.avila > Using default protocol (TFTP) > Address offset = 0x40000000 > Entry point: 0x00200100, address range: 0x00200000-0x006aedc8 > RedBoot> go > > some previous pmap changes made the AVILA board panic... The pmap > changes were made some time between July 1st and Aug 1st, and on kernels > since then, I get: > RedBoot> go > panic: mtx_lock() of spin mutex pmap @ /usr/src.avila/sys/arm/arm/pmap.c:3677 > Uptime: 1s So, finally tracked this panic down to the switch to EABI. If I compiled kernel-toolchain from 253395 (before the EABI switch) and build a kernel from HEAD, I get: FreeBSD 11.0-CURRENT #41 r260441: Tue Jan 7 22:50:42 PST 2014 jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm gcc version 4.2.1 20070831 patched [FreeBSD] CPU: IXP425 266MHz rev 1 (ARMv5TE) (XScale core) Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled 32KB/32B 32-way instruction cache 32KB/32B 32-way write-back-locking data cache real memory = 67108864 (64 MB) avail memory = 57008128 (54 MB) The question is why does turning on EABI cause the kernel_pmap mutex to be a spin mutex instead of a mtx_lock mutex? Oh, I did track down the above panic and the trace is basicly: pmap_extract pmap_init_l1 pmap_bootstrap initarm pmap_extract's arg is pmap_kernel() which is kernel_pmap, and kernel_pmap's lock is init'd earlier in pmap_bootstrap before calling pmap_init_l1... So I have no clue why it isn't work... Is someone going to help who has a clue? or am I just going to get silence again? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Jan 8 14:31:25 2014 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 ESMTPS id 5D03160B; Wed, 8 Jan 2014 14:31:25 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ECEDB1F24; Wed, 8 Jan 2014 14:31:23 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s08EVD5M084348; Wed, 8 Jan 2014 16:31:13 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s08EVDUV084012; Wed, 8 Jan 2014 14:31:13 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Jan 2014 14:31:13 GMT Message-Id: <201401081431.s08EVDUV084012@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 14:31:25 -0000 TB --- 2014-01-08 09:40:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-08 09:40:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-08 09:40:43 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-01-08 09:40:43 - cleaning the object tree TB --- 2014-01-08 09:40:43 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-08 09:41:35 - At svn revision 260447 TB --- 2014-01-08 09:41:36 - building world TB --- 2014-01-08 09:41:36 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 09:41:36 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 09:41:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 09:41:36 - SRCCONF=/dev/null TB --- 2014-01-08 09:41:36 - TARGET=arm TB --- 2014-01-08 09:41:36 - TARGET_ARCH=arm TB --- 2014-01-08 09:41:36 - TZ=UTC TB --- 2014-01-08 09:41:36 - __MAKE_CONF=/dev/null TB --- 2014-01-08 09:41:36 - cd /src TB --- 2014-01-08 09:41:36 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Jan 8 09:41:47 UTC 2014 >>> 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 Wed Jan 8 13:08:28 UTC 2014 TB --- 2014-01-08 13:08:28 - generating LINT kernel config TB --- 2014-01-08 13:08:28 - cd /src/sys/arm/conf TB --- 2014-01-08 13:08:28 - /usr/bin/make -B LINT TB --- 2014-01-08 13:08:28 - cd /src/sys/arm/conf TB --- 2014-01-08 13:08:28 - /usr/sbin/config -m LINT TB --- 2014-01-08 13:08:28 - building LINT kernel TB --- 2014-01-08 13:08:28 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 13:08:28 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 13:08:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 13:08:28 - SRCCONF=/dev/null TB --- 2014-01-08 13:08:28 - TARGET=arm TB --- 2014-01-08 13:08:28 - TARGET_ARCH=arm TB --- 2014-01-08 13:08:28 - TZ=UTC TB --- 2014-01-08 13:08:28 - __MAKE_CONF=/dev/null TB --- 2014-01-08 13:08:28 - cd /src TB --- 2014-01-08 13:08:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 8 13:08:28 UTC 2014 >>> 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 Wed Jan 8 13:34:32 UTC 2014 TB --- 2014-01-08 13:34:32 - cd /src/sys/arm/conf TB --- 2014-01-08 13:34:32 - /usr/sbin/config -m AC100 TB --- 2014-01-08 13:34:32 - skipping AC100 kernel TB --- 2014-01-08 13:34:32 - cd /src/sys/arm/conf TB --- 2014-01-08 13:34:32 - /usr/sbin/config -m ARMADAXP TB --- 2014-01-08 13:34:32 - skipping ARMADAXP kernel TB --- 2014-01-08 13:34:32 - cd /src/sys/arm/conf TB --- 2014-01-08 13:34:32 - /usr/sbin/config -m ARNDALE TB --- 2014-01-08 13:34:32 - skipping ARNDALE kernel TB --- 2014-01-08 13:34:32 - cd /src/sys/arm/conf TB --- 2014-01-08 13:34:32 - /usr/sbin/config -m ATMEL TB --- 2014-01-08 13:34:32 - building ATMEL kernel TB --- 2014-01-08 13:34:32 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 13:34:32 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 13:34:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 13:34:32 - SRCCONF=/dev/null TB --- 2014-01-08 13:34:32 - TARGET=arm TB --- 2014-01-08 13:34:32 - TARGET_ARCH=arm TB --- 2014-01-08 13:34:32 - TZ=UTC TB --- 2014-01-08 13:34:32 - __MAKE_CONF=/dev/null TB --- 2014-01-08 13:34:32 - cd /src TB --- 2014-01-08 13:34:32 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Wed Jan 8 13:34:32 UTC 2014 >>> 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 Wed Jan 8 13:38:34 UTC 2014 TB --- 2014-01-08 13:38:34 - cd /src/sys/arm/conf TB --- 2014-01-08 13:38:34 - /usr/sbin/config -m AVILA TB --- 2014-01-08 13:38:34 - skipping AVILA kernel TB --- 2014-01-08 13:38:34 - cd /src/sys/arm/conf TB --- 2014-01-08 13:38:34 - /usr/sbin/config -m BEAGLEBONE TB --- 2014-01-08 13:38:34 - skipping BEAGLEBONE kernel TB --- 2014-01-08 13:38:34 - cd /src/sys/arm/conf TB --- 2014-01-08 13:38:34 - /usr/sbin/config -m BWCT TB --- 2014-01-08 13:38:34 - building BWCT kernel TB --- 2014-01-08 13:38:34 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 13:38:34 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 13:38:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 13:38:34 - SRCCONF=/dev/null TB --- 2014-01-08 13:38:34 - TARGET=arm TB --- 2014-01-08 13:38:34 - TARGET_ARCH=arm TB --- 2014-01-08 13:38:34 - TZ=UTC TB --- 2014-01-08 13:38:34 - __MAKE_CONF=/dev/null TB --- 2014-01-08 13:38:34 - cd /src TB --- 2014-01-08 13:38:34 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Wed Jan 8 13:38:34 UTC 2014 >>> 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 Wed Jan 8 13:41:15 UTC 2014 TB --- 2014-01-08 13:41:15 - cd /src/sys/arm/conf TB --- 2014-01-08 13:41:15 - /usr/sbin/config -m CAMBRIA TB --- 2014-01-08 13:41:15 - skipping CAMBRIA kernel TB --- 2014-01-08 13:41:15 - cd /src/sys/arm/conf TB --- 2014-01-08 13:41:15 - /usr/sbin/config -m CNS11XXNAS TB --- 2014-01-08 13:41:15 - building CNS11XXNAS kernel TB --- 2014-01-08 13:41:15 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 13:41:15 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 13:41:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 13:41:15 - SRCCONF=/dev/null TB --- 2014-01-08 13:41:15 - TARGET=arm TB --- 2014-01-08 13:41:15 - TARGET_ARCH=arm TB --- 2014-01-08 13:41:15 - TZ=UTC TB --- 2014-01-08 13:41:15 - __MAKE_CONF=/dev/null TB --- 2014-01-08 13:41:15 - cd /src TB --- 2014-01-08 13:41:15 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Wed Jan 8 13:41:15 UTC 2014 >>> 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 Wed Jan 8 13:45:14 UTC 2014 TB --- 2014-01-08 13:45:14 - cd /src/sys/arm/conf TB --- 2014-01-08 13:45:14 - /usr/sbin/config -m CRB TB --- 2014-01-08 13:45:14 - skipping CRB kernel TB --- 2014-01-08 13:45:14 - cd /src/sys/arm/conf TB --- 2014-01-08 13:45:14 - /usr/sbin/config -m CUBIEBOARD TB --- 2014-01-08 13:45:14 - skipping CUBIEBOARD kernel TB --- 2014-01-08 13:45:14 - cd /src/sys/arm/conf TB --- 2014-01-08 13:45:14 - /usr/sbin/config -m CUBIEBOARD2 TB --- 2014-01-08 13:45:14 - skipping CUBIEBOARD2 kernel TB --- 2014-01-08 13:45:14 - cd /src/sys/arm/conf TB --- 2014-01-08 13:45:14 - /usr/sbin/config -m DB-78XXX TB --- 2014-01-08 13:45:14 - building DB-78XXX kernel TB --- 2014-01-08 13:45:14 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 13:45:14 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 13:45:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 13:45:14 - SRCCONF=/dev/null TB --- 2014-01-08 13:45:14 - TARGET=arm TB --- 2014-01-08 13:45:14 - TARGET_ARCH=arm TB --- 2014-01-08 13:45:14 - TZ=UTC TB --- 2014-01-08 13:45:14 - __MAKE_CONF=/dev/null TB --- 2014-01-08 13:45:14 - cd /src TB --- 2014-01-08 13:45:14 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Wed Jan 8 13:45:14 UTC 2014 >>> 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 Wed Jan 8 13:48:47 UTC 2014 TB --- 2014-01-08 13:48:47 - cd /src/sys/arm/conf TB --- 2014-01-08 13:48:47 - /usr/sbin/config -m DB-88F5XXX TB --- 2014-01-08 13:48:47 - building DB-88F5XXX kernel TB --- 2014-01-08 13:48:47 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 13:48:47 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 13:48:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 13:48:47 - SRCCONF=/dev/null TB --- 2014-01-08 13:48:47 - TARGET=arm TB --- 2014-01-08 13:48:47 - TARGET_ARCH=arm TB --- 2014-01-08 13:48:47 - TZ=UTC TB --- 2014-01-08 13:48:47 - __MAKE_CONF=/dev/null TB --- 2014-01-08 13:48:47 - cd /src TB --- 2014-01-08 13:48:47 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Wed Jan 8 13:48:47 UTC 2014 >>> 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 Wed Jan 8 13:52:08 UTC 2014 TB --- 2014-01-08 13:52:08 - cd /src/sys/arm/conf TB --- 2014-01-08 13:52:08 - /usr/sbin/config -m DB-88F6XXX TB --- 2014-01-08 13:52:08 - building DB-88F6XXX kernel TB --- 2014-01-08 13:52:08 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 13:52:08 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 13:52:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 13:52:08 - SRCCONF=/dev/null TB --- 2014-01-08 13:52:08 - TARGET=arm TB --- 2014-01-08 13:52:08 - TARGET_ARCH=arm TB --- 2014-01-08 13:52:08 - TZ=UTC TB --- 2014-01-08 13:52:08 - __MAKE_CONF=/dev/null TB --- 2014-01-08 13:52:08 - cd /src TB --- 2014-01-08 13:52:08 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Wed Jan 8 13:52:08 UTC 2014 >>> 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 Wed Jan 8 13:55:41 UTC 2014 TB --- 2014-01-08 13:55:41 - cd /src/sys/arm/conf TB --- 2014-01-08 13:55:41 - /usr/sbin/config -m DIGI-CCWMX53 TB --- 2014-01-08 13:55:41 - skipping DIGI-CCWMX53 kernel TB --- 2014-01-08 13:55:41 - cd /src/sys/arm/conf TB --- 2014-01-08 13:55:41 - /usr/sbin/config -m DOCKSTAR TB --- 2014-01-08 13:55:41 - building DOCKSTAR kernel TB --- 2014-01-08 13:55:41 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 13:55:41 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 13:55:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 13:55:41 - SRCCONF=/dev/null TB --- 2014-01-08 13:55:41 - TARGET=arm TB --- 2014-01-08 13:55:41 - TARGET_ARCH=arm TB --- 2014-01-08 13:55:41 - TZ=UTC TB --- 2014-01-08 13:55:41 - __MAKE_CONF=/dev/null TB --- 2014-01-08 13:55:41 - cd /src TB --- 2014-01-08 13:55:41 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Wed Jan 8 13:55:41 UTC 2014 >>> 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 Wed Jan 8 13:59:05 UTC 2014 TB --- 2014-01-08 13:59:05 - cd /src/sys/arm/conf TB --- 2014-01-08 13:59:05 - /usr/sbin/config -m DREAMPLUG-1001 TB --- 2014-01-08 13:59:05 - building DREAMPLUG-1001 kernel TB --- 2014-01-08 13:59:05 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 13:59:05 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 13:59:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 13:59:05 - SRCCONF=/dev/null TB --- 2014-01-08 13:59:05 - TARGET=arm TB --- 2014-01-08 13:59:05 - TARGET_ARCH=arm TB --- 2014-01-08 13:59:05 - TZ=UTC TB --- 2014-01-08 13:59:05 - __MAKE_CONF=/dev/null TB --- 2014-01-08 13:59:05 - cd /src TB --- 2014-01-08 13:59:05 - /usr/bin/make -B buildkernel KERNCONF=DREAMPLUG-1001 >>> Kernel build for DREAMPLUG-1001 started on Wed Jan 8 13:59:06 UTC 2014 >>> 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 Wed Jan 8 14:05:18 UTC 2014 TB --- 2014-01-08 14:05:18 - cd /src/sys/arm/conf TB --- 2014-01-08 14:05:18 - /usr/sbin/config -m EA3250 TB --- 2014-01-08 14:05:18 - building EA3250 kernel TB --- 2014-01-08 14:05:18 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 14:05:18 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 14:05:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 14:05:18 - SRCCONF=/dev/null TB --- 2014-01-08 14:05:18 - TARGET=arm TB --- 2014-01-08 14:05:18 - TARGET_ARCH=arm TB --- 2014-01-08 14:05:18 - TZ=UTC TB --- 2014-01-08 14:05:18 - __MAKE_CONF=/dev/null TB --- 2014-01-08 14:05:18 - cd /src TB --- 2014-01-08 14:05:18 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Wed Jan 8 14:05:18 UTC 2014 >>> 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 Wed Jan 8 14:08:33 UTC 2014 TB --- 2014-01-08 14:08:33 - cd /src/sys/arm/conf TB --- 2014-01-08 14:08:33 - /usr/sbin/config -m EB9200 TB --- 2014-01-08 14:08:33 - building EB9200 kernel TB --- 2014-01-08 14:08:33 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 14:08:33 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 14:08:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 14:08:33 - SRCCONF=/dev/null TB --- 2014-01-08 14:08:33 - TARGET=arm TB --- 2014-01-08 14:08:33 - TARGET_ARCH=arm TB --- 2014-01-08 14:08:33 - TZ=UTC TB --- 2014-01-08 14:08:33 - __MAKE_CONF=/dev/null TB --- 2014-01-08 14:08:33 - cd /src TB --- 2014-01-08 14:08:33 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Wed Jan 8 14:08:33 UTC 2014 >>> 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 Wed Jan 8 14:12:20 UTC 2014 TB --- 2014-01-08 14:12:20 - cd /src/sys/arm/conf TB --- 2014-01-08 14:12:20 - /usr/sbin/config -m EFIKA_MX TB --- 2014-01-08 14:12:20 - skipping EFIKA_MX kernel TB --- 2014-01-08 14:12:20 - cd /src/sys/arm/conf TB --- 2014-01-08 14:12:20 - /usr/sbin/config -m EP80219 TB --- 2014-01-08 14:12:20 - skipping EP80219 kernel TB --- 2014-01-08 14:12:20 - cd /src/sys/arm/conf TB --- 2014-01-08 14:12:20 - /usr/sbin/config -m ETHERNUT5 TB --- 2014-01-08 14:12:20 - building ETHERNUT5 kernel TB --- 2014-01-08 14:12:20 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 14:12:20 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 14:12:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 14:12:20 - SRCCONF=/dev/null TB --- 2014-01-08 14:12:20 - TARGET=arm TB --- 2014-01-08 14:12:20 - TARGET_ARCH=arm TB --- 2014-01-08 14:12:20 - TZ=UTC TB --- 2014-01-08 14:12:20 - __MAKE_CONF=/dev/null TB --- 2014-01-08 14:12:20 - cd /src TB --- 2014-01-08 14:12:20 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Wed Jan 8 14:12:20 UTC 2014 >>> 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 Wed Jan 8 14:24:24 UTC 2014 TB --- 2014-01-08 14:24:24 - cd /src/sys/arm/conf TB --- 2014-01-08 14:24:24 - /usr/sbin/config -m GUMSTIX TB --- 2014-01-08 14:24:24 - building GUMSTIX kernel TB --- 2014-01-08 14:24:24 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 14:24:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 14:24:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 14:24:24 - SRCCONF=/dev/null TB --- 2014-01-08 14:24:24 - TARGET=arm TB --- 2014-01-08 14:24:24 - TARGET_ARCH=arm TB --- 2014-01-08 14:24:24 - TZ=UTC TB --- 2014-01-08 14:24:24 - __MAKE_CONF=/dev/null TB --- 2014-01-08 14:24:24 - cd /src TB --- 2014-01-08 14:24:24 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Wed Jan 8 14:24:24 UTC 2014 >>> 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 Wed Jan 8 14:27:48 UTC 2014 TB --- 2014-01-08 14:27:48 - cd /src/sys/arm/conf TB --- 2014-01-08 14:27:48 - /usr/sbin/config -m GUMSTIX-QEMU TB --- 2014-01-08 14:27:48 - building GUMSTIX-QEMU kernel TB --- 2014-01-08 14:27:48 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 14:27:48 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 14:27:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 14:27:48 - SRCCONF=/dev/null TB --- 2014-01-08 14:27:48 - TARGET=arm TB --- 2014-01-08 14:27:48 - TARGET_ARCH=arm TB --- 2014-01-08 14:27:48 - TZ=UTC TB --- 2014-01-08 14:27:48 - __MAKE_CONF=/dev/null TB --- 2014-01-08 14:27:48 - cd /src TB --- 2014-01-08 14:27:48 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX-QEMU >>> Kernel build for GUMSTIX-QEMU started on Wed Jan 8 14:27:48 UTC 2014 >>> 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 Wed Jan 8 14:31:10 UTC 2014 TB --- 2014-01-08 14:31:10 - cd /src/sys/arm/conf TB --- 2014-01-08 14:31:10 - /usr/sbin/config -m HL200 TB --- 2014-01-08 14:31:10 - building HL200 kernel TB --- 2014-01-08 14:31:10 - CROSS_BUILD_TESTING=YES TB --- 2014-01-08 14:31:10 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-08 14:31:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-08 14:31:10 - SRCCONF=/dev/null TB --- 2014-01-08 14:31:10 - TARGET=arm TB --- 2014-01-08 14:31:10 - TARGET_ARCH=arm TB --- 2014-01-08 14:31:10 - TZ=UTC TB --- 2014-01-08 14:31:10 - __MAKE_CONF=/dev/null TB --- 2014-01-08 14:31:10 - cd /src TB --- 2014-01-08 14:31:10 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Wed Jan 8 14:31:11 UTC 2014 >>> 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 [...] yacc -b aicasm_macro_gram -p mm -d -o aicasm_macro_gram.c /src/sys/dev/aic7xxx/aicasm/aicasm_macro_gram.y cc -O2 -pipe -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c: In function 'symtable_dump': /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c:461: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/HL200 *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-01-08 14:31:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-08 14:31:11 - ERROR: failed to build HL200 kernel TB --- 2014-01-08 14:31:11 - 12747.63 user 4567.74 system 17428.66 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Jan 8 16:05:01 2014 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 ESMTPS id 6CE45D62 for ; Wed, 8 Jan 2014 16:05:01 +0000 (UTC) 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 2D3951782 for ; Wed, 8 Jan 2014 16:05:00 +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 1W0vck-0004At-JP; Wed, 08 Jan 2014 16:04:54 +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 s08G4qAB030694; Wed, 8 Jan 2014 09:04:52 -0700 (MST) (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+HBXyWZuv/xSD9OHRfTk5c Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20140108071643.GB99167@funkthat.com> References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 08 Jan 2014 09:04:51 -0700 Message-ID: <1389197091.1158.370.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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 16:05:01 -0000 On Tue, 2014-01-07 at 23:16 -0800, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Fri, Dec 20, 2013 at 22:10 -0800: > > Ian Lepore wrote this message on Thu, Nov 21, 2013 at 01:08 +0000: > > > Author: ian > > > Date: Thu Nov 21 01:08:10 2013 > > > New Revision: 258412 > > > URL: http://svnweb.freebsd.org/changeset/base/258412 > > > > > > Log: > > > Call cpu_setup() from the initarm() routine on platforms that don't use > > > the common FDT-aware initarm() in arm/machdep.c. > > > > > > Pointed out by: cognet > > > Pointy hat to: ian > > > > [...] > > > > > Modified: head/sys/arm/xscale/ixp425/avila_machdep.c > > > ============================================================================== > > > --- head/sys/arm/xscale/ixp425/avila_machdep.c Thu Nov 21 00:54:26 2013 (r258411) > > > +++ head/sys/arm/xscale/ixp425/avila_machdep.c Thu Nov 21 01:08:10 2013 (r258412) > > > @@ -405,6 +405,8 @@ initarm(struct arm_boot_params *abp) > > > * this problem will not occur after initarm(). > > > */ > > > cpu_idcache_wbinv_all(); > > > + cpu_setup(""); > > > + > > > /* ready to setup the console (XXX move earlier if possible) */ > > > cninit(); > > > /* > > > > > > > So, I finally got an AVILA board (thanks Jim@netgate) to do some testing > > on what stopped working... > > > > Turns out this commit break early output on the AVILA board... With > > this commit, I get no output when booting the kernel: > > RedBoot> load -b 0x200000 kernel.avila.avila > > Using default protocol (TFTP) > > Address offset = 0x40000000 > > Entry point: 0x00200100, address range: 0x00200000-0x006aedc8 > > RedBoot> go > > > > some previous pmap changes made the AVILA board panic... The pmap > > changes were made some time between July 1st and Aug 1st, and on kernels > > since then, I get: > > RedBoot> go > > panic: mtx_lock() of spin mutex pmap @ /usr/src.avila/sys/arm/arm/pmap.c:3677 > > Uptime: 1s > > So, finally tracked this panic down to the switch to EABI. If I > compiled kernel-toolchain from 253395 (before the EABI switch) and build > a kernel from HEAD, I get: > FreeBSD 11.0-CURRENT #41 r260441: Tue Jan 7 22:50:42 PST 2014 > jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm > gcc version 4.2.1 20070831 patched [FreeBSD] > CPU: IXP425 266MHz rev 1 (ARMv5TE) (XScale core) > Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled > 32KB/32B 32-way instruction cache > 32KB/32B 32-way write-back-locking data cache > real memory = 67108864 (64 MB) > avail memory = 57008128 (54 MB) > > The question is why does turning on EABI cause the kernel_pmap mutex > to be a spin mutex instead of a mtx_lock mutex? > > Oh, I did track down the above panic and the trace is basicly: > pmap_extract > pmap_init_l1 > pmap_bootstrap > initarm > > pmap_extract's arg is pmap_kernel() which is kernel_pmap, and > kernel_pmap's lock is init'd earlier in pmap_bootstrap before calling > pmap_init_l1... > > So I have no clue why it isn't work... > > Is someone going to help who has a clue? or am I just going to get > silence again? > I wonder if you're the first person actually run-testing big-endian EABI since we switched to eabi by default? Looking at the code involved in validating the mutex type, nothing jumps out at me as suspicious for endian-related trouble... the code involved appears to always access the data as a 32-bit flags field with shifting and masking (no unions or bogus re-casting to char pointers or anything). Setting WITHOUT_ARM_EABI in make.conf would be a workaround, but probably only useful to allow a build of -current to see if the problem truly toggles with the abi, and isn't somehow related to some other changes that happened since the switch to default eabi. (Remember you've got to blow away the MAKEOBJDIR and build fresh from scratch when changing abi.) -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jan 8 17:39:10 2014 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 ESMTPS id EF002893; Wed, 8 Jan 2014 17:39:10 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A52B71F9B; Wed, 8 Jan 2014 17:39:10 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s08Hd9nY034745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jan 2014 09:39:09 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s08Hd983034744; Wed, 8 Jan 2014 09:39:09 -0800 (PST) (envelope-from jmg) Date: Wed, 8 Jan 2014 09:39:09 -0800 From: John-Mark Gurney To: Ian Lepore Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Message-ID: <20140108173909.GF99167@funkthat.com> Mail-Followup-To: Ian Lepore , freebsd-arm@FreeBSD.org References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1389197091.1158.370.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 08 Jan 2014 09:39:10 -0800 (PST) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 17:39:11 -0000 Ian Lepore wrote this message on Wed, Jan 08, 2014 at 09:04 -0700: > On Tue, 2014-01-07 at 23:16 -0800, John-Mark Gurney wrote: > > John-Mark Gurney wrote this message on Fri, Dec 20, 2013 at 22:10 -0800: > > > Ian Lepore wrote this message on Thu, Nov 21, 2013 at 01:08 +0000: > > > > Author: ian > > > > Date: Thu Nov 21 01:08:10 2013 > > > > New Revision: 258412 > > > > URL: http://svnweb.freebsd.org/changeset/base/258412 > > > > > > > > Log: > > > > Call cpu_setup() from the initarm() routine on platforms that don't use > > > > the common FDT-aware initarm() in arm/machdep.c. > > > > > > > > Pointed out by: cognet > > > > Pointy hat to: ian > > > > > > [...] > > > > > > > Modified: head/sys/arm/xscale/ixp425/avila_machdep.c > > > > ============================================================================== > > > > --- head/sys/arm/xscale/ixp425/avila_machdep.c Thu Nov 21 00:54:26 2013 (r258411) > > > > +++ head/sys/arm/xscale/ixp425/avila_machdep.c Thu Nov 21 01:08:10 2013 (r258412) > > > > @@ -405,6 +405,8 @@ initarm(struct arm_boot_params *abp) > > > > * this problem will not occur after initarm(). > > > > */ > > > > cpu_idcache_wbinv_all(); > > > > + cpu_setup(""); > > > > + > > > > /* ready to setup the console (XXX move earlier if possible) */ > > > > cninit(); > > > > /* > > > > > > > > > > So, I finally got an AVILA board (thanks Jim@netgate) to do some testing > > > on what stopped working... > > > > > > Turns out this commit break early output on the AVILA board... With > > > this commit, I get no output when booting the kernel: > > > RedBoot> load -b 0x200000 kernel.avila.avila > > > Using default protocol (TFTP) > > > Address offset = 0x40000000 > > > Entry point: 0x00200100, address range: 0x00200000-0x006aedc8 > > > RedBoot> go > > > > > > some previous pmap changes made the AVILA board panic... The pmap > > > changes were made some time between July 1st and Aug 1st, and on kernels > > > since then, I get: > > > RedBoot> go > > > panic: mtx_lock() of spin mutex pmap @ /usr/src.avila/sys/arm/arm/pmap.c:3677 > > > Uptime: 1s > > > > So, finally tracked this panic down to the switch to EABI. If I > > compiled kernel-toolchain from 253395 (before the EABI switch) and build > > a kernel from HEAD, I get: > > FreeBSD 11.0-CURRENT #41 r260441: Tue Jan 7 22:50:42 PST 2014 > > jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm > > gcc version 4.2.1 20070831 patched [FreeBSD] > > CPU: IXP425 266MHz rev 1 (ARMv5TE) (XScale core) > > Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled > > 32KB/32B 32-way instruction cache > > 32KB/32B 32-way write-back-locking data cache > > real memory = 67108864 (64 MB) > > avail memory = 57008128 (54 MB) > > > > The question is why does turning on EABI cause the kernel_pmap mutex > > to be a spin mutex instead of a mtx_lock mutex? > > > > Oh, I did track down the above panic and the trace is basicly: > > pmap_extract > > pmap_init_l1 > > pmap_bootstrap > > initarm > > > > pmap_extract's arg is pmap_kernel() which is kernel_pmap, and > > kernel_pmap's lock is init'd earlier in pmap_bootstrap before calling > > pmap_init_l1... > > > > So I have no clue why it isn't work... > > > > Is someone going to help who has a clue? or am I just going to get > > silence again? > > I wonder if you're the first person actually run-testing big-endian EABI > since we switched to eabi by default? Nope, I'm not, Berislav Purgar reported the same issue earlier: https://www.freebsd.org/cgi/mid.cgi?CAAUsrB7GT1gWpKPB_kY8hrs=2=Lsf=47EA3hAGpyyWN3KJ4u4Q@mail.gmail.com and found the same issue w/ EABI... > Looking at the code involved in validating the mutex type, nothing jumps > out at me as suspicious for endian-related trouble... the code involved > appears to always access the data as a 32-bit flags field with shifting > and masking (no unions or bogus re-casting to char pointers or > anything). Considering that mutex code worked before, it shouldn't be the code... I'm wondering if either there is an issue w/ smashing memory or a cache flush that is writing bogus data out, or that a cache flush failed to write data that was in the cache? > Setting WITHOUT_ARM_EABI in make.conf would be a workaround, but > probably only useful to allow a build of -current to see if the problem > truly toggles with the abi, and isn't somehow related to some other > changes that happened since the switch to default eabi. (Remember > you've got to blow away the MAKEOBJDIR and build fresh from scratch when > changing abi.) So, I've tested that HEAD (absolutely no tree changes) w/ WITHOUT_ARM_EABI boots fine... and just to make sure my test is correct, I've disabled it too to verify that the kernel just hangs (absolutely no output).. and reenabled it and verified it works (that my setting is changing something)... worky -> no worky -> worky... Now I just realized another interesting thing about setting WITHOUT_ARM_EABI, it also fixes the console issue I was having w/ your call to cpu_setup("") previously (w/ EABI) killing console output and not even seeing the mtx panic message... So, it is clearly changing something very early on in boot... Clean HEAD using WITHOUT_ARM_EABI=: RedBoot> go KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #44 r260452: Wed Jan 8 09:35:24 PST 2014 jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm gcc version 4.2.1 20070831 patched [FreeBSD] CPU: IXP425 266MHz rev 1 (ARMv5TE) (XScale core) Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled 32KB/32B 32-way instruction cache 32KB/32B 32-way write-back-locking data cache real memory = 67108864 (64 MB) avail memory = 57008128 (54 MB) [...] I haven't put together a root to boot into yet, so I don't know if it makes it to single user or not... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu Jan 9 10:42:26 2014 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 ESMTPS id 0596520A; Thu, 9 Jan 2014 10:42:26 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (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 6544215F1; Thu, 9 Jan 2014 10:42:24 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s09AgNBO092081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jan 2014 14:42:23 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s09AgNl8092080; Thu, 9 Jan 2014 14:42:23 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 9 Jan 2014 14:42:23 +0400 From: Gleb Smirnoff To: Guy Yur Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Message-ID: <20140109104223.GS71033@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 10:42:26 -0000 Guy, On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. G> The "pfctl -s state" command is crashing when trying to print the G> second entry. G> G> struct pfsync_state has a size that is not divisiable by 4 or 8 leading to the G> second entry in the returned state array not being aligned and pfctl G> core dumps on Bus error when trying to access a uint32_t field. G> G> (gdb) bt G> #0 print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at G> /usr/src/sbin/pfctl/pf_print_state.c:178 G> #1 0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at G> /usr/src/sbin/pfctl/pf_print_state.c:236 G> #2 0x0000c664 in pfctl_show_states (dev=, G> iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095 G> G> sizeof(struct pfsync_state_key) is 36 G> sizeof(struct pfsync_state_peer) is 32 G> sizeof(struct pf_addr) is 16 G> sizeof(struct pfsync_state) is 242 G> G> Removing the __spare[2] field will allow the struct to be aligned on 8 bytes G> for the u_int64_t id field and also cover the uint32_t fields alignment G> but this will break KBI. G> G> I am currently using an inefficient workaround in pfctl_show_states G> that memcpy each entry to a struct pfsync_state on the stack G> ensuring each call to print_state receives an aligned struct. G> G> 10.0-RC1 World and kernel were compiled in a VirtualBox VM running G> 9.2-RELEASE-p2 i386. G> clang and ARM_EABI used as the default make options. For pf we are ready to break KBI. It uses same structs for internal kernel representation and for ioctl() API and this is actually a bug. Until it is properly fixed, we are doomed to break KBI always. Unfortunately, pfsync_state is not only a KBI but also a wire protocol for pfsync(4). We can't break this, since that would make different FreeBSD versions not exchanging states properly. Well, <= 8.x already is incompatible with >= 9.x, thanks yet another OpenBSD import. But we don't want to introduce another one. I will try to fix this making new structure for the ioctl. That will mean moving slowly towards divorcing internal structures and ioctl ones. I'd appreciate if you file a PR on that, so that problem won't leave forgotten in the mailing list. You can even code the bugfix :) Thanks! -- Totus tuus, Glebius. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 9 11:43:18 2014 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 ESMTPS id 99CFEC26; Thu, 9 Jan 2014 11:43:18 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (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 21F461B0C; Thu, 9 Jan 2014 11:43:17 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s09BhA8C092833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jan 2014 15:43:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s09BhAKS092832; Thu, 9 Jan 2014 15:43:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 9 Jan 2014 15:43:10 +0400 From: Gleb Smirnoff To: Guy Yur Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Message-ID: <20140109114310.GU71033@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 11:43:18 -0000 Guy, On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: G> sizeof(struct pfsync_state_key) is 36 G> sizeof(struct pfsync_state_peer) is 32 G> sizeof(struct pf_addr) is 16 G> sizeof(struct pfsync_state) is 242 I am also afraid that the pfsync(4) itself isn't alignment safe. And receiving and processing a pfsync packet with couple of states would panic an arm box. Is it possible for you to check this? -- Totus tuus, Glebius. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 9 14:29:43 2014 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 ESMTPS id 8BAAD27C; Thu, 9 Jan 2014 14:29:43 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 537F219AA; Thu, 9 Jan 2014 14:29:43 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id fb1so1806364pad.0 for ; Thu, 09 Jan 2014 06:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uiMWN5jR8dsST8Fyoc7iCFIDOG3Y13psOfpasyyJ9RE=; b=ihRUrAZ4vld8PwPj5IFhTZ81qrI7K3Ty5mfqYjfedA8gO+nkyNeG7XatS+/kiAnECz dy6mYLLJSCMikV++iHhnHGpxYi0QI/AHsmvUyBR9FTj2t9iTdEUghtnLiQLOvyobnuaY 6yOblnINkeaJftDwTuaaVgBojGQoeun32oxyREp2pPlvPZNF6Fe6SKFtNMjEUPUEK1mq maB51SS10MEJfWVVO95UhBI7Y3dPddE/5usHtNcUk10lu5/5hAXCGNwgPGhCYMCnM3np 9e/ueJHwwAIISU+7MLutInZmACjqvMorBJh7qt8jGbv6170kjAQ3vH08hqoPzAHZAJh+ zFFw== MIME-Version: 1.0 X-Received: by 10.69.12.99 with SMTP id ep3mr4128600pbd.86.1389277782965; Thu, 09 Jan 2014 06:29:42 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.46.42 with HTTP; Thu, 9 Jan 2014 06:29:42 -0800 (PST) In-Reply-To: <20140109104223.GS71033@FreeBSD.org> References: <20140109104223.GS71033@FreeBSD.org> Date: Thu, 9 Jan 2014 15:29:42 +0100 X-Google-Sender-Auth: rwc266wx-fMYed7KwqO91Nco2B4 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-net , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 14:29:43 -0000 On Thu, Jan 9, 2014 at 11:42 AM, Gleb Smirnoff wrote: > Guy, > > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. > G> The "pfctl -s state" command is crashing when trying to print the > G> second entry. > G> > G> struct pfsync_state has a size that is not divisiable by 4 or 8 leading > to the > G> second entry in the returned state array not being aligned and pfctl > G> core dumps on Bus error when trying to access a uint32_t field. > G> > G> (gdb) bt > G> #0 print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at > G> /usr/src/sbin/pfctl/pf_print_state.c:178 > G> #1 0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at > G> /usr/src/sbin/pfctl/pf_print_state.c:236 > G> #2 0x0000c664 in pfctl_show_states (dev=, > G> iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095 > G> > G> sizeof(struct pfsync_state_key) is 36 > G> sizeof(struct pfsync_state_peer) is 32 > G> sizeof(struct pf_addr) is 16 > G> sizeof(struct pfsync_state) is 242 > G> > G> Removing the __spare[2] field will allow the struct to be aligned on 8 > bytes > G> for the u_int64_t id field and also cover the uint32_t fields alignment > G> but this will break KBI. > G> > G> I am currently using an inefficient workaround in pfctl_show_states > G> that memcpy each entry to a struct pfsync_state on the stack > G> ensuring each call to print_state receives an aligned struct. > G> > G> 10.0-RC1 World and kernel were compiled in a VirtualBox VM running > G> 9.2-RELEASE-p2 i386. > G> clang and ARM_EABI used as the default make options. > > For pf we are ready to break KBI. It uses same structs for internal kernel > representation and for ioctl() API and this is actually a bug. Until it is > properly fixed, we are doomed to break KBI always. > > Unfortunately, pfsync_state is not only a KBI but also a wire protocol for > pfsync(4). We can't break this, since that would make different FreeBSD > versions not exchanging states properly. > > Well, <= 8.x already is incompatible with >= 9.x, thanks yet another > OpenBSD > import. But we don't want to introduce another one. > > I will try to fix this making new structure for the ioctl. That will mean > moving slowly towards divorcing internal structures and ioctl ones. > > I'd appreciate if you file a PR on that, so that problem won't leave > forgotten > in the mailing list. You can even code the bugfix :) > > Thanks! > > Well pfsync has a version in its header so its quite possible to support many of them. > -- > Totus tuus, Glebius. > _______________________________________________ > 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" > -- Ermal From owner-freebsd-arm@FreeBSD.ORG Thu Jan 9 20:22:55 2014 Return-Path: Delivered-To: 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 ESMTPS id E9EEC893; Thu, 9 Jan 2014 20:22:55 +0000 (UTC) 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 93EA01A76; Thu, 9 Jan 2014 20:22:55 +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 s09KMrHe057949; Thu, 9 Jan 2014 15:22:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s09KMrqA057936; Thu, 9 Jan 2014 20:22:53 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 9 Jan 2014 20:22:53 GMT Message-Id: <201401092022.s09KMrqA057936@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.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 20:22:56 -0000 TB --- 2014-01-09 17:30:19 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-09 17:30:19 - 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 --- 2014-01-09 17:30:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-09 17:30:19 - cleaning the object tree TB --- 2014-01-09 17:30:19 - /usr/local/bin/svn stat /src TB --- 2014-01-09 17:30:24 - At svn revision 260487 TB --- 2014-01-09 17:30:25 - building world TB --- 2014-01-09 17:30:25 - CROSS_BUILD_TESTING=YES TB --- 2014-01-09 17:30:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-09 17:30:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-09 17:30:25 - SRCCONF=/dev/null TB --- 2014-01-09 17:30:25 - TARGET=arm TB --- 2014-01-09 17:30:25 - TARGET_ARCH=arm TB --- 2014-01-09 17:30:25 - TZ=UTC TB --- 2014-01-09 17:30:25 - __MAKE_CONF=/dev/null TB --- 2014-01-09 17:30:25 - cd /src TB --- 2014-01-09 17:30:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 9 17:30:34 UTC 2014 >>> 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 [...] /src/usr.bin/netstat/mroute6.c:234:4: error: use of undeclared identifier 'mfcp'; did you mean 'mfc'? mfcp = mfc.mf6c_next; ^~~~ mfc /src/usr.bin/netstat/mroute6.c:121:14: note: 'mfc' declared here struct mf6c mfc; ^ 16 errors generated. *** Error code 1 Stop. bmake[3]: stopped in /src/usr.bin/netstat *** Error code 1 Stop. bmake[2]: stopped in /src/usr.bin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-09 20:22:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-09 20:22:53 - ERROR: failed to build world TB --- 2014-01-09 20:22:53 - 8324.73 user 1506.38 system 10353.82 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Jan 9 21:40:03 2014 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 ESMTPS id 035EAFD3 for ; Thu, 9 Jan 2014 21:40:03 +0000 (UTC) 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 CED6611B3 for ; Thu, 9 Jan 2014 21:40:02 +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 s09Le2SR037916 for ; Thu, 9 Jan 2014 21:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s09Le2Iu037915; Thu, 9 Jan 2014 21:40:02 GMT (envelope-from gnats) Resent-Date: Thu, 9 Jan 2014 21:40:02 GMT Resent-Message-Id: <201401092140.s09Le2Iu037915@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, Guy Yur 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 ESMTPS id 0E29AE8B for ; Thu, 9 Jan 2014 21:37:56 +0000 (UTC) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A5951191 for ; Thu, 9 Jan 2014 21:37:55 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id h14so1706578eaj.35 for ; Thu, 09 Jan 2014 13:37:54 -0800 (PST) Received: from vm8.localdomain ([188.120.155.236]) by mx.google.com with ESMTPSA id a45sm9126608eem.6.2014.01.09.13.37.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 09 Jan 2014 13:37:53 -0800 (PST) Received: by vm8.localdomain (sSMTP sendmail emulation); Thu, 09 Jan 2014 23:37:21 +0200 Message-Id: <52cf16b1.45b00e0a.3aa5.ffff8053@mx.google.com> Date: Thu, 09 Jan 2014 23:37:21 +0200 From: Guy Yur To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.114 Subject: arm/185617: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Guy Yur List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 21:40:03 -0000 >Number: 185617 >Category: arm >Synopsis: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 09 21:40:02 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Guy Yur >Release: FreeBSD 10.0-RC1 arm >Organization: >Environment: System: FreeBSD bbb.localdomain 10.0-RC1 FreeBSD 10.0-RC1 #1 r259250M: Thu Dec 12 22:54:08 IST 2013 root@vm8.localdomain:/usr/obj/arm.armv6/usr/src/sys/BBB arm >Description: I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. The "pfctl -s state" command is crashing when trying to print the second entry. struct pfsync_state has a size that is not divisiable by 4 leading to the second entry in the returned state array not being aligned. This is fine when accessing the entry as a struct pfsync_state pointer since the struct has the __packed attribute and on arm unaligned access will be used. When print_host is called it receives a pf_addr struct pointer &nk->addr[1] which is not aligned on 4 bytes for the second entry and since the struct is not __packed it will be accessed using word load instructions which will trigger an unaligned access fault and pfctl will exit with bus error. (gdb) bt #0 print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at /usr/src/sbin/pfctl/pf_print_state.c:178 #1 0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at /usr/src/sbin/pfctl/pf_print_state.c:236 #2 0x0000c664 in pfctl_show_states (dev=, iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095 sizeof(struct pfsync_state_key) is 36 sizeof(struct pfsync_state_peer) is 32 sizeof(struct pf_addr) is 16 sizeof(struct pfsync_state) is 242 >How-To-Repeat: pf running on an arm host, make sure there is more than one active connection. Run: pfctl -s state >Fix: A quick workaround is for print_state to copy the pf_addr in pfsync_state_key to a pf_addr struct on the stack and pass it to print_host. Another possibility is to make sure pfsync_state is aligned on at least 4 bytes (8 preferred for the u_int64_t id) or create a new aligned struct for the DIOCGETSTATE and DIOCGETSTATES ioctls to separate between the pfsync_state as protocol data and the info returned by the ioctls. Changing pfsync_state size will break KBI and the pfsync protocol. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Thu Jan 9 22:17:13 2014 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 ESMTPS id 8B96EFB8; Thu, 9 Jan 2014 22:17:13 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A7CE1509; Thu, 9 Jan 2014 22:17:13 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id m1so4138094oag.24 for ; Thu, 09 Jan 2014 14:17:12 -0800 (PST) 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=d6OF2dt4gC2ZXrs+CdrqbvQa/AqP2T3QhBp8lcCF55I=; b=p3tNvc3F1jxp4ays/DLgj+IHafANlxpXPrdS9Jn6ZAv8DTduSScRfcggm8nKvfAFUV EdFgOIUBMETJH2UU05uMmVticEyFHv6gwgh0IxLtS09TMoCYufyZdKaqp2dyCpTmJiZK V81BfzTsiQW/44As/tW7luciMJpTK8FZgx/xlmaxMIh+aOnfDBItGzjEDfTxpfHAlZwy H6bbbm/IFQkF14PlmiSxY7nJmHYbr/JtzrcfsLmFzmew3Im6PGamYgDr7Lq2+VXPgBkJ Z+f3LieJVkgZRSR/qaEUIlh7Qk2Yrq2GYsFUavrcMfYeAQqX2qTOOON9UlWfowCzjsLe jqTQ== MIME-Version: 1.0 X-Received: by 10.182.221.230 with SMTP id qh6mr4225814obc.7.1389305832460; Thu, 09 Jan 2014 14:17:12 -0800 (PST) Received: by 10.76.20.82 with HTTP; Thu, 9 Jan 2014 14:17:12 -0800 (PST) In-Reply-To: <20140109104223.GS71033@FreeBSD.org> References: <20140109104223.GS71033@FreeBSD.org> Date: Fri, 10 Jan 2014 00:17:12 +0200 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 22:17:13 -0000 Hi, On Thu, Jan 9, 2014 at 12:42 PM, Gleb Smirnoff wrote: > Guy, > > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. > G> The "pfctl -s state" command is crashing when trying to print the > G> second entry. > G> > G> (gdb) bt > G> #0 print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at > G> /usr/src/sbin/pfctl/pf_print_state.c:178 > G> #1 0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at > G> /usr/src/sbin/pfctl/pf_print_state.c:236 > G> #2 0x0000c664 in pfctl_show_states (dev=, > G> iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095 > G> > G> sizeof(struct pfsync_state_key) is 36 > G> sizeof(struct pfsync_state_peer) is 32 > G> sizeof(struct pf_addr) is 16 > G> sizeof(struct pfsync_state) is 242 > G> > > I will try to fix this making new structure for the ioctl. That will mean > moving slowly towards divorcing internal structures and ioctl ones. > > I'd appreciate if you file a PR on that, so that problem won't leave forgotten > in the mailing list. You can even code the bugfix :) > > Thanks! > > -- > Totus tuus, Glebius. I filled arm/185617 with some updated information. After further looking at why the kernel doesn't crash when filling the pfsync_state array and only the userspace pfctl is crashing I see that pfsync_state has the __packed attribute which means on arm unaligned access is used so there is no problem handling an unaligned pfsync_state. The reason pfctl crashes is because it passes a structure field as a pf_addr pointer. struct pf_addr is not __packed so on arm word access will be used, triggering the unaligned fault. So there is indeed no need to break the pfsync protocol. In if_pfsync.c I think all the accesses to pfsync_state are done using a pfsync_state pointer, there is no passing of struct fields as separate pointers and since the struct is covered by __packed there won't be an unaligned access. Thanks, Guy From owner-freebsd-arm@FreeBSD.ORG Thu Jan 9 22:26:11 2014 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 ESMTPS id C4D07366; Thu, 9 Jan 2014 22:26:11 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B7A715CD; Thu, 9 Jan 2014 22:26:11 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s09MQAGw058049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 14:26:10 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s09MQAlA058048; Thu, 9 Jan 2014 14:26:10 -0800 (PST) (envelope-from jmg) Date: Thu, 9 Jan 2014 14:26:10 -0800 From: John-Mark Gurney To: Guy Yur Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Message-ID: <20140109222610.GJ46596@funkthat.com> Mail-Followup-To: Guy Yur , Gleb Smirnoff , freebsd-net@freebsd.org, freebsd-arm@freebsd.org References: <20140109104223.GS71033@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 09 Jan 2014 14:26:10 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org, Gleb Smirnoff X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 22:26:11 -0000 Guy Yur wrote this message on Fri, Jan 10, 2014 at 00:17 +0200: > On Thu, Jan 9, 2014 at 12:42 PM, Gleb Smirnoff wrote: > > Guy, > > > > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: > > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. > > G> The "pfctl -s state" command is crashing when trying to print the > > G> second entry. > > > G> > > G> (gdb) bt > > G> #0 print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at > > G> /usr/src/sbin/pfctl/pf_print_state.c:178 > > G> #1 0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at > > G> /usr/src/sbin/pfctl/pf_print_state.c:236 > > G> #2 0x0000c664 in pfctl_show_states (dev=, > > G> iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095 > > G> > > G> sizeof(struct pfsync_state_key) is 36 > > G> sizeof(struct pfsync_state_peer) is 32 > > G> sizeof(struct pf_addr) is 16 > > G> sizeof(struct pfsync_state) is 242 > > G> > > > > > I will try to fix this making new structure for the ioctl. That will mean > > moving slowly towards divorcing internal structures and ioctl ones. > > > > I'd appreciate if you file a PR on that, so that problem won't leave forgotten > > in the mailing list. You can even code the bugfix :) > > > > Thanks! > > > > -- > > Totus tuus, Glebius. > > I filled arm/185617 with some updated information. > > After further looking at why the kernel doesn't crash when filling > the pfsync_state array and only the userspace pfctl is crashing I > see that pfsync_state has the __packed attribute which means on arm > unaligned access is used so there is no problem handling an unaligned > pfsync_state. > > The reason pfctl crashes is because it passes a structure field > as a pf_addr pointer. struct pf_addr is not __packed so on arm > word access will be used, triggering the unaligned fault. > > So there is indeed no need to break the pfsync protocol. > > In if_pfsync.c I think all the accesses to pfsync_state are done using > a pfsync_state pointer, there is no passing of struct fields as > separate pointers and since the struct is covered by __packed > there won't be an unaligned access. Ok, that makes sense... so, either we mark struct pf_addr as __packed, or we do some nasty stuff, like the following in print_host: struct { struct pf_addr a } *uaddr __packed; uaddr = addr; aw.v.a.addr = uaddr->a; it's not pretty, but I believe it would work... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu Jan 9 23:04:58 2014 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 ESMTPS id C1A0D380; Thu, 9 Jan 2014 23:04:58 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B61818A9; Thu, 9 Jan 2014 23:04:58 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id m1so4188985oag.24 for ; Thu, 09 Jan 2014 15:04:57 -0800 (PST) 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 :content-type; bh=kaghnQjANnNR0a9EpS6wbhrcoDcotmOGxSD7iava9U4=; b=Pb2OMVmCe7iPQ8sn2LvzrKzfbOszsvnrd1vSttKWVisBapudwP88tFHz/Pkhswp2g0 T3XGpZEjuOe+f0bpysdpNW7/av8yePVOtz4eYL6fFlfCwtOxywxnK2/Not9jtDzlt59z EpZAVPcI50SfXsUJwHDZfxteLudFeVm35vlmGvNauI93RlMDZ7gF316W/QHR38Ij2C/U Zi0pPYyrvNRVs1oJUWNcbCcG8p9vlOBgcY9qyGDVGg/npf2x5vCUzDJa9/U1feZd4uqr hQISnMzqLhqmGFcmAtkYIoyg5Helwogohpf3qKvnvfVEov2aIq5x8cBN1o18s+JEConR JNgA== MIME-Version: 1.0 X-Received: by 10.60.179.113 with SMTP id df17mr4501215oec.16.1389308697685; Thu, 09 Jan 2014 15:04:57 -0800 (PST) Received: by 10.76.20.82 with HTTP; Thu, 9 Jan 2014 15:04:57 -0800 (PST) In-Reply-To: <20140109222610.GJ46596@funkthat.com> References: <20140109104223.GS71033@FreeBSD.org> <20140109222610.GJ46596@funkthat.com> Date: Fri, 10 Jan 2014 01:04:57 +0200 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: Guy Yur , Gleb Smirnoff , freebsd-net@freebsd.org, freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary=089e011609bc6931ef04ef91a33c X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 23:04:58 -0000 --089e011609bc6931ef04ef91a33c Content-Type: text/plain; charset=UTF-8 On Fri, Jan 10, 2014 at 12:26 AM, John-Mark Gurney wrote: > Guy Yur wrote this message on Fri, Jan 10, 2014 at 00:17 +0200: >> On Thu, Jan 9, 2014 at 12:42 PM, Gleb Smirnoff wrote: >> > Guy, >> > >> > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: >> > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. >> > G> The "pfctl -s state" command is crashing when trying to print the >> > G> second entry. >> > Ok, that makes sense... so, either we mark struct pf_addr as __packed, > or we do some nasty stuff, like the following in print_host: > struct { > struct pf_addr a > } *uaddr __packed; > > uaddr = addr; > aw.v.a.addr = uaddr->a; > > it's not pretty, but I believe it would work... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." For performance reasons, I don't think pf_addr should be marked as __packed. I attached the changes I am now using in print_state() since there is no need to copy the full pfsync_state, only pf_addr. I converted sk and nk from pointers to structs on the stack and using struct copy. pf_addr is 16 bytes. Regards, Guy --089e011609bc6931ef04ef91a33c Content-Type: application/octet-stream; name="pf_print_state.patch" Content-Disposition: attachment; filename="pf_print_state.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hq8m4iyt0 SW5kZXg6IHBmY3RsL3BmX3ByaW50X3N0YXRlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gcGZjdGwvcGZfcHJp bnRfc3RhdGUuYwkocmV2aXNpb24gMjYwNDkyKQorKysgcGZjdGwvcGZfcHJpbnRfc3RhdGUuYwko d29ya2luZyBjb3B5KQpAQCAtMjA4LDcgKzIwOCw3IEBAIHZvaWQKIHByaW50X3N0YXRlKHN0cnVj dCBwZnN5bmNfc3RhdGUgKnMsIGludCBvcHRzKQogewogCXN0cnVjdCBwZnN5bmNfc3RhdGVfcGVl ciAqc3JjLCAqZHN0OwotCXN0cnVjdCBwZnN5bmNfc3RhdGVfa2V5ICpzaywgKm5rOworCXN0cnVj dCBwZnN5bmNfc3RhdGVfa2V5IHNrLCBuazsKIAlzdHJ1Y3QgcHJvdG9lbnQgKnA7CiAJaW50IG1p biwgc2VjOwogCkBAIC0yMTUsMTcgKzIxNSwxNyBAQCBwcmludF9zdGF0ZShzdHJ1Y3QgcGZzeW5j X3N0YXRlICpzLCBpbnQgb3B0cykKIAlpZiAocy0+ZGlyZWN0aW9uID09IFBGX09VVCkgewogCQlz cmMgPSAmcy0+c3JjOwogCQlkc3QgPSAmcy0+ZHN0OwotCQlzayA9ICZzLT5rZXlbUEZfU0tfU1RB Q0tdOwotCQluayA9ICZzLT5rZXlbUEZfU0tfV0lSRV07CisJCXNrID0gcy0+a2V5W1BGX1NLX1NU QUNLXTsKKwkJbmsgPSBzLT5rZXlbUEZfU0tfV0lSRV07CiAJCWlmIChzLT5wcm90byA9PSBJUFBS T1RPX0lDTVAgfHwgcy0+cHJvdG8gPT0gSVBQUk9UT19JQ01QVjYpIAotCQkJc2stPnBvcnRbMF0g PSBuay0+cG9ydFswXTsKKwkJCXNrLnBvcnRbMF0gPSBuay5wb3J0WzBdOwogCX0gZWxzZSB7CiAJ CXNyYyA9ICZzLT5kc3Q7CiAJCWRzdCA9ICZzLT5zcmM7Ci0JCXNrID0gJnMtPmtleVtQRl9TS19X SVJFXTsKLQkJbmsgPSAmcy0+a2V5W1BGX1NLX1NUQUNLXTsKKwkJc2sgPSBzLT5rZXlbUEZfU0tf V0lSRV07CisJCW5rID0gcy0+a2V5W1BGX1NLX1NUQUNLXTsKIAkJaWYgKHMtPnByb3RvID09IElQ UFJPVE9fSUNNUCB8fCBzLT5wcm90byA9PSBJUFBST1RPX0lDTVBWNikgCi0JCQlzay0+cG9ydFsx XSA9IG5rLT5wb3J0WzFdOworCQkJc2sucG9ydFsxXSA9IG5rLnBvcnRbMV07CiAJfQogCXByaW50 ZigiJXMgIiwgcy0+aWZuYW1lKTsKIAlpZiAoKHAgPSBnZXRwcm90b2J5bnVtYmVyKHMtPnByb3Rv KSkgIT0gTlVMTCkKQEAgLTIzMywxMSArMjMzLDExIEBAIHByaW50X3N0YXRlKHN0cnVjdCBwZnN5 bmNfc3RhdGUgKnMsIGludCBvcHRzKQogCWVsc2UKIAkJcHJpbnRmKCIldSAiLCBzLT5wcm90byk7 CiAKLQlwcmludF9ob3N0KCZuay0+YWRkclsxXSwgbmstPnBvcnRbMV0sIHMtPmFmLCBvcHRzKTsK LQlpZiAoUEZfQU5FUSgmbmstPmFkZHJbMV0sICZzay0+YWRkclsxXSwgcy0+YWYpIHx8Ci0JICAg IG5rLT5wb3J0WzFdICE9IHNrLT5wb3J0WzFdKSB7CisJcHJpbnRfaG9zdCgmbmsuYWRkclsxXSwg bmsucG9ydFsxXSwgcy0+YWYsIG9wdHMpOworCWlmIChQRl9BTkVRKCZuay5hZGRyWzFdLCAmc2su YWRkclsxXSwgcy0+YWYpIHx8CisJICAgIG5rLnBvcnRbMV0gIT0gc2sucG9ydFsxXSkgewogCQlw cmludGYoIiAoIik7Ci0JCXByaW50X2hvc3QoJnNrLT5hZGRyWzFdLCBzay0+cG9ydFsxXSwgcy0+ YWYsIG9wdHMpOworCQlwcmludF9ob3N0KCZzay5hZGRyWzFdLCBzay5wb3J0WzFdLCBzLT5hZiwg b3B0cyk7CiAJCXByaW50ZigiKSIpOwogCX0KIAlpZiAocy0+ZGlyZWN0aW9uID09IFBGX09VVCkK QEAgLTI0NCwxMSArMjQ0LDExIEBAIHByaW50X3N0YXRlKHN0cnVjdCBwZnN5bmNfc3RhdGUgKnMs IGludCBvcHRzKQogCQlwcmludGYoIiAtPiAiKTsKIAllbHNlCiAJCXByaW50ZigiIDwtICIpOwot CXByaW50X2hvc3QoJm5rLT5hZGRyWzBdLCBuay0+cG9ydFswXSwgcy0+YWYsIG9wdHMpOwotCWlm IChQRl9BTkVRKCZuay0+YWRkclswXSwgJnNrLT5hZGRyWzBdLCBzLT5hZikgfHwKLQkgICAgbmst PnBvcnRbMF0gIT0gc2stPnBvcnRbMF0pIHsKKwlwcmludF9ob3N0KCZuay5hZGRyWzBdLCBuay5w b3J0WzBdLCBzLT5hZiwgb3B0cyk7CisJaWYgKFBGX0FORVEoJm5rLmFkZHJbMF0sICZzay5hZGRy WzBdLCBzLT5hZikgfHwKKwkgICAgbmsucG9ydFswXSAhPSBzay5wb3J0WzBdKSB7CiAJCXByaW50 ZigiICgiKTsKLQkJcHJpbnRfaG9zdCgmc2stPmFkZHJbMF0sIHNrLT5wb3J0WzBdLCBzLT5hZiwg b3B0cyk7CisJCXByaW50X2hvc3QoJnNrLmFkZHJbMF0sIHNrLnBvcnRbMF0sIHMtPmFmLCBvcHRz KTsKIAkJcHJpbnRmKCIpIik7CiAJfQogCg== --089e011609bc6931ef04ef91a33c-- From owner-freebsd-arm@FreeBSD.ORG Thu Jan 9 23:39:00 2014 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 ESMTPS id 0D91A12B; Thu, 9 Jan 2014 23:39:00 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D807E1AEE; Thu, 9 Jan 2014 23:38:59 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s09Ncwm9059056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 15:38:59 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s09Ncwe2059055; Thu, 9 Jan 2014 15:38:58 -0800 (PST) (envelope-from jmg) Date: Thu, 9 Jan 2014 15:38:58 -0800 From: John-Mark Gurney To: Guy Yur Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Message-ID: <20140109233858.GL46596@funkthat.com> Mail-Followup-To: Guy Yur , Gleb Smirnoff , freebsd-net@freebsd.org, freebsd-arm@freebsd.org References: <20140109104223.GS71033@FreeBSD.org> <20140109222610.GJ46596@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 09 Jan 2014 15:38:59 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org, Gleb Smirnoff X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 23:39:00 -0000 Guy Yur wrote this message on Fri, Jan 10, 2014 at 01:04 +0200: > On Fri, Jan 10, 2014 at 12:26 AM, John-Mark Gurney wrote: > > Guy Yur wrote this message on Fri, Jan 10, 2014 at 00:17 +0200: > >> On Thu, Jan 9, 2014 at 12:42 PM, Gleb Smirnoff wrote: > >> > Guy, > >> > > >> > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: > >> > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. > >> > G> The "pfctl -s state" command is crashing when trying to print the > >> > G> second entry. > >> > > > Ok, that makes sense... so, either we mark struct pf_addr as __packed, > > or we do some nasty stuff, like the following in print_host: > > struct { > > struct pf_addr a > > } *uaddr __packed; > > > > uaddr = addr; > > aw.v.a.addr = uaddr->a; > > > > it's not pretty, but I believe it would work... > > For performance reasons, I don't think pf_addr should be marked as __packed. > > I attached the changes I am now using in print_state() since there is > no need to copy > the full pfsync_state, only pf_addr. > I converted sk and nk from pointers to structs on the stack and using > struct copy. > pf_addr is 16 bytes. Did you look at using the above trick? Since we are iterating over a list, that'll be a lot of copies, plus, I'm not sure that your fix will be guaranteed to work for ever.. since there isn't a requirement that the copy happens w/ bcopy/memcpy or some other copy routine that assumes things might not be aligned... Specificly these: - sk = &s->key[PF_SK_STACK]; - nk = &s->key[PF_SK_WIRE]; + sk = s->key[PF_SK_STACK]; + nk = s->key[PF_SK_WIRE]; since s->key is already assumed to be aligned, a future compiler could be smart enough to say, I'm not going to use the stack.. That would/could happen if print_host's addr arg grew a const which it could... Also, I just realized that some of the lines modify sk (setting port), but you don't write those modifications back to s->key[PF_SK_STACK]... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Fri Jan 10 11:56:34 2014 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 ESMTPS id E8729E81; Fri, 10 Jan 2014 11:56:33 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DD74152D; Fri, 10 Jan 2014 11:56:33 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id l6so4849351oag.19 for ; Fri, 10 Jan 2014 03:56:33 -0800 (PST) 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 :content-type; bh=sLUlKQy0MoIiYGhsbK3mHa3pgCcUvH7CqSp3nhZhKa0=; b=dvGRpu/ULv0x1ynxhtYNNwFCC8V/lsirExSkHf3mm8UerHprJPcM+N9KRtYRiUUR+D xTOTcMIqREmUaasz769unCrgKXDBCpZ/sDQesASfYhZSnUbSYDRyvACb5GTPyrwfqEk2 KyuzQNybPlKQrleEhclLPa6ai+ko07qRXczMinklJ1mZu1kk5o+Oil9QuIxAES/iZKF0 WDpoJ+GMsH/OAT9qFMVAdyeaJcOZNuOsaKObufUIsgN2NYZQq3Qt8n0TwCx4BDCs94g4 MrdjDNImfdZXVAMATXPZlwMel7JQGbdfBTw6b/pC93LosJLticcwreQ/Eo8/60cLkfXl nvkw== MIME-Version: 1.0 X-Received: by 10.60.62.199 with SMTP id a7mr1778866oes.64.1389354992911; Fri, 10 Jan 2014 03:56:32 -0800 (PST) Received: by 10.76.20.82 with HTTP; Fri, 10 Jan 2014 03:56:32 -0800 (PST) In-Reply-To: <20140109233858.GL46596@funkthat.com> References: <20140109104223.GS71033@FreeBSD.org> <20140109222610.GJ46596@funkthat.com> <20140109233858.GL46596@funkthat.com> Date: Fri, 10 Jan 2014 13:56:32 +0200 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 11:56:34 -0000 On Fri, Jan 10, 2014 at 1:38 AM, John-Mark Gurney wrote: > Guy Yur wrote this message on Fri, Jan 10, 2014 at 01:04 +0200: >> On Fri, Jan 10, 2014 at 12:26 AM, John-Mark Gurney wrote: >> > Guy Yur wrote this message on Fri, Jan 10, 2014 at 00:17 +0200: >> >> On Thu, Jan 9, 2014 at 12:42 PM, Gleb Smirnoff wrote: >> >> > Guy, >> >> > >> >> > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: >> >> > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. >> >> > G> The "pfctl -s state" command is crashing when trying to print the >> >> > G> second entry. >> >> >> >> > Ok, that makes sense... so, either we mark struct pf_addr as __packed, >> > or we do some nasty stuff, like the following in print_host: >> > struct { >> > struct pf_addr a >> > } *uaddr __packed; >> > >> > uaddr = addr; >> > aw.v.a.addr = uaddr->a; >> > >> > it's not pretty, but I believe it would work... >> >> For performance reasons, I don't think pf_addr should be marked as __packed. >> >> I attached the changes I am now using in print_state() since there is >> no need to copy >> the full pfsync_state, only pf_addr. >> I converted sk and nk from pointers to structs on the stack and using >> struct copy. >> pf_addr is 16 bytes. > > Did you look at using the above trick? > > Since we are iterating over a list, that'll be a lot of copies, plus, > I'm not sure that your fix will be guaranteed to work for ever.. since > there isn't a requirement that the copy happens w/ bcopy/memcpy or some > other copy routine that assumes things might not be aligned... > Right. The correct fix would be to have a separate struct for the ioctl that can be aligned as Gleb suggested. I will try to prepare and test such changes. If new ioctls are added, the KBI can also be preserved. pfsync_state_export is used by if_pfsync.c and pf_ioctl.c so there will be duplicated code even if reusing the old ioctls with the new struct. > Specificly these: > - sk = &s->key[PF_SK_STACK]; > - nk = &s->key[PF_SK_WIRE]; > + sk = s->key[PF_SK_STACK]; > + nk = s->key[PF_SK_WIRE]; > > since s->key is already assumed to be aligned, a future compiler could > be smart enough to say, I'm not going to use the stack.. That > would/could happen if print_host's addr arg grew a const which it > could... > I thought that because s itself is __packed and key is an array inside s the __packed will apply to it too, since the disassembly showed clang chose to do a memcpy, I don't know if that is true or not. An explicit bcopy is safer. I see that the function already does a bcopy of the u_int64_t id field so it has some assumption that the structure might not be aligned. If a new always aligned structure is used for the ioctl, the bcopy of id can also be avoided. > Also, I just realized that some of the lines modify sk (setting port), > but you don't write those modifications back to s->key[PF_SK_STACK]... > The print function doesn't need to modify s->key, the port changes are only for passing to print_host. > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." Regards, Guy From owner-freebsd-arm@FreeBSD.ORG Fri Jan 10 23:02:48 2014 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 ESMTPS id D8EE244D; Fri, 10 Jan 2014 23:02:48 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9270618D3; Fri, 10 Jan 2014 23:02:48 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s0AN2fOD077988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 15:02:41 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s0AN2fd4077987; Fri, 10 Jan 2014 15:02:41 -0800 (PST) (envelope-from jmg) Date: Fri, 10 Jan 2014 15:02:41 -0800 From: John-Mark Gurney To: Ian Lepore , freebsd-arm@FreeBSD.org Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Message-ID: <20140110230241.GS46596@funkthat.com> Mail-Followup-To: Ian Lepore , freebsd-arm@FreeBSD.org, andrew@FreeBSD.org References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140108173909.GF99167@funkthat.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 10 Jan 2014 15:02:42 -0800 (PST) Cc: andrew@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 23:02:48 -0000 John-Mark Gurney wrote this message on Wed, Jan 08, 2014 at 09:39 -0800: > So, I've tested that HEAD (absolutely no tree changes) w/ > WITHOUT_ARM_EABI boots fine... and just to make sure my test is > correct, I've disabled it too to verify that the kernel just hangs > (absolutely no output).. and reenabled it and verified it works (that > my setting is changing something)... > worky -> no worky -> worky... > > Now I just realized another interesting thing about setting > WITHOUT_ARM_EABI, it also fixes the console issue I was having w/ your > call to cpu_setup("") previously (w/ EABI) killing console output and > not even seeing the mtx panic message... > > So, it is clearly changing something very early on in boot... Apparently gcc ARMEB w/ EABI miscompiles code... The code to store lo_flags in the lock_object is correct: lock->lo_flags = i << LO_CLASSSHIFT; c03ce2d0: e1a01c06 lsl r1, r6, #24 c03ce2d4: e5881004 str r1, [r8, #4] But when I add a printf to fetch the data, I get: printf("lo_classindex: %#x\n", LO_CLASSINDEX(lock)); c03ce2e0: e5d81007 ldrb r1, [r8, #7] c03ce2e4: e59f0098 ldr r0, [pc, #152] ; c03ce384 <_end+0xffcf9 19c> c03ce2e8: e201100f and r1, r1, #15 ; 0xf c03ce2ec: eb0012ea bl c03d2e9c We are doing a ldrb (LoaD Relative Byte) which would be fine to substitute for the right shift of 24, but only if it loaded the correct byte.. It should be loading #4 instead of #7 since we are on big endian... Anyone who know gcc arm well to figure this out? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Fri Jan 10 23:41:38 2014 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 ESMTPS id 44168D6C; Fri, 10 Jan 2014 23:41:38 +0000 (UTC) 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 13D491B63; Fri, 10 Jan 2014 23:41:37 +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 1W1lhi-000CYF-VA; Fri, 10 Jan 2014 23:41: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 s0ANfRTf033398; Fri, 10 Jan 2014 16:41:27 -0700 (MST) (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/HiZM1Fa5UuvPB1ERDpQWV Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20140110230241.GS46596@funkthat.com> References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> <20140110230241.GS46596@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Jan 2014 16:41:27 -0700 Message-ID: <1389397287.1158.462.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: andrew@FreeBSD.org, freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 23:41:38 -0000 On Fri, 2014-01-10 at 15:02 -0800, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Wed, Jan 08, 2014 at 09:39 -0800: > > So, I've tested that HEAD (absolutely no tree changes) w/ > > WITHOUT_ARM_EABI boots fine... and just to make sure my test is > > correct, I've disabled it too to verify that the kernel just hangs > > (absolutely no output).. and reenabled it and verified it works (that > > my setting is changing something)... > > worky -> no worky -> worky... > > > > Now I just realized another interesting thing about setting > > WITHOUT_ARM_EABI, it also fixes the console issue I was having w/ your > > call to cpu_setup("") previously (w/ EABI) killing console output and > > not even seeing the mtx panic message... > > > > So, it is clearly changing something very early on in boot... > > Apparently gcc ARMEB w/ EABI miscompiles code... The code to store > lo_flags in the lock_object is correct: > lock->lo_flags = i << LO_CLASSSHIFT; > c03ce2d0: e1a01c06 lsl r1, r6, #24 > c03ce2d4: e5881004 str r1, [r8, #4] > > But when I add a printf to fetch the data, I get: > printf("lo_classindex: %#x\n", LO_CLASSINDEX(lock)); > c03ce2e0: e5d81007 ldrb r1, [r8, #7] > c03ce2e4: e59f0098 ldr r0, [pc, #152] ; c03ce384 <_end+0xffcf9 > 19c> > c03ce2e8: e201100f and r1, r1, #15 ; 0xf > c03ce2ec: eb0012ea bl c03d2e9c > > > We are doing a ldrb (LoaD Relative Byte) which would be fine to > substitute for the right shift of 24, but only if it loaded the correct > byte.. It should be loading #4 instead of #7 since we are on big > endian... > > Anyone who know gcc arm well to figure this out? > The generated byte-load code is enough different from the literal "load 32 bits and shift" of LO_CLASSINDEX() that the optimizer must have messed it up. Do we build the kernel with -O2, and if so would -O1 help? -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Jan 11 00:26:50 2014 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 ESMTPS id 32D8B5AE; Sat, 11 Jan 2014 00:26:50 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 08ADB1EE2; Sat, 11 Jan 2014 00:26:49 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s0B0Qmij079024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 16:26:49 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s0B0Qmno079023; Fri, 10 Jan 2014 16:26:48 -0800 (PST) (envelope-from jmg) Date: Fri, 10 Jan 2014 16:26:48 -0800 From: John-Mark Gurney To: Ian Lepore Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Message-ID: <20140111002648.GT46596@funkthat.com> Mail-Followup-To: Ian Lepore , freebsd-arm@FreeBSD.org, andrew@FreeBSD.org References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> <20140110230241.GS46596@funkthat.com> <1389397287.1158.462.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1389397287.1158.462.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 10 Jan 2014 16:26:49 -0800 (PST) Cc: andrew@FreeBSD.org, freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 00:26:50 -0000 Ian Lepore wrote this message on Fri, Jan 10, 2014 at 16:41 -0700: > On Fri, 2014-01-10 at 15:02 -0800, John-Mark Gurney wrote: > > John-Mark Gurney wrote this message on Wed, Jan 08, 2014 at 09:39 -0800: > > > So, I've tested that HEAD (absolutely no tree changes) w/ > > > WITHOUT_ARM_EABI boots fine... and just to make sure my test is > > > correct, I've disabled it too to verify that the kernel just hangs > > > (absolutely no output).. and reenabled it and verified it works (that > > > my setting is changing something)... > > > worky -> no worky -> worky... > > > > > > Now I just realized another interesting thing about setting > > > WITHOUT_ARM_EABI, it also fixes the console issue I was having w/ your > > > call to cpu_setup("") previously (w/ EABI) killing console output and > > > not even seeing the mtx panic message... > > > > > > So, it is clearly changing something very early on in boot... > > > > Apparently gcc ARMEB w/ EABI miscompiles code... The code to store > > lo_flags in the lock_object is correct: > > lock->lo_flags = i << LO_CLASSSHIFT; > > c03ce2d0: e1a01c06 lsl r1, r6, #24 > > c03ce2d4: e5881004 str r1, [r8, #4] > > > > But when I add a printf to fetch the data, I get: > > printf("lo_classindex: %#x\n", LO_CLASSINDEX(lock)); > > c03ce2e0: e5d81007 ldrb r1, [r8, #7] > > c03ce2e4: e59f0098 ldr r0, [pc, #152] ; c03ce384 <_end+0xffcf9 > > 19c> > > c03ce2e8: e201100f and r1, r1, #15 ; 0xf > > c03ce2ec: eb0012ea bl c03d2e9c > > > > > > We are doing a ldrb (LoaD Relative Byte) which would be fine to > > substitute for the right shift of 24, but only if it loaded the correct > > byte.. It should be loading #4 instead of #7 since we are on big > > endian... > > > > Anyone who know gcc arm well to figure this out? > > > > The generated byte-load code is enough different from the literal "load > 32 bits and shift" of LO_CLASSINDEX() that the optimizer must have > messed it up. Do we build the kernel with -O2, and if so would -O1 > help? In a generated test case, even -O1 produces broken code... Only -O0 looks like it produces correct code, though the code is so much more verbose, it takes more work to verify... code: int foo(int *b) { return (*b & 0xf000000) >> 24; } -O0: 00000000 : 0: e1a0c00d mov ip, sp 4: e92dd800 push {fp, ip, lr, pc} 8: e24cb004 sub fp, ip, #4 ; 0x4 c: e24dd004 sub sp, sp, #4 ; 0x4 10: e50b0010 str r0, [fp, #-16] 14: e51b3010 ldr r3, [fp, #-16] 18: e5933000 ldr r3, [r3] 1c: e203340f and r3, r3, #251658240 ; 0xf000000 20: e1a03c43 asr r3, r3, #24 24: e1a00003 mov r0, r3 28: e89da808 ldm sp, {r3, fp, sp, pc} -O1 & -O2: 00000000 : 0: e5d00000 ldrb r0, [r0] 4: e200000f and r0, r0, #15 ; 0xf 8: e12fff1e bx lr -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Jan 11 04:37:41 2014 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 ESMTPS id 150E0DEE for ; Sat, 11 Jan 2014 04:37:41 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD5F51FD2 for ; Sat, 11 Jan 2014 04:37:40 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id ar20so1874774iec.39 for ; Fri, 10 Jan 2014 20:37:33 -0800 (PST) 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=sQycZA7aQnIzEAZ47aH+PkKhZlG7+5ERivPxPBQJ0UU=; b=Y3dDItCPyHXmua5HSs5AKzV6menYZmQVFGIhuyIkKouW46dT5p4/SOOT1mdhB2bfO9 NA6Obl9jcIthJIxvl/qZRh1PJOA3AeAL4jXTUELHw3iYSthrCAImvBiXxyjSR46bM17/ vQWZKqHShwWzcwaAuCawU33KJwMstJfB6EQpgtf9jUMRlKXdkvypHqEuNp/PqEPtPHHC otaD2zV/rIBAF5sObhcUAAfdJLuJX2Bt6fS8XXbWEXOMDEYdxwgvJ/W+gLaq423ChyEZ bNJG2zC4k9TPWYnqKq+5uX77FW4mR3tWl9J6eV8MU1xQrvsHwdWx+9SDHWKMQAJI9Jfa VdrA== X-Gm-Message-State: ALoCoQlyRsLPoKjw48gBDNUhqhRf9A39/2DjpD/kLD8Y6lRSAgsT0A5RRhOvszwsaOqze6nZOWxb X-Received: by 10.43.138.8 with SMTP id iq8mr11560152icc.37.1389415053811; Fri, 10 Jan 2014 20:37:33 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id u1sm6350762ige.1.2014.01.10.20.37.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jan 2014 20:37:33 -0800 (PST) Sender: Warner Losh Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20140111002648.GT46596@funkthat.com> Date: Fri, 10 Jan 2014 21:37:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> <20140110230241.GS46596@funkthat.com> <1389397287.1158.462.camel@revolution.hippie.lan> <20140111002648.GT46596@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1085) Cc: andrew@FreeBSD.org, freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 04:37:41 -0000 On Jan 10, 2014, at 5:26 PM, John-Mark Gurney wrote: > Ian Lepore wrote this message on Fri, Jan 10, 2014 at 16:41 -0700: >> On Fri, 2014-01-10 at 15:02 -0800, John-Mark Gurney wrote: >>> John-Mark Gurney wrote this message on Wed, Jan 08, 2014 at 09:39 = -0800: >>>> So, I've tested that HEAD (absolutely no tree changes) w/ >>>> WITHOUT_ARM_EABI boots fine... and just to make sure my test is >>>> correct, I've disabled it too to verify that the kernel just hangs >>>> (absolutely no output).. and reenabled it and verified it works = (that >>>> my setting is changing something)... >>>> worky -> no worky -> worky... >>>>=20 >>>> Now I just realized another interesting thing about setting >>>> WITHOUT_ARM_EABI, it also fixes the console issue I was having w/ = your >>>> call to cpu_setup("") previously (w/ EABI) killing console output = and >>>> not even seeing the mtx panic message... >>>>=20 >>>> So, it is clearly changing something very early on in boot... >>>=20 >>> Apparently gcc ARMEB w/ EABI miscompiles code... The code to store >>> lo_flags in the lock_object is correct: >>> lock->lo_flags =3D i << LO_CLASSSHIFT; >>> c03ce2d0: e1a01c06 lsl r1, r6, #24 >>> c03ce2d4: e5881004 str r1, [r8, #4] >>>=20 >>> But when I add a printf to fetch the data, I get: >>> printf("lo_classindex: %#x\n", LO_CLASSINDEX(lock)); >>> c03ce2e0: e5d81007 ldrb r1, [r8, #7] >>> c03ce2e4: e59f0098 ldr r0, [pc, #152] ; c03ce384 = <_end+0xffcf9 >>> 19c> >>> c03ce2e8: e201100f and r1, r1, #15 ; 0xf >>> c03ce2ec: eb0012ea bl c03d2e9c >>>=20 >>>=20 >>> We are doing a ldrb (LoaD Relative Byte) which would be fine to >>> substitute for the right shift of 24, but only if it loaded the = correct >>> byte.. It should be loading #4 instead of #7 since we are on big >>> endian... >>>=20 >>> Anyone who know gcc arm well to figure this out? >>>=20 >>=20 >> The generated byte-load code is enough different from the literal = "load >> 32 bits and shift" of LO_CLASSINDEX() that the optimizer must have >> messed it up. Do we build the kernel with -O2, and if so would -O1 >> help? >=20 > In a generated test case, even -O1 produces broken code... Only -O0 > looks like it produces correct code, though the code is so much more > verbose, it takes more work to verify... Maybe there's a specific optimization that can be disabled instead? = Maybe you can try the ones that are enabled between O0 and O1. Since you = have the setup, maybe you could look... Warner > code: > int > foo(int *b) > { > return (*b & 0xf000000) >> 24; > } >=20 > -O0: > 00000000 : > 0: e1a0c00d mov ip, sp > 4: e92dd800 push {fp, ip, lr, pc} > 8: e24cb004 sub fp, ip, #4 ; 0x4 > c: e24dd004 sub sp, sp, #4 ; 0x4 > 10: e50b0010 str r0, [fp, #-16] > 14: e51b3010 ldr r3, [fp, #-16] > 18: e5933000 ldr r3, [r3] > 1c: e203340f and r3, r3, #251658240 ; 0xf000000 > 20: e1a03c43 asr r3, r3, #24 > 24: e1a00003 mov r0, r3 > 28: e89da808 ldm sp, {r3, fp, sp, pc} >=20 > -O1 & -O2: > 00000000 : > 0: e5d00000 ldrb r0, [r0] > 4: e200000f and r0, r0, #15 ; 0xf > 8: e12fff1e bx lr >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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 Sat Jan 11 14:00:13 2014 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 ESMTPS id AB138921; Sat, 11 Jan 2014 14:00:13 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 8891D14BF; Sat, 11 Jan 2014 14:00:13 +0000 (UTC) Received: from bender.Home (97e07ae8.skybroadband.com [151.224.122.232]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 58D2B5DFFE; Sat, 11 Jan 2014 13:52:02 +0000 (UTC) Date: Sat, 11 Jan 2014 13:51:56 +0000 From: Andrew Turner To: John-Mark Gurney Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Message-ID: <20140111135156.251a70fa@bender.Home> In-Reply-To: <20140110230241.GS46596@funkthat.com> References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> <20140110230241.GS46596@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: andrew@FreeBSD.org, freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 14:00:13 -0000 On Fri, 10 Jan 2014 15:02:41 -0800 John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Wed, Jan 08, 2014 at 09:39 > -0800: > > So, I've tested that HEAD (absolutely no tree changes) w/ > > WITHOUT_ARM_EABI boots fine... and just to make sure my test is > > correct, I've disabled it too to verify that the kernel just hangs > > (absolutely no output).. and reenabled it and verified it works > > (that my setting is changing something)... > > worky -> no worky -> worky... > > > > Now I just realized another interesting thing about setting > > WITHOUT_ARM_EABI, it also fixes the console issue I was having w/ > > your call to cpu_setup("") previously (w/ EABI) killing console > > output and not even seeing the mtx panic message... > > > > So, it is clearly changing something very early on in boot... > > Apparently gcc ARMEB w/ EABI miscompiles code... The code to store > lo_flags in the lock_object is correct: > lock->lo_flags = i << LO_CLASSSHIFT; > c03ce2d0: e1a01c06 lsl r1, r6, #24 > c03ce2d4: e5881004 str r1, [r8, #4] > > But when I add a printf to fetch the data, I get: > printf("lo_classindex: %#x\n", LO_CLASSINDEX(lock)); > c03ce2e0: e5d81007 ldrb r1, [r8, #7] > c03ce2e4: e59f0098 ldr r0, [pc, #152] ; c03ce384 > <_end+0xffcf9 > 19c> > c03ce2e8: e201100f and r1, r1, #15 ; 0xf > c03ce2ec: eb0012ea bl c03d2e9c > > > We are doing a ldrb (LoaD Relative Byte) which would be fine to > substitute for the right shift of 24, but only if it loaded the > correct byte.. It should be loading #4 instead of #7 since we are on > big endian... > > Anyone who know gcc arm well to figure this out? > I have an untested fix at [1]. As I don't have any big-endian boards I am unable to test the kernel with this. Andrew [1] http://people.freebsd.org/~andrew/armeb_gcc.diff From owner-freebsd-arm@FreeBSD.ORG Sat Jan 11 18:49:03 2014 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 ESMTPS id C354FE4 for ; Sat, 11 Jan 2014 18:49:03 +0000 (UTC) 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 9F8F517B6 for ; Sat, 11 Jan 2014 18:49:03 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s0BImtkS005615 for freebsd-arm@freebsd.org; Sat, 11 Jan 2014 18:48:55 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (gateway.kientzle.com [192.168.1.65]) by kientzle.com with SMTP id wxtdv9p3wyfc2dt4afaqx4y3qe; for freebsd-arm@freebsd.org; Sat, 11 Jan 2014 18:48:55 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Obtaining an RPi with Micron RAM? Message-Id: <5E418613-8869-4FD5-AF8F-3E1BF6DE0412@freebsd.org> Date: Sat, 11 Jan 2014 10:48:55 -0800 To: freebsd-arm ml Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 18:49:03 -0000 Apparently, different RPis have different RAM chips which require slightly different boot support. I'd like to test some boot changes across the different board versions but don't know where to obtain an RPi with the Micron RAM. (The new one I just bought has the same Samsung RAM as my old one.) If you have an RPi with "M" logo on the RAM chip, could you please reply direct to me and let me know *where* you bought it from so I can get one of my own? If you happen to be located near me (I'm in the SF Bay Area) and would be willing to swap, that would be even better. Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Sat Jan 11 20:53:05 2014 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 ESMTPS id 1B40367C; Sat, 11 Jan 2014 20:53:05 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E662F13D9; Sat, 11 Jan 2014 20:53:04 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s0BKr3DJ094951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Jan 2014 12:53:04 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s0BKr3E1094950; Sat, 11 Jan 2014 12:53:03 -0800 (PST) (envelope-from jmg) Date: Sat, 11 Jan 2014 12:53:03 -0800 From: John-Mark Gurney To: Andrew Turner Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Message-ID: <20140111205303.GZ46596@funkthat.com> Mail-Followup-To: Andrew Turner , Ian Lepore , freebsd-arm@FreeBSD.org, andrew@FreeBSD.org References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> <20140110230241.GS46596@funkthat.com> <20140111135156.251a70fa@bender.Home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140111135156.251a70fa@bender.Home> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 11 Jan 2014 12:53:04 -0800 (PST) Cc: andrew@FreeBSD.org, freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 20:53:05 -0000 Andrew Turner wrote this message on Sat, Jan 11, 2014 at 13:51 +0000: > On Fri, 10 Jan 2014 15:02:41 -0800 > John-Mark Gurney wrote: > > > John-Mark Gurney wrote this message on Wed, Jan 08, 2014 at 09:39 > > -0800: > > > So, I've tested that HEAD (absolutely no tree changes) w/ > > > WITHOUT_ARM_EABI boots fine... and just to make sure my test is > > > correct, I've disabled it too to verify that the kernel just hangs > > > (absolutely no output).. and reenabled it and verified it works > > > (that my setting is changing something)... > > > worky -> no worky -> worky... > > > > > > Now I just realized another interesting thing about setting > > > WITHOUT_ARM_EABI, it also fixes the console issue I was having w/ > > > your call to cpu_setup("") previously (w/ EABI) killing console > > > output and not even seeing the mtx panic message... > > > > > > So, it is clearly changing something very early on in boot... > > > > Apparently gcc ARMEB w/ EABI miscompiles code... The code to store > > lo_flags in the lock_object is correct: > > lock->lo_flags = i << LO_CLASSSHIFT; > > c03ce2d0: e1a01c06 lsl r1, r6, #24 > > c03ce2d4: e5881004 str r1, [r8, #4] > > > > But when I add a printf to fetch the data, I get: > > printf("lo_classindex: %#x\n", LO_CLASSINDEX(lock)); > > c03ce2e0: e5d81007 ldrb r1, [r8, #7] > > c03ce2e4: e59f0098 ldr r0, [pc, #152] ; c03ce384 > > <_end+0xffcf9 > > 19c> > > c03ce2e8: e201100f and r1, r1, #15 ; 0xf > > c03ce2ec: eb0012ea bl c03d2e9c > > > > > > We are doing a ldrb (LoaD Relative Byte) which would be fine to > > substitute for the right shift of 24, but only if it loaded the > > correct byte.. It should be loading #4 instead of #7 since we are on > > big endian... > > > > Anyone who know gcc arm well to figure this out? > > > > I have an untested fix at [1]. As I don't have any big-endian boards I > am unable to test the kernel with this. > > Andrew > > [1] http://people.freebsd.org/~andrew/armeb_gcc.diff I have verified that this patch allows me to boot a kernel till it mounts root... As I haven't put together a root fs yet, I can't say if it goes to single/multiuser yet... Thanks! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Jan 11 21:00:42 2014 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 ESMTPS id C498B8EE for ; Sat, 11 Jan 2014 21:00:42 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88CF514D3 for ; Sat, 11 Jan 2014 21:00:42 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id u16so4171434iet.4 for ; Sat, 11 Jan 2014 13:00:35 -0800 (PST) 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=SFNd6GZKJiMYwZaU/m6ZQ5m3DtEr8JgU78VO1i/yTbc=; b=B4JkuvaWYCWCNYRojrskIHsrHMW3/ZPBReqZZaYiAYqIT6cnBZjQP1+zltz4P6vtLb KnmgbvRU7w1G7CsKUyQBExj+TPlar2CDnBrlF6oXnGaVZ44BFYTBKb6S6W9MRv8ozZJ/ h/up/LK/yzqzQUIbtXjwqw7dFPLIACw4byK0CH140oFuDcfFL28bIVx6nxuwd0LZzsh2 gXMYWzcr9XFDtjrb2S0aOcmdECpajTqe99EjSjI2allff5Xqz6zr2SOVnmusAl6VSWO0 p6ysv96fpW411HW9NFJdTDAEBx0VQSDsZSDOmgIoViz0T/UEyewO81cu3LrcVoltr9Pw fGCQ== X-Gm-Message-State: ALoCoQk95SWyff/PStiY+1/7pYMAOxS4qo3Re4rjqWFC9HPt/C2Nq+O8I/icXOqXS4XIqv0wkUud X-Received: by 10.42.84.195 with SMTP id n3mr14455415icl.9.1389474035824; Sat, 11 Jan 2014 13:00:35 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id fk5sm9698786igb.9.2014.01.11.13.00.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 Jan 2014 13:00:35 -0800 (PST) Sender: Warner Losh Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20140111205303.GZ46596@funkthat.com> Date: Sat, 11 Jan 2014 14:00:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> <20140110230241.GS46596@funkthat.com> <20140111135156.251a70fa@bender.Home> <20140111205303.GZ46596@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1085) Cc: andrew@FreeBSD.org, freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 21:00:42 -0000 On Jan 11, 2014, at 1:53 PM, John-Mark Gurney wrote: > Andrew Turner wrote this message on Sat, Jan 11, 2014 at 13:51 +0000: >> On Fri, 10 Jan 2014 15:02:41 -0800 >> John-Mark Gurney wrote: >>=20 >>> John-Mark Gurney wrote this message on Wed, Jan 08, 2014 at 09:39 >>> -0800: >>>> So, I've tested that HEAD (absolutely no tree changes) w/ >>>> WITHOUT_ARM_EABI boots fine... and just to make sure my test is >>>> correct, I've disabled it too to verify that the kernel just hangs >>>> (absolutely no output).. and reenabled it and verified it works >>>> (that my setting is changing something)... >>>> worky -> no worky -> worky... >>>>=20 >>>> Now I just realized another interesting thing about setting >>>> WITHOUT_ARM_EABI, it also fixes the console issue I was having w/ >>>> your call to cpu_setup("") previously (w/ EABI) killing console >>>> output and not even seeing the mtx panic message... >>>>=20 >>>> So, it is clearly changing something very early on in boot... >>>=20 >>> Apparently gcc ARMEB w/ EABI miscompiles code... The code to store >>> lo_flags in the lock_object is correct: >>> lock->lo_flags =3D i << LO_CLASSSHIFT; >>> c03ce2d0: e1a01c06 lsl r1, r6, #24 >>> c03ce2d4: e5881004 str r1, [r8, #4] >>>=20 >>> But when I add a printf to fetch the data, I get: >>> printf("lo_classindex: %#x\n", LO_CLASSINDEX(lock)); >>> c03ce2e0: e5d81007 ldrb r1, [r8, #7] >>> c03ce2e4: e59f0098 ldr r0, [pc, #152] ; c03ce384 >>> <_end+0xffcf9 >>> 19c> >>> c03ce2e8: e201100f and r1, r1, #15 ; 0xf >>> c03ce2ec: eb0012ea bl c03d2e9c >>>=20 >>>=20 >>> We are doing a ldrb (LoaD Relative Byte) which would be fine to >>> substitute for the right shift of 24, but only if it loaded the >>> correct byte.. It should be loading #4 instead of #7 since we are on >>> big endian... >>>=20 >>> Anyone who know gcc arm well to figure this out? >>>=20 >>=20 >> I have an untested fix at [1]. As I don't have any big-endian boards = I >> am unable to test the kernel with this. >>=20 >> Andrew >>=20 >> [1] http://people.freebsd.org/~andrew/armeb_gcc.diff >=20 > I have verified that this patch allows me to boot a kernel till it > mounts root... As I haven't put together a root fs yet, I can't say > if it goes to single/multiuser yet... Sounds like a sufficient test to commit it. We can make other fixes if = there are other issues... This is assuming that Andrew has tested on LE systems :0 Warner= From owner-freebsd-arm@FreeBSD.ORG Sat Jan 11 22:24:34 2014 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 ESMTPS id D6B06B37; Sat, 11 Jan 2014 22:24:34 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 902B41A4A; Sat, 11 Jan 2014 22:24:34 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id l6so6534595oag.19 for ; Sat, 11 Jan 2014 14:24:33 -0800 (PST) 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=b7yWD4YZeUu51KK44sg1Gzf9pSOqQlcRmcYyv1pwbYw=; b=cefleVrHPirW8b0l8lyipqe716Cs691ggsYdlNWacK3vsiqfAL5LMdJmcpxWGmeGST WIpEUYBQQFJPlNZvVI52tspa5oaDlBoLZTlvbVILFqyiq2OLCPmrfqxzVRp6Y2+tcPcW prH8kRObg2CYuxdLWEKAthwJJKSV0PnLou9Cw4zDL+NsJV0PMgNmBA4SDvMQ423Pf7MX E+bJRWRcyUETHc0VBzHr58dWd5OeYRnWAVF0QYPa+Lk3WTrKBMHQgXXRjpVFL8v/7A1d BMJtrDZn230fFoOmZ5maseLh42LGSuqF7mmM7bQJTCpDId94Uue00t66p3iHSH3Kd9a1 MDJg== MIME-Version: 1.0 X-Received: by 10.182.66.164 with SMTP id g4mr14382826obt.47.1389479073810; Sat, 11 Jan 2014 14:24:33 -0800 (PST) Received: by 10.76.20.82 with HTTP; Sat, 11 Jan 2014 14:24:33 -0800 (PST) Date: Sun, 12 Jan 2014 00:24:33 +0200 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary=089e0160c35e9e329d04efb94ed2 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 22:24:34 -0000 --089e0160c35e9e329d04efb94ed2 Content-Type: text/plain; charset=UTF-8 Hi, New patch that adds new aligned state structs and new ioctls. A trade-off of allowing correct alignment and improved speed for architectures that require alignment at the cost of extra maintenance when the state structs need to be extended. I duplicated the structs pfsync_state_scrub, pfsync_state_peer, pfsync_state_key and pfsync_state as non __packed structures. (pfsync_state_key is not marked as __packed, should it be?) pfsync_state_export also duplicated for the new struct. In the new state struct I reordered creatorid before the packets array to keep alignment on 8 bytes. packets and bytes converted to u_int64_t instead of array of u_int32_t (they are u_int64_t in the internal pf_state). sizeof(struct pf_addr) = 16; 16 % 4 = 0 sizeof(struct pfioc_state2_scrub) = 8; 8 % 4 = 0 sizeof(struct pfioc_state2_peer) = 28; 28 % 4 = 0 sizeof(struct pfioc_state2_key) = 36; 36 % 4 = 0 sizeof(struct pfioc_state2) = 232; 232 % 8 = 0 offsetof(struct pfioc_state2, src) = 96; 96 % 4 = 0 offsetof(struct pfioc_state2, dst) = 124; 124 % 4 = 0 offsetof(struct pfioc_state2, rt_addr) = 152; 152 % 4 = 0 offsetof(struct pfioc_state2, rule) = 168; 168 % 4 = 0 offsetof(struct pfioc_state2, packets) = 192; 192 % 8 = 0 The export for the new struct is done in host byte order which is used by the internal pf_state structure (except for pf_addr, id and creatorid which are kept in network order). I didn't bother creating a new version of DIOCADDSTATE since it is only used for pfsync and it receives only one pfioc_state / pfsync_state. Tested both of the new ioctls on the BeagleBone Black by modifying pfctl to also issue the single state ioctl with the (id,creatorid) of the last entry found in the print loop. I am not sure about the new structs and ioctls naming and there might be style bugs. Also attached a patch to constify the print functions in pfctl if there is interest in that. Needs to be applied after the new structs patch. P.S. Are alignment traps disabled on the Raspberry Pi? I wasn't able to cause a user space crash on the Pi with unaligned access. Regards, Guy --089e0160c35e9e329d04efb94ed2 Content-Type: application/octet-stream; name="pf-pfioc_state2.patch" Content-Disposition: attachment; filename="pf-pfioc_state2.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hqbfbiu50 SW5kZXg6IHN5cy9uZXQvcGZ2YXIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0L3BmdmFyLmgJKHJl dmlzaW9uIDI2MDQ5MikKKysrIHN5cy9uZXQvcGZ2YXIuaAkod29ya2luZyBjb3B5KQpAQCAtOTQz LDYgKzk0MywyMyBAQCBleHRlcm4gcGZsb2dfcGFja2V0X3QJCSpwZmxvZ19wYWNrZXRfcHRyOwog CX0JCQkJCQkJCVwKIH0gd2hpbGUgKDApCiAKKyNkZWZpbmUgcGZfc3RhdGVfcGVlcl9odG9oKHMs ZCkgZG8gewkJXAorCShkKS0+c2VxbG8gPSAocyktPnNlcWxvOwkJXAorCShkKS0+c2VxaGkgPSAo cyktPnNlcWhpOwkJXAorCShkKS0+c2VxZGlmZiA9IChzKS0+c2VxZGlmZjsJCVwKKwkoZCktPm1h eF93aW4gPSAocyktPm1heF93aW47CQlcCisJKGQpLT5tc3MgPSAocyktPm1zczsJCQlcCisJKGQp LT5zdGF0ZSA9IChzKS0+c3RhdGU7CQlcCisJKGQpLT53c2NhbGUgPSAocyktPndzY2FsZTsJCVwK KwlpZiAoKHMpLT5zY3J1YikgewkJCQkJCVwKKwkJKGQpLT5zY3J1Yi5wZnNzX2ZsYWdzID0gCQkJ CVwKKwkJICAgIChzKS0+c2NydWItPnBmc3NfZmxhZ3MgJiBQRlNTX1RJTUVTVEFNUDsJCVwKKwkJ KGQpLT5zY3J1Yi5wZnNzX3R0bCA9IChzKS0+c2NydWItPnBmc3NfdHRsOwkJXAorCQkoZCktPnNj cnViLnBmc3NfdHNfbW9kID0gKHMpLT5zY3J1Yi0+cGZzc190c19tb2Q7CVwKKwkJKGQpLT5zY3J1 Yi5zY3J1Yl9mbGFnID0gUEZTWU5DX1NDUlVCX0ZMQUdfVkFMSUQ7CVwKKwl9CQkJCQkJCQlcCit9 IHdoaWxlICgwKQorCiAjZGVmaW5lIHBmX3N0YXRlX2NvdW50ZXJfaHRvbihzLGQpIGRvIHsJCQkJ XAogCWRbMF0gPSBodG9ubCgocz4+MzIpJjB4ZmZmZmZmZmYpOwkJCVwKIAlkWzFdID0gaHRvbmwo cyYweGZmZmZmZmZmKTsJCQkJXApAQCAtMTQ0MCw2ICsxNDU3LDU1IEBAIHN0cnVjdCBwZmlvY19z dGF0ZSB7CiAJc3RydWN0IHBmc3luY19zdGF0ZQlzdGF0ZTsKIH07CiAKK3N0cnVjdCBwZmlvY19z dGF0ZTJfc2NydWIgeworCXVfaW50MTZfdAlwZnNzX2ZsYWdzOworCXVfaW50OF90CXBmc3NfdHRs OwkvKiBzdGFzaGVkIFRUTAkJKi8KKyNkZWZpbmUgUEZJT0NfU0NSVUJfRkxBR19WQUxJRAkJUEZT WU5DX1NDUlVCX0ZMQUdfVkFMSUQKKwl1X2ludDhfdAlzY3J1Yl9mbGFnOworCXVfaW50MzJfdAlw ZnNzX3RzX21vZDsJLyogdGltZXN0YW1wIG1vZHVsYXRpb24JKi8KK307CisKK3N0cnVjdCBwZmlv Y19zdGF0ZTJfcGVlciB7CisJc3RydWN0IHBmaW9jX3N0YXRlMl9zY3J1YiBzY3J1YjsJLyogc3Rh dGUgaXMgc2NydWJiZWQJKi8KKwl1X2ludDMyX3QJc2VxbG87CQkvKiBNYXggc2VxdWVuY2UgbnVt YmVyIHNlbnQJKi8KKwl1X2ludDMyX3QJc2VxaGk7CQkvKiBNYXggdGhlIG90aGVyIGVuZCBBQ0tk ICsgd2luCSovCisJdV9pbnQzMl90CXNlcWRpZmY7CS8qIFNlcXVlbmNlIG51bWJlciBtb2R1bGF0 b3IJKi8KKwl1X2ludDE2X3QJbWF4X3dpbjsJLyogbGFyZ2VzdCB3aW5kb3cgKHByZSBzY2FsaW5n KQkqLworCXVfaW50MTZfdAltc3M7CQkvKiBNYXhpbXVtIHNlZ21lbnQgc2l6ZSBvcHRpb24JKi8K Kwl1X2ludDhfdAlzdGF0ZTsJCS8qIGFjdGl2ZSBzdGF0ZSBsZXZlbAkJKi8KKwl1X2ludDhfdAl3 c2NhbGU7CQkvKiB3aW5kb3cgc2NhbGluZyBmYWN0b3IJKi8KK307CisKK3N0cnVjdCBwZmlvY19z dGF0ZTJfa2V5IHsKKwlzdHJ1Y3QgcGZfYWRkcgkgYWRkclsyXTsKKwl1X2ludDE2X3QJIHBvcnRb Ml07Cit9OworCitzdHJ1Y3QgcGZpb2Nfc3RhdGUyIHsKKwl1X2ludDY0X3QJIGlkOworCWNoYXIJ CSBpZm5hbWVbSUZOQU1TSVpdOworCXN0cnVjdCBwZmlvY19zdGF0ZTJfa2V5CWtleVsyXTsKKwlz dHJ1Y3QgcGZpb2Nfc3RhdGUyX3BlZXIgc3JjOworCXN0cnVjdCBwZmlvY19zdGF0ZTJfcGVlciBk c3Q7CisJc3RydWN0IHBmX2FkZHIJIHJ0X2FkZHI7CisJdV9pbnQzMl90CSBydWxlOworCXVfaW50 MzJfdAkgYW5jaG9yOworCXVfaW50MzJfdAkgbmF0X3J1bGU7CisJdV9pbnQzMl90CSBjcmVhdGlv bjsKKwl1X2ludDMyX3QJIGV4cGlyZTsKKwl1X2ludDMyX3QJIGNyZWF0b3JpZDsKKwl1X2ludDY0 X3QJIHBhY2tldHNbMl07CisJdV9pbnQ2NF90CSBieXRlc1syXTsKKwlzYV9mYW1pbHlfdAkgYWY7 CisJdV9pbnQ4X3QJIHByb3RvOworCXVfaW50OF90CSBkaXJlY3Rpb247CisJdV9pbnQ4X3QJIGxv ZzsKKwl1X2ludDhfdAkgc3RhdGVfZmxhZ3M7CisJdV9pbnQ4X3QJIHRpbWVvdXQ7CisJdV9pbnQ4 X3QJIHN5bmNfZmxhZ3M7CisJdV9pbnQ4X3QJIHVwZGF0ZXM7Cit9OworCiBzdHJ1Y3QgcGZpb2Nf c3JjX25vZGVfa2lsbCB7CiAJc2FfZmFtaWx5X3QgcHNua19hZjsKIAlzdHJ1Y3QgcGZfcnVsZV9h ZGRyIHBzbmtfc3JjOwpAQCAtMTQ2OCw2ICsxNTM0LDE0IEBAIHN0cnVjdCBwZmlvY19zdGF0ZXMg ewogI2RlZmluZSBwc19zdGF0ZXMJcHNfdS5wc3Vfc3RhdGVzCiB9OwogCitzdHJ1Y3QgcGZpb2Nf c3RhdGVzMiB7CisJaW50CXBzX2xlbjsKKwl1bmlvbiB7CisJCWNhZGRyX3QJCQkgcHN1X2J1ZjsK KwkJc3RydWN0IHBmaW9jX3N0YXRlMgkqcHN1X3N0YXRlczsKKwl9IHBzX3U7Cit9OworCiBzdHJ1 Y3QgcGZpb2Nfc3JjX25vZGVzIHsKIAlpbnQJcHNuX2xlbjsKIAl1bmlvbiB7CkBAIC0xNjQyLDYg KzE3MTYsOCBAQCBzdHJ1Y3QgcGZfaWZzcGVlZCB7CiAJdV9pbnQzMl90CQliYXVkcmF0ZTsKIH07 CiAjZGVmaW5lCURJT0NHSUZTUEVFRAlfSU9XUignRCcsIDkyLCBzdHJ1Y3QgcGZfaWZzcGVlZCkK KyNkZWZpbmUgRElPQ0dFVFNUQVRFMglfSU9XUignRCcsIDkzLCBzdHJ1Y3QgcGZpb2Nfc3RhdGUy KQorI2RlZmluZSBESU9DR0VUU1RBVEVTMglfSU9XUignRCcsIDk0LCBzdHJ1Y3QgcGZpb2Nfc3Rh dGVzMikKIAogI2lmZGVmIF9LRVJORUwKIHN0cnVjdCBwZl9zcmNoYXNoIHsKSW5kZXg6IHN5cy9u ZXRwZmlsL3BmL3BmX2lvY3RsLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldHBmaWwvcGYvcGZfaW9j dGwuYwkocmV2aXNpb24gMjYwNDkyKQorKysgc3lzL25ldHBmaWwvcGYvcGZfaW9jdGwuYwkod29y a2luZyBjb3B5KQpAQCAtMTA4LDYgKzEwOCw4IEBAIHN0YXRpYyBpbnQJCSBwZl9jb21taXRfcnVs ZXModV9pbnQzMl90LCBpbnQsIGNoYXIKIHN0YXRpYyBpbnQJCSBwZl9hZGRyX3NldHVwKHN0cnVj dCBwZl9ydWxlc2V0ICosCiAJCQkgICAgc3RydWN0IHBmX2FkZHJfd3JhcCAqLCBzYV9mYW1pbHlf dCk7CiBzdGF0aWMgdm9pZAkJIHBmX2FkZHJfY29weW91dChzdHJ1Y3QgcGZfYWRkcl93cmFwICop Oworc3RhdGljIHZvaWQJCSBwZmlvY19zdGF0ZTJfZXhwb3J0KHN0cnVjdCBwZmlvY19zdGF0ZTIg KnNwLAorCQkJICAgIHN0cnVjdCBwZl9zdGF0ZSAqc3QpOwogCiBWTkVUX0RFRklORShzdHJ1Y3Qg cGZfcnVsZSwJcGZfZGVmYXVsdF9ydWxlKTsKIApAQCAtMTAwMyw2ICsxMDA1LDggQEAgcGZpb2N0 bChzdHJ1Y3QgY2RldiAqZGV2LCB1X2xvbmcgY21kLCBjYWRkcl90IGFkZHIKIAkJY2FzZSBESU9D R0lGU1BFRUQ6CiAJCWNhc2UgRElPQ1NFVElGRkxBRzoKIAkJY2FzZSBESU9DQ0xSSUZGTEFHOgor CQljYXNlIERJT0NHRVRTVEFURTI6CisJCWNhc2UgRElPQ0dFVFNUQVRFUzI6CiAJCQlicmVhazsK IAkJY2FzZSBESU9DUkNMUlRBQkxFUzoKIAkJY2FzZSBESU9DUkFERFRBQkxFUzoKQEAgLTEwNDEs NiArMTA0NSw4IEBAIHBmaW9jdGwoc3RydWN0IGNkZXYgKmRldiwgdV9sb25nIGNtZCwgY2FkZHJf dCBhZGRyCiAJCWNhc2UgRElPQ0dFVFNSQ05PREVTOgogCQljYXNlIERJT0NJR0VUSUZBQ0VTOgog CQljYXNlIERJT0NHSUZTUEVFRDoKKwkJY2FzZSBESU9DR0VUU1RBVEUyOgorCQljYXNlIERJT0NH RVRTVEFURVMyOgogCQkJYnJlYWs7CiAJCWNhc2UgRElPQ1JDTFJUQUJMRVM6CiAJCWNhc2UgRElP Q1JBRERUQUJMRVM6CkBAIC0xNzU4LDYgKzE3NjQsNjggQEAgRElPQ0dFVFNUQVRFU19mdWxsOgog CQlicmVhazsKIAl9CiAKKwljYXNlIERJT0NHRVRTVEFURTI6IHsKKwkJc3RydWN0IHBmaW9jX3N0 YXRlMgkqcHMgPSAoc3RydWN0IHBmaW9jX3N0YXRlMiAqKWFkZHI7CisJCXN0cnVjdCBwZl9zdGF0 ZQkJKnM7CisKKwkJcyA9IHBmX2ZpbmRfc3RhdGVfYnlpZChwcy0+aWQsIHBzLT5jcmVhdG9yaWQp OworCQlpZiAocyA9PSBOVUxMKSB7CisJCQllcnJvciA9IEVOT0VOVDsKKwkJCWJyZWFrOworCQl9 CisKKwkJcGZpb2Nfc3RhdGUyX2V4cG9ydChwcywgcyk7CisJCVBGX1NUQVRFX1VOTE9DSyhzKTsK KwkJYnJlYWs7CisJfQorCisJY2FzZSBESU9DR0VUU1RBVEVTMjogeworCQlzdHJ1Y3QgcGZpb2Nf c3RhdGVzMgkqcHMgPSAoc3RydWN0IHBmaW9jX3N0YXRlczIgKilhZGRyOworCQlzdHJ1Y3QgcGZf c3RhdGUJCSpzOworCQlzdHJ1Y3QgcGZpb2Nfc3RhdGUyCSpwc3RvcmUsICpwOworCQlpbnQgaSwg bnI7CisKKwkJaWYgKHBzLT5wc19sZW4gPT0gMCkgeworCQkJbnIgPSB1bWFfem9uZV9nZXRfY3Vy KFZfcGZfc3RhdGVfeik7CisJCQlwcy0+cHNfbGVuID0gc2l6ZW9mKHN0cnVjdCBwZmlvY19zdGF0 ZTIpICogbnI7CisJCQlicmVhazsKKwkJfQorCisJCXAgPSBwc3RvcmUgPSBtYWxsb2MocHMtPnBz X2xlbiwgTV9URU1QLCBNX1dBSVRPSyk7CisJCW5yID0gMDsKKworCQlmb3IgKGkgPSAwOyBpIDw9 IFZfcGZfaGFzaG1hc2s7IGkrKykgeworCQkJc3RydWN0IHBmX2lkaGFzaCAqaWggPSAmVl9wZl9p ZGhhc2hbaV07CisKKwkJCVBGX0hBU0hST1dfTE9DSyhpaCk7CisJCQlMSVNUX0ZPUkVBQ0gocywg JmloLT5zdGF0ZXMsIGVudHJ5KSB7CisKKwkJCQlpZiAocy0+dGltZW91dCA9PSBQRlRNX1VOTElO S0VEKQorCQkJCQljb250aW51ZTsKKworCQkJCWlmICgobnIrMSkgKiBzaXplb2YoKnApID4gcHMt PnBzX2xlbikgeworCQkJCQlQRl9IQVNIUk9XX1VOTE9DSyhpaCk7CisJCQkJCWdvdG8gRElPQ0dF VFNUQVRFUzJfZnVsbDsKKwkJCQl9CisJCQkJcGZpb2Nfc3RhdGUyX2V4cG9ydChwLCBzKTsKKwkJ CQlwKys7CisJCQkJbnIrKzsKKwkJCX0KKwkJCVBGX0hBU0hST1dfVU5MT0NLKGloKTsKKwkJfQor RElPQ0dFVFNUQVRFUzJfZnVsbDoKKwkJZXJyb3IgPSBjb3B5b3V0KHBzdG9yZSwgcHMtPnBzX3N0 YXRlcywKKwkJICAgIHNpemVvZihzdHJ1Y3QgcGZpb2Nfc3RhdGUyKSAqIG5yKTsKKwkJaWYgKGVy cm9yKSB7CisJCQlmcmVlKHBzdG9yZSwgTV9URU1QKTsKKwkJCWJyZWFrOworCQl9CisJCXBzLT5w c19sZW4gPSBzaXplb2Yoc3RydWN0IHBmaW9jX3N0YXRlMikgKiBucjsKKwkJZnJlZShwc3RvcmUs IE1fVEVNUCk7CisKKwkJYnJlYWs7CisJfQorCiAJY2FzZSBESU9DR0VUU1RBVFVTOiB7CiAJCXN0 cnVjdCBwZl9zdGF0dXMgKnMgPSAoc3RydWN0IHBmX3N0YXR1cyAqKWFkZHI7CiAJCVBGX1JVTEVT X1JMT0NLKCk7CkBAIC0zMzA4LDYgKzMzNzYsNjYgQEAgcGZzeW5jX3N0YXRlX2V4cG9ydChzdHJ1 Y3QgcGZzeW5jX3N0YXRlICpzcCwgc3RydWMKIH0KIAogc3RhdGljIHZvaWQKK3BmaW9jX3N0YXRl Ml9leHBvcnQoc3RydWN0IHBmaW9jX3N0YXRlMiAqc3AsIHN0cnVjdCBwZl9zdGF0ZSAqc3QpCit7 CisJYnplcm8oc3AsIHNpemVvZihzdHJ1Y3QgcGZpb2Nfc3RhdGUyKSk7CisKKwkvKiBjb3B5IGZy b20gc3RhdGUga2V5ICovCisJc3AtPmtleVtQRl9TS19XSVJFXS5hZGRyWzBdID0gc3QtPmtleVtQ Rl9TS19XSVJFXS0+YWRkclswXTsKKwlzcC0+a2V5W1BGX1NLX1dJUkVdLmFkZHJbMV0gPSBzdC0+ a2V5W1BGX1NLX1dJUkVdLT5hZGRyWzFdOworCXNwLT5rZXlbUEZfU0tfV0lSRV0ucG9ydFswXSA9 IHN0LT5rZXlbUEZfU0tfV0lSRV0tPnBvcnRbMF07CisJc3AtPmtleVtQRl9TS19XSVJFXS5wb3J0 WzFdID0gc3QtPmtleVtQRl9TS19XSVJFXS0+cG9ydFsxXTsKKwlzcC0+a2V5W1BGX1NLX1NUQUNL XS5hZGRyWzBdID0gc3QtPmtleVtQRl9TS19TVEFDS10tPmFkZHJbMF07CisJc3AtPmtleVtQRl9T S19TVEFDS10uYWRkclsxXSA9IHN0LT5rZXlbUEZfU0tfU1RBQ0tdLT5hZGRyWzFdOworCXNwLT5r ZXlbUEZfU0tfU1RBQ0tdLnBvcnRbMF0gPSBzdC0+a2V5W1BGX1NLX1NUQUNLXS0+cG9ydFswXTsK KwlzcC0+a2V5W1BGX1NLX1NUQUNLXS5wb3J0WzFdID0gc3QtPmtleVtQRl9TS19TVEFDS10tPnBv cnRbMV07CisJc3AtPnByb3RvID0gc3QtPmtleVtQRl9TS19XSVJFXS0+cHJvdG87CisJc3AtPmFm ID0gc3QtPmtleVtQRl9TS19XSVJFXS0+YWY7CisKKwkvKiBjb3B5IGZyb20gc3RhdGUgKi8KKwlz dHJsY3B5KHNwLT5pZm5hbWUsIHN0LT5raWYtPnBmaWtfbmFtZSwgc2l6ZW9mKHNwLT5pZm5hbWUp KTsKKwliY29weSgmc3QtPnJ0X2FkZHIsICZzcC0+cnRfYWRkciwgc2l6ZW9mKHNwLT5ydF9hZGRy KSk7CisJc3AtPmNyZWF0aW9uID0gdGltZV91cHRpbWUgLSBzdC0+Y3JlYXRpb247CisJc3AtPmV4 cGlyZSA9IHBmX3N0YXRlX2V4cGlyZXMoc3QpOworCWlmIChzcC0+ZXhwaXJlIDw9IHRpbWVfdXB0 aW1lKQorCQlzcC0+ZXhwaXJlID0gMDsKKwllbHNlCisJCXNwLT5leHBpcmUgPSBzcC0+ZXhwaXJl IC0gdGltZV91cHRpbWU7CisKKwlzcC0+ZGlyZWN0aW9uID0gc3QtPmRpcmVjdGlvbjsKKwlzcC0+ bG9nID0gc3QtPmxvZzsKKwlzcC0+dGltZW91dCA9IHN0LT50aW1lb3V0OworCXNwLT5zdGF0ZV9m bGFncyA9IHN0LT5zdGF0ZV9mbGFnczsKKwlpZiAoc3QtPnNyY19ub2RlKQorCQlzcC0+c3luY19m bGFncyB8PSBQRlNZTkNfRkxBR19TUkNOT0RFOworCWlmIChzdC0+bmF0X3NyY19ub2RlKQorCQlz cC0+c3luY19mbGFncyB8PSBQRlNZTkNfRkxBR19OQVRTUkNOT0RFOworCisJc3AtPmlkID0gc3Qt PmlkOworCXNwLT5jcmVhdG9yaWQgPSBzdC0+Y3JlYXRvcmlkOworCXBmX3N0YXRlX3BlZXJfaHRv aCgmc3QtPnNyYywgJnNwLT5zcmMpOworCXBmX3N0YXRlX3BlZXJfaHRvaCgmc3QtPmRzdCwgJnNw LT5kc3QpOworCisJaWYgKHN0LT5ydWxlLnB0ciA9PSBOVUxMKQorCQlzcC0+cnVsZSA9IC0xOwor CWVsc2UKKwkJc3AtPnJ1bGUgPSBzdC0+cnVsZS5wdHItPm5yOworCWlmIChzdC0+YW5jaG9yLnB0 ciA9PSBOVUxMKQorCQlzcC0+YW5jaG9yID0gLTE7CisJZWxzZQorCQlzcC0+YW5jaG9yID0gc3Qt PmFuY2hvci5wdHItPm5yOworCWlmIChzdC0+bmF0X3J1bGUucHRyID09IE5VTEwpCisJCXNwLT5u YXRfcnVsZSA9IC0xOworCWVsc2UKKwkJc3AtPm5hdF9ydWxlID0gc3QtPm5hdF9ydWxlLnB0ci0+ bnI7CisKKwlzcC0+cGFja2V0c1swXSA9IHN0LT5wYWNrZXRzWzBdOworCXNwLT5wYWNrZXRzWzFd ID0gc3QtPnBhY2tldHNbMV07CisJc3AtPmJ5dGVzWzBdID0gc3QtPmJ5dGVzWzBdOworCXNwLT5i eXRlc1sxXSA9IHN0LT5ieXRlc1sxXTsKK30KKworc3RhdGljIHZvaWQKIHBmX3RibGFkZHJfY29w eW91dChzdHJ1Y3QgcGZfYWRkcl93cmFwICphdykKIHsKIAlzdHJ1Y3QgcGZyX2t0YWJsZSAqa3Q7 CkluZGV4OiBzYmluL3BmY3RsL3BmX3ByaW50X3N0YXRlLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9w ZmN0bC9wZl9wcmludF9zdGF0ZS5jCShyZXZpc2lvbiAyNjA0OTIpCisrKyBzYmluL3BmY3RsL3Bm X3ByaW50X3N0YXRlLmMJKHdvcmtpbmcgY29weSkKQEAgLTE5NCwyMSArMTk0LDIwIEBAIHByaW50 X2hvc3Qoc3RydWN0IHBmX2FkZHIgKmFkZHIsIHVfaW50MTZfdCBwb3J0LCBzCiB9CiAKIHZvaWQK LXByaW50X3NlcShzdHJ1Y3QgcGZzeW5jX3N0YXRlX3BlZXIgKnApCitwcmludF9zZXEoc3RydWN0 IHBmaW9jX3N0YXRlMl9wZWVyICpwKQogewogCWlmIChwLT5zZXFkaWZmKQotCQlwcmludGYoIlsl dSArICV1XSgrJXUpIiwgbnRvaGwocC0+c2VxbG8pLAotCQkgICAgbnRvaGwocC0+c2VxaGkpIC0g bnRvaGwocC0+c2VxbG8pLCBudG9obChwLT5zZXFkaWZmKSk7CisJCXByaW50ZigiWyV1ICsgJXVd KCsldSkiLCBwLT5zZXFsbywgcC0+c2VxaGkgLSBwLT5zZXFsbywKKwkJICAgIHAtPnNlcWRpZmYp OwogCWVsc2UKLQkJcHJpbnRmKCJbJXUgKyAldV0iLCBudG9obChwLT5zZXFsbyksCi0JCSAgICBu dG9obChwLT5zZXFoaSkgLSBudG9obChwLT5zZXFsbykpOworCQlwcmludGYoIlsldSArICV1XSIs IHAtPnNlcWxvLCBwLT5zZXFoaSAtIHAtPnNlcWxvKTsKIH0KIAogdm9pZAotcHJpbnRfc3RhdGUo c3RydWN0IHBmc3luY19zdGF0ZSAqcywgaW50IG9wdHMpCitwcmludF9zdGF0ZShzdHJ1Y3QgcGZp b2Nfc3RhdGUyICpzLCBpbnQgb3B0cykKIHsKLQlzdHJ1Y3QgcGZzeW5jX3N0YXRlX3BlZXIgKnNy YywgKmRzdDsKLQlzdHJ1Y3QgcGZzeW5jX3N0YXRlX2tleSAqc2ssICpuazsKKwlzdHJ1Y3QgcGZp b2Nfc3RhdGUyX3BlZXIgKnNyYywgKmRzdDsKKwlzdHJ1Y3QgcGZpb2Nfc3RhdGUyX2tleSAqc2ss ICpuazsKIAlzdHJ1Y3QgcHJvdG9lbnQgKnA7CiAJaW50IG1pbiwgc2VjOwogCkBAIC0yOTYsMTAg KzI5NSw4IEBAIHZvaWQKIAl9CiAKIAlpZiAob3B0cyAmIFBGX09QVF9WRVJCT1NFKSB7Ci0JCXVf aW50NjRfdCBwYWNrZXRzWzJdOwotCQl1X2ludDY0X3QgYnl0ZXNbMl07Ci0JCXVfaW50MzJfdCBj cmVhdGlvbiA9IG50b2hsKHMtPmNyZWF0aW9uKTsKLQkJdV9pbnQzMl90IGV4cGlyZSA9IG50b2hs KHMtPmV4cGlyZSk7CisJCXVfaW50MzJfdCBjcmVhdGlvbiA9IHMtPmNyZWF0aW9uOworCQl1X2lu dDMyX3QgZXhwaXJlID0gcy0+ZXhwaXJlOwogCiAJCXNlYyA9IGNyZWF0aW9uICUgNjA7CiAJCWNy ZWF0aW9uIC89IDYwOwpAQCAtMzEyLDE5ICszMDksMTMgQEAgdm9pZAogCQlleHBpcmUgLz0gNjA7 CiAJCXByaW50ZigiLCBleHBpcmVzIGluICUuMnU6JS4ydTolLjJ1IiwgZXhwaXJlLCBtaW4sIHNl Yyk7CiAKLQkJYmNvcHkocy0+cGFja2V0c1swXSwgJnBhY2tldHNbMF0sIHNpemVvZih1X2ludDY0 X3QpKTsKLQkJYmNvcHkocy0+cGFja2V0c1sxXSwgJnBhY2tldHNbMV0sIHNpemVvZih1X2ludDY0 X3QpKTsKLQkJYmNvcHkocy0+Ynl0ZXNbMF0sICZieXRlc1swXSwgc2l6ZW9mKHVfaW50NjRfdCkp OwotCQliY29weShzLT5ieXRlc1sxXSwgJmJ5dGVzWzFdLCBzaXplb2YodV9pbnQ2NF90KSk7CiAJ CXByaW50ZigiLCAlanU6JWp1IHBrdHMsICVqdTolanUgYnl0ZXMiLAotCQkgICAgKHVpbnRtYXhf dCApYmU2NHRvaChwYWNrZXRzWzBdKSwKLQkJICAgICh1aW50bWF4X3QgKWJlNjR0b2gocGFja2V0 c1sxXSksCi0JCSAgICAodWludG1heF90ICliZTY0dG9oKGJ5dGVzWzBdKSwKLQkJICAgICh1aW50 bWF4X3QgKWJlNjR0b2goYnl0ZXNbMV0pKTsKLQkJaWYgKG50b2hsKHMtPmFuY2hvcikgIT0gLTEp Ci0JCQlwcmludGYoIiwgYW5jaG9yICV1IiwgbnRvaGwocy0+YW5jaG9yKSk7Ci0JCWlmIChudG9o bChzLT5ydWxlKSAhPSAtMSkKLQkJCXByaW50ZigiLCBydWxlICV1IiwgbnRvaGwocy0+cnVsZSkp OworCQkgICAgKHVpbnRtYXhfdClzLT5wYWNrZXRzWzBdLCAodWludG1heF90KXMtPnBhY2tldHNb MV0sCisJCSAgICAodWludG1heF90KXMtPmJ5dGVzWzBdLCAodWludG1heF90KXMtPmJ5dGVzWzFd KTsKKwkJaWYgKHMtPmFuY2hvciAhPSAtMSkKKwkJCXByaW50ZigiLCBhbmNob3IgJXUiLCBzLT5h bmNob3IpOworCQlpZiAocy0+cnVsZSAhPSAtMSkKKwkJCXByaW50ZigiLCBydWxlICV1Iiwgcy0+ cnVsZSk7CiAJCWlmIChzLT5zdGF0ZV9mbGFncyAmIFBGU1RBVEVfU0xPUFBZKQogCQkJcHJpbnRm KCIsIHNsb3BweSIpOwogCQlpZiAocy0+c3luY19mbGFncyAmIFBGU1lOQ19GTEFHX1NSQ05PREUp CkBAIC0zMzQsMTEgKzMyNSw4IEBAIHZvaWQKIAkJcHJpbnRmKCJcbiIpOwogCX0KIAlpZiAob3B0 cyAmIFBGX09QVF9WRVJCT1NFMikgewotCQl1X2ludDY0X3QgaWQ7Ci0KLQkJYmNvcHkoJnMtPmlk LCAmaWQsIHNpemVvZih1X2ludDY0X3QpKTsKIAkJcHJpbnRmKCIgICBpZDogJTAxNmp4IGNyZWF0 b3JpZDogJTA4eCIsCi0JCSAgICAodWludG1heF90ICliZTY0dG9oKGlkKSwgbnRvaGwocy0+Y3Jl YXRvcmlkKSk7CisJCSAgICAodWludG1heF90KWJlNjR0b2gocy0+aWQpLCBudG9obChzLT5jcmVh dG9yaWQpKTsKIAkJcHJpbnRmKCJcbiIpOwogCX0KIH0KSW5kZXg6IHNiaW4vcGZjdGwvcGZjdGwu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBzYmluL3BmY3RsL3BmY3RsLmMJKHJldmlzaW9uIDI2MDQ5MikKKysr IHNiaW4vcGZjdGwvcGZjdGwuYwkod29ya2luZyBjb3B5KQpAQCAtMTA1NCw4ICsxMDU0LDggQEAg ZG9uZToKIGludAogcGZjdGxfc2hvd19zdGF0ZXMoaW50IGRldiwgY29uc3QgY2hhciAqaWZhY2Us IGludCBvcHRzKQogewotCXN0cnVjdCBwZmlvY19zdGF0ZXMgcHM7Ci0Jc3RydWN0IHBmc3luY19z dGF0ZSAqcDsKKwlzdHJ1Y3QgcGZpb2Nfc3RhdGVzMiBwczsKKwlzdHJ1Y3QgcGZpb2Nfc3RhdGUy ICpwOwogCWNoYXIgKmluYnVmID0gTlVMTCwgKm5ld2luYnVmID0gTlVMTDsKIAl1bnNpZ25lZCBp bnQgbGVuID0gMDsKIAlpbnQgaSwgZG90aXRsZSA9IChvcHRzICYgUEZfT1BUX1NIT1dBTEwpOwpA QCAtMTA2OSwxMiArMTA2OSwxMiBAQCBwZmN0bF9zaG93X3N0YXRlcyhpbnQgZGV2LCBjb25zdCBj aGFyICppZmFjZSwgaW50CiAJCQkJZXJyKDEsICJyZWFsbG9jIik7CiAJCQlwcy5wc19idWYgPSBp bmJ1ZiA9IG5ld2luYnVmOwogCQl9Ci0JCWlmIChpb2N0bChkZXYsIERJT0NHRVRTVEFURVMsICZw cykgPCAwKSB7Ci0JCQl3YXJuKCJESU9DR0VUU1RBVEVTIik7CisJCWlmIChpb2N0bChkZXYsIERJ T0NHRVRTVEFURVMyLCAmcHMpIDwgMCkgeworCQkJd2FybigiRElPQ0dFVFNUQVRFUzIiKTsKIAkJ CWZyZWUoaW5idWYpOwogCQkJcmV0dXJuICgtMSk7CiAJCX0KLQkJaWYgKHBzLnBzX2xlbiArIHNp emVvZihzdHJ1Y3QgcGZpb2Nfc3RhdGVzKSA8IGxlbikKKwkJaWYgKHBzLnBzX2xlbiArIHNpemVv ZihzdHJ1Y3QgcGZpb2Nfc3RhdGVzMikgPCBsZW4pCiAJCQlicmVhazsKIAkJaWYgKGxlbiA9PSAw ICYmIHBzLnBzX2xlbiA9PSAwKQogCQkJZ290byBkb25lOwpJbmRleDogc2Jpbi9wZmN0bC9wZmN0 bC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIHNiaW4vcGZjdGwvcGZjdGwuaAkocmV2aXNpb24gMjYwNDkyKQor Kysgc2Jpbi9wZmN0bC9wZmN0bC5oCSh3b3JraW5nIGNvcHkpCkBAIC0xMTcsOCArMTE3LDggQEAg Y2hhcgkJKnJhdGUyc3RyKGRvdWJsZSk7CiAKIHZvaWQJIHByaW50X2FkZHIoc3RydWN0IHBmX2Fk ZHJfd3JhcCAqLCBzYV9mYW1pbHlfdCwgaW50KTsKIHZvaWQJIHByaW50X2hvc3Qoc3RydWN0IHBm X2FkZHIgKiwgdV9pbnQxNl90IHAsIHNhX2ZhbWlseV90LCBpbnQpOwotdm9pZAkgcHJpbnRfc2Vx KHN0cnVjdCBwZnN5bmNfc3RhdGVfcGVlciAqKTsKLXZvaWQJIHByaW50X3N0YXRlKHN0cnVjdCBw ZnN5bmNfc3RhdGUgKiwgaW50KTsKK3ZvaWQJIHByaW50X3NlcShzdHJ1Y3QgcGZpb2Nfc3RhdGUy X3BlZXIgKik7Cit2b2lkCSBwcmludF9zdGF0ZShzdHJ1Y3QgcGZpb2Nfc3RhdGUyICosIGludCk7 CiBpbnQJIHVubWFzayhzdHJ1Y3QgcGZfYWRkciAqLCBzYV9mYW1pbHlfdCk7CiAKIGludAkgcGZj dGxfY21kbGluZV9zeW1zZXQoY2hhciAqKTsK --089e0160c35e9e329d04efb94ed2 Content-Type: application/octet-stream; name="pfctl-constify.patch" Content-Disposition: attachment; filename="pfctl-constify.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hqbfbpwr1 LS0tIHNiaW4vcGZjdGwvcGZjdGwuaC5vcmlnCTIwMTQtMDEtMTEgMjE6MjA6NTcuMDAwMDAwMDAw ICswMjAwCisrKyBzYmluL3BmY3RsL3BmY3RsLmgJMjAxNC0wMS0xMSAyMToyMjozMC4wMDAwMDAw MDAgKzAyMDAKQEAgLTExNSwxMSArMTE1LDExIEBAIHZvaWQJCSBwZmFsdHFfc3RvcmUoc3RydWN0 IHBmX2FsdHEgKik7CiBzdHJ1Y3QgcGZfYWx0cQkqcGZhbHRxX2xvb2t1cChjb25zdCBjaGFyICop OwogY2hhcgkJKnJhdGUyc3RyKGRvdWJsZSk7CiAKLXZvaWQJIHByaW50X2FkZHIoc3RydWN0IHBm X2FkZHJfd3JhcCAqLCBzYV9mYW1pbHlfdCwgaW50KTsKLXZvaWQJIHByaW50X2hvc3Qoc3RydWN0 IHBmX2FkZHIgKiwgdV9pbnQxNl90IHAsIHNhX2ZhbWlseV90LCBpbnQpOwotdm9pZAkgcHJpbnRf c2VxKHN0cnVjdCBwZmlvY19zdGF0ZTJfcGVlciAqKTsKLXZvaWQJIHByaW50X3N0YXRlKHN0cnVj dCBwZmlvY19zdGF0ZTIgKiwgaW50KTsKLWludAkgdW5tYXNrKHN0cnVjdCBwZl9hZGRyICosIHNh X2ZhbWlseV90KTsKK3ZvaWQJIHByaW50X2FkZHIoY29uc3Qgc3RydWN0IHBmX2FkZHJfd3JhcCAq LCBzYV9mYW1pbHlfdCwgaW50KTsKK3ZvaWQJIHByaW50X2hvc3QoY29uc3Qgc3RydWN0IHBmX2Fk ZHIgKiwgdV9pbnQxNl90IHAsIHNhX2ZhbWlseV90LCBpbnQpOwordm9pZAkgcHJpbnRfc2VxKGNv bnN0IHN0cnVjdCBwZmlvY19zdGF0ZTJfcGVlciAqKTsKK3ZvaWQJIHByaW50X3N0YXRlKGNvbnN0 IHN0cnVjdCBwZmlvY19zdGF0ZTIgKiwgaW50KTsKK2ludAkgdW5tYXNrKGNvbnN0IHN0cnVjdCBw Zl9hZGRyICosIHNhX2ZhbWlseV90KTsKIAogaW50CSBwZmN0bF9jbWRsaW5lX3N5bXNldChjaGFy ICopOwogaW50CSBwZmN0bF9hZGRfdHJhbnMoc3RydWN0IHBmcl9idWZmZXIgKiwgaW50LCBjb25z dCBjaGFyICopOwotLS0gc2Jpbi9wZmN0bC9wZmN0bF9wYXJzZXIuaC5vcmlnCTIwMTQtMDEtMTEg MTQ6MDA6MTMuMDAwMDAwMDAwICswMjAwCisrKyBzYmluL3BmY3RsL3BmY3RsX3BhcnNlci5oCTIw MTQtMDEtMTEgMjE6Mzc6MDIuMDAwMDAwMDAwICswMjAwCkBAIC0yOTIsNyArMjkyLDcgQEAgZXh0 ZXJuIGNvbnN0IHN0cnVjdCBwZl90aW1lb3V0IHBmX3RpbWVvdQogCiB2b2lkCQkJIHNldF9pcG1h c2soc3RydWN0IG5vZGVfaG9zdCAqLCB1X2ludDhfdCk7CiBpbnQJCQkgY2hlY2tfbmV0bWFzayhz dHJ1Y3Qgbm9kZV9ob3N0ICosIHNhX2ZhbWlseV90KTsKLWludAkJCSB1bm1hc2soc3RydWN0IHBm X2FkZHIgKiwgc2FfZmFtaWx5X3QpOworaW50CQkJIHVubWFzayhjb25zdCBzdHJ1Y3QgcGZfYWRk ciAqLCBzYV9mYW1pbHlfdCk7CiB2b2lkCQkJIGlmYV9sb2FkKHZvaWQpOwogc3RydWN0IG5vZGVf aG9zdAkqaWZhX2V4aXN0cyhjb25zdCBjaGFyICopOwogc3RydWN0IG5vZGVfaG9zdAkqaWZhX2xv b2t1cChjb25zdCBjaGFyICosIGludCk7Ci0tLSBzYmluL3BmY3RsL3BmX3ByaW50X3N0YXRlLmMu b3JpZwkyMDE0LTAxLTExIDIxOjIxOjMwLjAwMDAwMDAwMCArMDIwMAorKysgc2Jpbi9wZmN0bC9w Zl9wcmludF9zdGF0ZS5jCTIwMTQtMDEtMTEgMjE6Mzg6MTUuMDAwMDAwMDAwICswMjAwCkBAIC01 MCwxMCArNTAsMTAgQEAgX19GQlNESUQoIiRGcmVlQlNEOiByZWxlbmcvMTAuMC9zYmluL3BmYwog I2luY2x1ZGUgInBmY3RsX3BhcnNlci5oIgogI2luY2x1ZGUgInBmY3RsLmgiCiAKLXZvaWQJcHJp bnRfbmFtZShzdHJ1Y3QgcGZfYWRkciAqLCBzYV9mYW1pbHlfdCk7Cit2b2lkCXByaW50X25hbWUo Y29uc3Qgc3RydWN0IHBmX2FkZHIgKiwgc2FfZmFtaWx5X3QpOwogCiB2b2lkCi1wcmludF9hZGRy KHN0cnVjdCBwZl9hZGRyX3dyYXAgKmFkZHIsIHNhX2ZhbWlseV90IGFmLCBpbnQgdmVyYm9zZSkK K3ByaW50X2FkZHIoY29uc3Qgc3RydWN0IHBmX2FkZHJfd3JhcCAqYWRkciwgc2FfZmFtaWx5X3Qg YWYsIGludCB2ZXJib3NlKQogewogCXN3aXRjaCAoYWRkci0+dHlwZSkgewogCWNhc2UgUEZfQURE Ul9EWU5JRlRMOgpAQCAtMTM0LDcgKzEzNCw3IEBAIHByaW50X2FkZHIoc3RydWN0IHBmX2FkZHJf d3JhcCAqYWRkciwgc2EKIH0KIAogdm9pZAotcHJpbnRfbmFtZShzdHJ1Y3QgcGZfYWRkciAqYWRk ciwgc2FfZmFtaWx5X3QgYWYpCitwcmludF9uYW1lKGNvbnN0IHN0cnVjdCBwZl9hZGRyICphZGRy LCBzYV9mYW1pbHlfdCBhZikKIHsKIAljaGFyIGhvc3RbTklfTUFYSE9TVF07CiAKQEAgLTE2Nyw3 ICsxNjcsNyBAQCBwcmludF9uYW1lKHN0cnVjdCBwZl9hZGRyICphZGRyLCBzYV9mYW1pCiB9CiAK IHZvaWQKLXByaW50X2hvc3Qoc3RydWN0IHBmX2FkZHIgKmFkZHIsIHVfaW50MTZfdCBwb3J0LCBz YV9mYW1pbHlfdCBhZiwgaW50IG9wdHMpCitwcmludF9ob3N0KGNvbnN0IHN0cnVjdCBwZl9hZGRy ICphZGRyLCB1X2ludDE2X3QgcG9ydCwgc2FfZmFtaWx5X3QgYWYsIGludCBvcHRzKQogewogCWlm IChvcHRzICYgUEZfT1BUX1VTRUROUykKIAkJcHJpbnRfbmFtZShhZGRyLCBhZik7CkBAIC0xOTQs NyArMTk0LDcgQEAgcHJpbnRfaG9zdChzdHJ1Y3QgcGZfYWRkciAqYWRkciwgdV9pbnQxNgogfQog CiB2b2lkCi1wcmludF9zZXEoc3RydWN0IHBmaW9jX3N0YXRlMl9wZWVyICpwKQorcHJpbnRfc2Vx KGNvbnN0IHN0cnVjdCBwZmlvY19zdGF0ZTJfcGVlciAqcCkKIHsKIAlpZiAocC0+c2VxZGlmZikK IAkJcHJpbnRmKCJbJXUgKyAldV0oKyV1KSIsIHAtPnNlcWxvLCBwLT5zZXFoaSAtIHAtPnNlcWxv LApAQCAtMjA0LDEyICsyMDQsMTMgQEAgcHJpbnRfc2VxKHN0cnVjdCBwZmlvY19zdGF0ZTJfcGVl ciAqcCkKIH0KIAogdm9pZAotcHJpbnRfc3RhdGUoc3RydWN0IHBmaW9jX3N0YXRlMiAqcywgaW50 IG9wdHMpCitwcmludF9zdGF0ZShjb25zdCBzdHJ1Y3QgcGZpb2Nfc3RhdGUyICpzLCBpbnQgb3B0 cykKIHsKLQlzdHJ1Y3QgcGZpb2Nfc3RhdGUyX3BlZXIgKnNyYywgKmRzdDsKLQlzdHJ1Y3QgcGZp b2Nfc3RhdGUyX2tleSAqc2ssICpuazsKLQlzdHJ1Y3QgcHJvdG9lbnQgKnA7CisJY29uc3Qgc3Ry dWN0IHBmaW9jX3N0YXRlMl9wZWVyICpzcmMsICpkc3Q7CisJY29uc3Qgc3RydWN0IHBmaW9jX3N0 YXRlMl9rZXkgKnNrLCAqbms7CisJY29uc3Qgc3RydWN0IHByb3RvZW50ICpwOwogCWludCBtaW4s IHNlYzsKKwl1X2ludDE2X3Qgc3BvcnRbMl0sIG5wb3J0WzJdOwogCiAJaWYgKHMtPmRpcmVjdGlv biA9PSBQRl9PVVQpIHsKIAkJc3JjID0gJnMtPnNyYzsKQEAgLTIxNywxNCArMjE4LDI0IEBAIHBy aW50X3N0YXRlKHN0cnVjdCBwZmlvY19zdGF0ZTIgKnMsIGludCAKIAkJc2sgPSAmcy0+a2V5W1BG X1NLX1NUQUNLXTsKIAkJbmsgPSAmcy0+a2V5W1BGX1NLX1dJUkVdOwogCQlpZiAocy0+cHJvdG8g PT0gSVBQUk9UT19JQ01QIHx8IHMtPnByb3RvID09IElQUFJPVE9fSUNNUFY2KSAKLQkJCXNrLT5w b3J0WzBdID0gbmstPnBvcnRbMF07CisJCQlzcG9ydFswXSA9IG5rLT5wb3J0WzBdOworCQllbHNl CisJCQlzcG9ydFswXSA9IHNrLT5wb3J0WzBdOworCQlzcG9ydFsxXSA9IHNrLT5wb3J0WzFdOwor CQlucG9ydFswXSA9IG5rLT5wb3J0WzBdOworCQlucG9ydFsxXSA9IG5rLT5wb3J0WzFdOwogCX0g ZWxzZSB7CiAJCXNyYyA9ICZzLT5kc3Q7CiAJCWRzdCA9ICZzLT5zcmM7CiAJCXNrID0gJnMtPmtl eVtQRl9TS19XSVJFXTsKIAkJbmsgPSAmcy0+a2V5W1BGX1NLX1NUQUNLXTsKKwkJc3BvcnRbMF0g PSBzay0+cG9ydFswXTsKIAkJaWYgKHMtPnByb3RvID09IElQUFJPVE9fSUNNUCB8fCBzLT5wcm90 byA9PSBJUFBST1RPX0lDTVBWNikgCi0JCQlzay0+cG9ydFsxXSA9IG5rLT5wb3J0WzFdOworCQkJ c3BvcnRbMV0gPSBuay0+cG9ydFsxXTsKKwkJZWxzZQorCQkJc3BvcnRbMV0gPSBzay0+cG9ydFsx XTsKKwkJbnBvcnRbMF0gPSBuay0+cG9ydFswXTsKKwkJbnBvcnRbMV0gPSBuay0+cG9ydFsxXTsK IAl9CiAJcHJpbnRmKCIlcyAiLCBzLT5pZm5hbWUpOwogCWlmICgocCA9IGdldHByb3RvYnludW1i ZXIocy0+cHJvdG8pKSAhPSBOVUxMKQpAQCAtMjMyLDIyICsyNDMsMjIgQEAgcHJpbnRfc3RhdGUo c3RydWN0IHBmaW9jX3N0YXRlMiAqcywgaW50IAogCWVsc2UKIAkJcHJpbnRmKCIldSAiLCBzLT5w cm90byk7CiAKLQlwcmludF9ob3N0KCZuay0+YWRkclsxXSwgbmstPnBvcnRbMV0sIHMtPmFmLCBv cHRzKTsKKwlwcmludF9ob3N0KCZuay0+YWRkclsxXSwgbnBvcnRbMV0sIHMtPmFmLCBvcHRzKTsK IAlpZiAoUEZfQU5FUSgmbmstPmFkZHJbMV0sICZzay0+YWRkclsxXSwgcy0+YWYpIHx8Ci0JICAg IG5rLT5wb3J0WzFdICE9IHNrLT5wb3J0WzFdKSB7CisJICAgIG5wb3J0WzFdICE9IHNwb3J0WzFd KSB7CiAJCXByaW50ZigiICgiKTsKLQkJcHJpbnRfaG9zdCgmc2stPmFkZHJbMV0sIHNrLT5wb3J0 WzFdLCBzLT5hZiwgb3B0cyk7CisJCXByaW50X2hvc3QoJnNrLT5hZGRyWzFdLCBzcG9ydFsxXSwg cy0+YWYsIG9wdHMpOwogCQlwcmludGYoIikiKTsKIAl9CiAJaWYgKHMtPmRpcmVjdGlvbiA9PSBQ Rl9PVVQpCiAJCXByaW50ZigiIC0+ICIpOwogCWVsc2UKIAkJcHJpbnRmKCIgPC0gIik7Ci0JcHJp bnRfaG9zdCgmbmstPmFkZHJbMF0sIG5rLT5wb3J0WzBdLCBzLT5hZiwgb3B0cyk7CisJcHJpbnRf aG9zdCgmbmstPmFkZHJbMF0sIG5wb3J0WzBdLCBzLT5hZiwgb3B0cyk7CiAJaWYgKFBGX0FORVEo Jm5rLT5hZGRyWzBdLCAmc2stPmFkZHJbMF0sIHMtPmFmKSB8fAotCSAgICBuay0+cG9ydFswXSAh PSBzay0+cG9ydFswXSkgeworCSAgICBucG9ydFswXSAhPSBzcG9ydFswXSkgewogCQlwcmludGYo IiAoIik7Ci0JCXByaW50X2hvc3QoJnNrLT5hZGRyWzBdLCBzay0+cG9ydFswXSwgcy0+YWYsIG9w dHMpOworCQlwcmludF9ob3N0KCZzay0+YWRkclswXSwgc3BvcnRbMF0sIHMtPmFmLCBvcHRzKTsK IAkJcHJpbnRmKCIpIik7CiAJfQogCkBAIC0zMzIsNyArMzQzLDcgQEAgcHJpbnRfc3RhdGUoc3Ry dWN0IHBmaW9jX3N0YXRlMiAqcywgaW50IAogfQogCiBpbnQKLXVubWFzayhzdHJ1Y3QgcGZfYWRk ciAqbSwgc2FfZmFtaWx5X3QgYWYpCit1bm1hc2soY29uc3Qgc3RydWN0IHBmX2FkZHIgKm0sIHNh X2ZhbWlseV90IGFmKQogewogCWludCBpID0gMzEsIGogPSAwLCBiID0gMDsKIAl1X2ludDMyX3Qg dG1wOwo= --089e0160c35e9e329d04efb94ed2--